Community
Participate
Working Groups
I20060213-0010 Bug 119203 comment 5 indicates that the search engine currently does not resolve references to types/methods/fields from class files, but rather creates an AST on the attached source and then tries to resolve from there. This can lead to unexpected search results if the classpath is not 100% complete and the source cannot be compiled without errors (bug 119203, bug 127048). If instead the already resolved reference in the classfile would be consulted, then the reference would always be accurate (or non-matching, if then qualifier is different).
Philippe, Olivier, I definitely need your class file knowledge to help me to figure out what can be done here...
Defer post 3.2
Any chance this bug will be fixed within the 3.3 timeframe?
Reopen as we may consider it for 3.4...
It really sounds strange now that annotation references are found in class files without source (bug 211366) but other references to a type are not found.
(In reply to comment #6) > It really sounds strange now that annotation references are found in class > files without source (bug 211366) but other references to a type are not found. > That means we need to fix this bug for 3.4. This should make you happy ;-) Bug 211366 was fixed first and put in 3.4M4 as it was initially opened as critical!
Do we want to return potential matches as well? For example, if you are looking for a method reference where the method takes an int as a parameter, do you want a potential match for a method reference with the same name but no parameter ? I can return this as a potential match or I can simply return only exact matches.
I would expect the same as in the source case.
The problem is that if in the source, you search for a method foo(String) I cannot be sure that this is matching foo(java.lang.String). So this would be a potential match, whereas I can get an exact match if the type is fully qualified. I'll check how this is handled in the source case.
Yes we want potential matches. However a method with different number of parameters is not a potential match. A potential match is a match where the resolution failed (e.g. the method binding is null). If the user searches for "foo(String)" (without qualifing String), then "foo(java.lang.String)" and "foo(p.String" are both exact matches. For the .class file case, I think we can only have potential matches in the case of the missing type case (see bug 196200), i.e if the .class file was compiled and some types it references were missing. So we will have the exact same behavior in the source case and in the binary case iff the source is complete.
Created attachment 91338 [details] Olivier's initial patch Olivier provided an initial patch which returns matches for fields and methods references but not fully tested.
I'll continue for types references and write complete tests for this new functionality. Only for M7 as I have other API changes to write before M6...
Created attachment 96476 [details] Olivier's patch on top of HEAD
Jerome, I had no other input than Olivier's patch updated on top of HEAD. Thanks
We ran out of time for 3.4. Deferring to 3.5
Created attachment 111674 [details] Olivier's patch updated for 3.5
(In reply to comment #0) > I20060213-0010 > > Bug 119203 comment 5 indicates that the search engine currently does not > resolve references to types/methods/fields from class files, but rather creates > an AST on the attached source and then tries to resolve from there. This can > lead to unexpected search results if the classpath is not 100% complete and the > source cannot be compiled without errors (bug 119203, bug 127048). > > If instead the already resolved reference in the classfile would be consulted, > then the reference would always be accurate (or non-matching, if then qualifier > is different). The reference would indeed be accurate but it would contain no source position. I.e. if the user double-clicks on the result in the Search view, it will not show the position of the reference in the attached source. It would be a regression. However implementing method/field/type references for .class files with no source attached would be an improvement.
> The reference would indeed be accurate but it would contain no source position. > I.e. if the user double-clicks on the result in the Search view, it will not > show the position of the reference in the attached source. It would be a > regression. Good point. I guess the line number attributes in the class file could sometimes be used to select at least the matching line, but debug info is optional and it may be hard to implement for type references. So I agree it's better to live with inaccurate matches in this case for now (until bug 110176 gives hierarchical classpaths).
Comment on attachment 111674 [details] Olivier's patch updated for 3.5 This patch does not respond to desired functionality. It only finds references in .class files which do not have any attached source but still parse sources first when available...
See bug 247045 to follow work progress on finding references in .class files without sources...
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
