Bugzilla – Full Text Bug Listing
| Summary: | Autocompletion not available in Enum constructors | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Fred Bricon <fbricon> |
| Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | baier, cristichi, dma_k, gautier.desaintmartinlacaze, jarthana, kenneth, kleeeis, manoj.palat, raue, stephan.herrmann, Vikas.Chandra |
| Version: | 4.8 | ||
| Target Milestone: | 4.20 M3 | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| See Also: |
https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/179390 https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=faafc0ab6cd99562ebbe9577db2435ece4750ebd |
||
| Whiteboard: | |||
| Bug Depends on: | 539685 | ||
| Bug Blocks: | |||
Any chance to fix this? Enums are a very usefull to add some behavior, see Effective Java 3 Item 42. https://github.com/jbloch/effective-java-3e-source-code/blob/master/src/effectivejava/chapter7/item42/Operation.java @Stephan I've been testing this and found out that if I add a bogus character in the enum to add a compile error, then the code completion works for enum constructors. If I followed the code correct, the parser put a EOF token if it finds an error during argument parsing, this does not happen when we have a error somewhere else in the enum, and the parser can correctly find the correct constructor call. I can't find out how to continue from here, that's why I added you to this bug if you can sprinkle some fairy dust on this. Note to previous comment, the bogus character must be added before any enum constants to see the correct behaviour. I changed the code a bit so that the constructor appears above the completion node and in this case, the completion works. Here's what the ast looks like just before resolution (CompletionEngine):
public enum Foo {
Foo,
Color color;
{
}
Bar(<CompleteOnName:Color.G>),
public Foo() {
}
<clinit>() {
}
}
And in the reported case it looks like this:
public enum Foo {
Bar,
public Foo() {
}
<clinit>() {
}
}
Notice the missing completion node? I see we do create a completion node inside CompletionParser.createQualifiedAssistNameReference() but doesn't get attached anywhere in the compilation unit. If we can just find a way to do that, things should work.
This bug is so annoying, I hope it gets fixed sooner or later I agree code completion bugs can be annoying. However, the JDT team is short on resources and mostly focusing on new Java releases. If someone from the community if interested in taking a look, I can review the patch. This is really annoying, cf. related bug 395604 I could not circumvent this problem by adding bogus characters in Eclipse 2018-12. public enum E {
E1,
E2
}
public enum F {
F1(E.E1), <== #1 remove comma here
F2(E.) <== #2 now the assist work here
;
F(E e1) {
}
}
Thanks, Kenneth, I tried pretty much that without success, but now it does work. Same as bug #499649 and #395604. Does not work for me on Eclipse v4.14.0.v20191210-0610. I can confirm this bug still exists in Eclipse 4.19. I'm getting hit by this bug more often recently as I'm using more complex enums. Potentially there is hope via bug 539685 where finally I'm addressing exactly this: (In reply to Kenneth Styrberg from comment #2) > If I followed the code correct, the parser put a EOF token if it finds an > error during argument parsing, this does not happen when we have a error > somewhere else in the enum, and the parser can correctly find the correct > constructor call. New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/179390 (In reply to Eclipse Genie from comment #14) > New Gerrit change created: > https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/179390 The fix is quite simple: simply don't set EOF when inside an enum constant initializer. Just when applied on head it causes a few regressions. Fortunately, these regressions don't occur when applied on top of Bug 539685 and Bug 558530. The downside: we'll see the flood of regressions where Bug 539685 hasn't yet adjusted expectations of completion parser tests (where I assume that most changes are actually improvements - just it needs to be sorted out). BTW: As all this happens already during diet parsing, I don't think that parsing more should be a problem. Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/179390 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=faafc0ab6cd99562ebbe9577db2435ece4750ebd Verified for 4.20 M3 Version: 2021-06 (4.20)Build id: I20210518-0850 |
Enum constructors with parameters get no autocompletion at all, when trying to complete those parameters. Given: public enum Color { GREEN, BLUE; } public enum Foo { Bar(Color.G /* Ctrl+space and nothing happens here */); Foo(Color color) {} } This affects jdt.ls too, and trickles down to vscode-java [1] [1] https://github.com/redhat-developer/vscode-java/issues/454