Summary: | Code completion engine hints annotations on wrong places | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Kaloyan Raev <kaloyan> | ||||||
Component: | Core | Assignee: | David Audel <david_audel> | ||||||
Status: | CLOSED FIXED | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | ||||||||
Version: | 3.2 | ||||||||
Target Milestone: | 3.3 M7 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows XP | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Kaloyan Raev
2006-09-27 11:38:16 EDT
I presume you are talking about the @Target level for an annotation ? If so, then the same logic used by the compiler to flag inappropriate annotations is available in codeassist engine. I suspect the behavior is explainable by the fact the annotation isn't attached during codeassist to the next element (could be wrong there), and thus discrimination may not occur. Created attachment 51022 [details]
demoproject
I attach demo project. The zip file contains a project fake-ejb30. This is a simple Java project with ejb-3_0-api.jar library added in the classpath. To reproduce the problem open FakeEJB.java and try on line 8:
1) Type "@L" and Ctrl+Space --> @Local and @LocalHome annotations are suggested. This is wrong.
2) Type "@" and Ctrl+Space --> No annotation is suggested at all. This is wrong. Example for valid annotation that has to be suggested is @EJB
3) Type "loc" and Ctrl+Space --> @Local annotation is suggested. This is wrong, too - No "@" char is typed before "loc". The result of the code completion is "Local" instead of "@Local".
Hope this helps for the identification of the root cause.
Reply to comment 2 The test case is: public class FakeEJB { //completion location private int variable; } 1) Currently code assist doesn't attach the completed annotation to the following element, therefore codeassist is unable to filter an annotation with the wrong target level. But even if the completed annotation was attached to the following element, codeassist must not filter proposals with the wrong target level because the following element can be unrelated with the completion. With this test case: @Target({TYPE}) @interface MyAnnot { } public class FakeEJB { @MyAnn // complete at | location private int variable; } the intent of the user can be to write: public class FakeEJB { @MyAnnot class MemberClass {} private int variable; } However the relevance of these kinds of proposals should be lesser because i think most of the time the user want to add an annotation to the following element. 2) It's fixed in 3.3 M2 (see bug 129983) 3) The completion 'Local' is valid because the it's possible to write the following code: Local l; private int variable; But this proposal should be less relevant than other type proposals because use an annotation type as a variable type is not the common case. We need to improve relevance computation for annotation completion. As there is several issues described in this bug,, i opened a separate bug for issue 3) bug 184178 Created attachment 64989 [details]
Proposed fix for issue 1)
With this fix
- Annotations which target the same ElementType as the following node are more relevant than others.
- Annotations which don't target the same ElementType as the following node are proposed except if the completion is at top level types level. In this case only annotations of types can be possible.
package p;
@A|
public class X {}
Currently when the completion is inside the statements part of a method body the completion parser recovery isn't reliable to associate annotations to the correct node.
void foo() {
@Lo|
{
int var;
So this fix give the same relevance for all annotations inside method body to avoid to compute wrong relevances. This case would be fixed later as it require a deeper completion recovery improvement.
Released for 3.3M7. Test added CompletionTest_1_5#test0301() -> test0329() Verified for 3.3M7 using I20070427-0010 based on what can be done stated in comment 5. However I found weird to get a proposal for long in case 1) comment 2. Once I take it, I end up with: @long .... and this is wrong. Should I open a bug report for this one ? Verified. This is a bug. Base types shouldn't be proposed. Could you open a bug report ? Closing |