Community
Participate
Working Groups
Eclipse proposes for me class name instead of a field name. -- Configuration Details -- Product: Eclipse 4.6.0.20160613-1800 (org.eclipse.epp.package.jee.product) Installed Features: org.eclipse.jdt 3.12.0.v20160606-1100
Created attachment 262831 [details] screenshot See the screenshot that clarifies everything.
I don't think we ever propose field names, method names or things like that. What you see is just a list of types that are available in this context, not necessarily useful there. Noopur, can you confirm please?
(In reply to Jay Arthanareeswaran from comment #2) > I don't think we ever propose field names, method names or things like that. > What you see is just a list of types that are available in this context, not > necessarily useful there. > > Noopur, can you confirm please? We propose field names of kind org.eclipse.jdt.core.CompletionProposal.VARIABLE_DECLARATION. @Yauheniy, can you please provide a standalone example to reproduce the bug?
(In reply to Noopur Gupta from comment #3) > (In reply to Jay Arthanareeswaran from comment #2) > > I don't think we ever propose field names, method names or things like that. > > What you see is just a list of types that are available in this context, not > > necessarily useful there. > > > > Noopur, can you confirm please? > > We propose field names of kind > org.eclipse.jdt.core.CompletionProposal.VARIABLE_DECLARATION. > > @Yauheniy, can you please provide a standalone example to reproduce the bug? What do you mean "standalone"? Just start typing field declaration: private MyClass [here something commmon, that spells like any class and press CTRL+SPACE and you will see that it proposes for you class names]. BUT!! If I type it with semicolon - everything works fine! But who will type semicolon first and then field name? private MyClass ;| //move your cursor private MyClass |; //start typing and press ctrl+space, it works and proposes "myClass/class/etc." Is it clear for you? Try it yourself and you will understand, what I'm talking about.
(In reply to Noopur Gupta from comment #3) > (In reply to Jay Arthanareeswaran from comment #2) > > I don't think we ever propose field names, method names or things like that. > > What you see is just a list of types that are available in this context, not > > necessarily useful there. > > > > Noopur, can you confirm please? > > We propose field names of kind > org.eclipse.jdt.core.CompletionProposal.VARIABLE_DECLARATION. > > @Yauheniy, can you please provide a standalone example to reproduce the bug? See the screenshot. It should propose for me "localizationService" in this case. I saw this problem not only in this specific project and even in the previous versions of Eclipse.
Just to second Noopur's request for a "standalone example": when I have this in my editor: //--- public class FieldCompletion { private FieldCompletion | } //--- and hit Ctrl+Space I get the to expected proposals "completion" and "fieldCompletion". So, perhaps s.t. is different in your context, perhaps s.t. at some location of your file which you are not showing. Can you please show an entire file? If that doesn't let us reproduce we will ask about a self-contained project etc. ...
Created attachment 262865 [details] STEP BY STEP Screenshots
(In reply to Stephan Herrmann from comment #6) > Just to second Noopur's request for a "standalone example": when I have this > in my editor: > > //--- > public class FieldCompletion { > private FieldCompletion | > } > //--- > > and hit Ctrl+Space I get the to expected proposals "completion" and > "fieldCompletion". > > So, perhaps s.t. is different in your context, perhaps s.t. at some location > of your file which you are not showing. Can you please show an entire file? > If that doesn't let us reproduce we will ask about a self-contained project > etc. ... See attachments. It reproduces when you have any method below this field and if you typing without a semicolon.
OK, all it takes to reproduce the problem is this: //--- public class Main { private LinkageError | @Override public String toString() { return ""; } } //--- (sreenshots aren't really the best way to share Java code...) And here's what makes the difference between attachment 262831 [details], comment 6 on the one hand and successful reproduction of the problem on the other hand: *when followed by an annotated method declaration* the incomplete field declaration is somehow understood as part of the subsequent method declaration. To witness: toString() has this error: The method toString in type Main can only set one of public / protected / private Now, while the field declaration is incomplete we obviously have a syntax error. Code completion depends on smart recovery at that error. Things work fine even with an unannotated method declaration, only when also adding the annotation, syntax recovery gets confused. Technically, we seem to end up seeing a list of modifiers: private LinkageError @Override public most of this is *syntactically OK*, only one token, LinkageError, is syntactically wrong, so dropping this single token is the simplest recovery. After such error recovery there is no hint anymore that completion should produce a field name. I'm not sure if tweaking the heuristics of syntax recovery for this case is feasible. OTOH, the fact that the @Override annotations makes the difference between desired and undesired recovery could give a hint. Last note: even in the bad case I see only one class name proposed: Main. That is: part of the problem can still not be reproduced just by following the steps. Not sure if this is worth pursuing.
(In reply to Stephan Herrmann from comment #9) > OK, all it takes to reproduce the problem is this: > > //--- > public class Main { > private LinkageError | > > @Override > public String toString() { > return ""; > } > } > //--- > > (sreenshots aren't really the best way to share Java code...) > > > And here's what makes the difference between attachment 262831 [details], > comment 6 on the one hand and successful reproduction of the problem on the > other hand: *when followed by an annotated method declaration* the > incomplete field declaration is somehow understood as part of the subsequent > method declaration. To witness: toString() has this error: > > The method toString in type Main can only set one of public / protected / > private > > Now, while the field declaration is incomplete we obviously have a syntax > error. Code completion depends on smart recovery at that error. Things work > fine even with an unannotated method declaration, only when also adding the > annotation, syntax recovery gets confused. > > Technically, we seem to end up seeing a list of modifiers: > private LinkageError @Override public > > most of this is *syntactically OK*, only one token, LinkageError, is > syntactically wrong, so dropping this single token is the simplest recovery. > After such error recovery there is no hint anymore that completion should > produce a field name. > > > I'm not sure if tweaking the heuristics of syntax recovery for this case is > feasible. OTOH, the fact that the @Override annotations makes the difference > between desired and undesired recovery could give a hint. > > > Last note: even in the bad case I see only one class name proposed: Main. > That is: part of the problem can still not be reproduced just by following > the steps. Not sure if this is worth pursuing. "sreenshots aren't really the best way to share Java code..." I'm sorry, just wanted to show you position of cursor and popup window as is. Nevertheless it's not the right way to interpret it. > Technically, we seem to end up seeing a list of modifiers: > private LinkageError @Override public I think if it takes not really much time, it's really a good idea to fix it. This behaviour is unexpeceted. BTW: It reproduces also when field is followed by annotated another one. private Exception exc| //HERE THE SAME, wrong completion. @Deprecated private LinkageError linkageError;
(In reply to Yauheniy Ratkevich from comment #10) > Nevertheless it's not the right way to interpret it. > > Technically, we seem to end up seeing a list of modifiers: > > private LinkageError @Override public > > I think if it takes not really much time, it's really a good idea to fix it. > This behaviour is unexpeceted. Let me just note, that this is not the explicit decision of any engineer to interpret the broken syntax as shown. It's the answer from a sophisticated heuristic-based algorithm. Tweaking that algorithm is a very delicate issue, so "if it takes not really much time" is s.t. we cannot know in advance.
