Community
Participate
Working Groups
Using I20210518-1800. With /org.eclipse.ui.ide/extensions/org/eclipse/ui/dialogs/WizardNewFolderMainPage.java go to handleAdvancedButtonSelect() method, to the first "if (linkedResourceComposite != null) {" and try to auto-complete any existing field, e.g. linkedResourceComposite.| There are no proposals shown. Nada. Try to do same in the same method, but *before* the "if (linkedResourceComposite != null)" - content assist works. This is highly frustrating, IMHO it is a blocker issue for content assist.
Stephan, I know you did something in the content assist area - is this may be related?
I am on I20210519-1800 and I see this problem. Interestingly, If you have a semi colon after your invocation point, then proposals are offered. Andrey, are you seeing that too?
(In reply to Jay Arthanareeswaran from comment #2) > Andrey, are you seeing that too? Exact. I will try bisect where it is coming from later today. For me this *must* be in 4.20.
Okay, I see this is most likely caused by https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=e3517ddc41f3c9536a29ef9be4e7dd3104993ab2 I see that in the broken case, we end up creating a TypeReference (instead of NameReference). Interestingly, we also end up parsing the complete "then" block. Previously the then statement only had the completion node.
Okay, something weird going on when we create CompletionQTypeReference. This is the point in paring at which we create the completion node: linkedResourceComposite. linkedResourceComposite =============================== Starts here -->=<-- Ends here =============================== null; Note that we are already past the completion node in question and onto the next statement. And this is the stack: CompletionOnQualifiedTypeReference.<init>(char[][], char[], long[]) line: 45 CompletionParser.checkAndCreateModuleQualifiedAssistTypeReference(char[][], char[], long[]) line: 5008 CompletionParser.createQualifiedAssistTypeReference(char[][], char[], long[]) line: 5034 CompletionParser(AssistParser).getTypeReference(int) line: 1492 CompletionParser(Parser).consumeEnterVariable() line: 3668 How did we even get to consumeEnterVariable() with a statement that has "."? linkedResourceComposite. linkedResourceComposite = null;
(In reply to Jay Arthanareeswaran from comment #4) > Okay, I see this is most likely caused by > > https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=e3517ddc41f3c9536a29ef9be4e7dd3104993ab2 > > I see that in the broken case, we end up creating a TypeReference (instead > of NameReference). Interestingly, we also end up parsing the complete "then" > block. Previously the then statement only had the completion node. Right, since Bug 539685 we parse to the end of the expression to provide more context for resolution / type inference. Given that I broke it, I will take a look later today. BTW, regression: yes. High priority: yes. Blocker: "the bug blocks development or testing of the build (for which there is no work-around)" [1] no way! :) [1] https://wiki.eclipse.org/Bug_Reporting_FAQ#What_is_the_difference_between_Severity_and_Priority.3F
(In reply to Stephan Herrmann from comment #6) > Given that I broke it, I will take a look later today. Thanks. > BTW, regression: yes. High priority: yes. Blocker: > > "the bug blocks development or testing of the build (for which there is no > work-around)" [1] > > no way! :) Given the fact that the major IDE functionality (editing/content assist) is "randomly" broken for the user, this is a blocker. This is a trivial thing may be, and you still can compile, debug etc, but from user perspective IDE is not usable anymore for daily work. With this bug one can go directly to vi for editing sources. Therefore releasing with this bug is a "no go" from my POV, and so it is a blocker.
(In reply to Andrey Loskutov from comment #7) > (In reply to Stephan Herrmann from comment #6) > > Given that I broke it, I will take a look later today. > > Thanks. > > > BTW, regression: yes. High priority: yes. Blocker: > > > > "the bug blocks development or testing of the build (for which there is no > > work-around)" [1] > > > > no way! :) > > Given the fact that the major IDE functionality (editing/content assist) is > "randomly" broken for the user, this is a blocker. This is a trivial thing > may be, and you still can compile, debug etc, but from user perspective IDE > is not usable anymore for daily work. With this bug one can go directly to > vi for editing sources. > > Therefore releasing with this bug is a "no go" from my POV, and so it is a > blocker. Are you saying the documentation is no longer up-to-date / used / relevant: https://wiki.eclipse.org/Bug_Reporting_FAQ#What_is_the_difference_between_Severity_and_Priority.3F ? What you describe exactly fits to the description of "major", if you ask me.
BTW, for me bug 569668 is a true blocker according to your description. If somebody looks into that, it would certainly increase my enthusiasm for Eclipse :)
(In reply to Stephan Herrmann from comment #8) > Are you saying the documentation is no longer up-to-date / used / relevant: > https://wiki.eclipse.org/ > Bug_Reporting_FAQ#What_is_the_difference_between_Severity_and_Priority.3F > ? Yes. Never seen "P" flags used in last few years, and also the rest is very developer-focused, not user-focused. The impact of this bug on the average IDE user is *very* high, even if there is no data loss and no crashes etc. I guess "usability" was not that prominent at time the wiki was written. Also please note "But overall, it is up to each project do decide how they triage/handle bugs so some variability from project to project will occur." > What you describe exactly fits to the description of "major", if you ask me. :-) I was beaten by our customers so many times for so much smaller bugs in Eclipse, I don't want to imagine how they would complain about non functional content assist => blocker for me / my users.
(In reply to Jay Arthanareeswaran from comment #5) > Note that we are already past the completion node in question and onto the > next statement. And this is the stack: > > CompletionOnQualifiedTypeReference.<init>(char[][], char[], long[]) line: 45 > CompletionParser.checkAndCreateModuleQualifiedAssistTypeReference(char[][], > char[], long[]) line: 5008 > CompletionParser.createQualifiedAssistTypeReference(char[][], char[], > long[]) line: 5034 Clearly checkAndCreateModuleQualifiedAssistTypeReference does more than what its name suggests. It contains the old pre-module code as well.
(In reply to Jay Arthanareeswaran from comment #5) > How did we even get to consumeEnterVariable() with a statement that has "."? > > linkedResourceComposite. > linkedResourceComposite = null; Due to the greater parse range, the parser will see linkedResourceComposite.linkedResourceComposite as a qualified type reference that starts a variable declaration. Inside fetchNextToken() we have some heuristics when to fall back to the old strategy (reduced parse range) by signaling an early EOF. One of rules is to check if any expressions are pending on expressionStack. While the current block doesn't have any pending expressions, the heuristic is tricked by the if-condition that still lingers on the expression stack, but shouldn't influence that heuristic. Upcoming patch will refine the heuristic to detect that the expression is "out of scope". All this probably implies that inside a lambda that same problem persists, because with lambdas involved, the old strategy is no good.
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/180822
(In reply to Eclipse Genie from comment #13) > New Gerrit change created: > https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/180822 Intermediate test failures should be fixed in patch set #2 Jay, Andrey, can you take it to completion from here (incl. any required approvals)?
I've seen the failure in CompletionTests.testCompletionKeywordContinue5. I can look into it after business hours.
(In reply to Stephan Herrmann from comment #15) > I've seen the failure in CompletionTests.testCompletionKeywordContinue5. > I can look into it after business hours. If I make a small change to the following statement, then the failing test pass. But I guess this could have side effects. pushOnElementStack(K_BLOCK_DELIMITER, IF, this.expressionStack[this.expressionPtr]); // Change IF to FOR/WHILE Wonder if we should push respective infos in all case statements?
(In reply to Jay Arthanareeswaran from comment #16) > Wonder if we should push respective infos in all case statements? Amended the patch to this effect. Let's see how the tests go. Stephan, please take a look.
See also bug 573702 and bug 573694. Probably they are also related here.
*** Bug 573694 has been marked as a duplicate of this bug. ***
For those not following on gerrit: we have a green build. Over to the people who decide about inclusion in RC1 :)
@Stephan i have tested your patches and it works perfect now. I added few comments on the tests though, but we can decide when and how to handle them with the given time frame.
(In reply to Gayan Perera from comment #21) > @Stephan i have tested your patches and it works perfect now. I added few > comments on the tests though, but we can decide when and how to handle them > with the given time frame. I test this issue as well, but the comments are for other issue.
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/180822 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=0904799f18b393b84b7d7f69b95f1a1cd7534343
Verified in Eclipse SDK Version: 2021-06 (4.20) Build id: I20210524-1800 OS: Windows 10, v.10.0, x86_64 / win32 Java vendor: AdoptOpenJDK Java runtime version: 11.0.10+9 Java version: 11.0.10
Just to say, there may still be failing cases: bug 576934
