Summary: | [1.5][search] Types search does not work with generics | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Frederic Fusier <frederic_fusier> | ||||
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | ||||||
Version: | 3.1 | ||||||
Target Milestone: | 3.1 M4 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Frederic Fusier
2004-10-05 10:18:02 EDT
Currently search for declaration already works for generic types. Search needs improvement for references only. The thing really new with generic types is that we not only search the type itself but user can now search a specific instance of the type. For example, when user is searching for 'List' it can be the generic type list or the raw type. First implementation of this search for generic will assume following rules: 1) All selected IType will be considered as the generic type. This means that no matter whether user has selected List or List<String> , selected element will always be generic type List<T>. 2) All type patterns (as List<String> for example) will be considered as parameterized type. Saying that, this bug address following kinds of search: 1) References to generic types Due to rule 1, this search occurs while selecting a type in editor, outline view or package explorer and search for its references 2) References to raw types Due to rule 2, this can be done only using Search dialog (for example enter 'List' pattern in dialog and search for types references) 3) References to parameterized types Again, due to rule 2, this can be done only using Search dialog (for example, enter 'List<String> in dialog and search for type references) Note that search 1) and 2) return same matches which differ by selection. Search 1) matches selections are only on type name although those of search 2) include also type arguments. Note also that wildcard are allowed for search 3). For example, enter pattern 'List<? extends Exception>' will match List<Exception> and List<RuntimeException> but will miss List<Object> references. Reversly, pattern 'List<? super Exception>' will match List<Exception> and List<Object> references but will miss List<RuntimeException>... Partially fixed and released in HEAD. Following points still need implementation: 1) Support search references for parameterized types selected from editor 2) Support parameterized types patterns with several type arguments Ex: Generic<Exception>.Member<Exception> 3) Support parameterized types patterns with nested type arguments Ex: Generic<List<String>> I will attach patch files for this implementation to show detail of changes done in code and test cases added... Note that I will not change resolution to FIXED until remaining points 1) and 2) are not fixed. Point 3) has a lower priority and could be fixed in a separated bug if necessary... Created attachment 15034 [details]
Patch files for initial implementation
Zip file contains both patch for org.eclipse.jdt.core changes and test cases
added in org.eclipse.jdt.core.tests.model
Fixed and released in HEAD. Now rule 1) of comment 1 has changed since CodeSelect supports generic types. So, search will now perform two different kind of search: 1) search to generic type performed each time user will select a generic type, a raw type, the identifier of a parameterized type ("List" from "List<String>" for example) or enter a type name (qualified or not) in Java Search dialog. 2) search to parameterized type performed each time user will select a parameterized type (ie. by selecting "List<String>", just put cursor in it) or enter a parameterized type name in Java Search dialog. Now parameterized types with several and/or nested type arguments are supported. So references to Generic<Exception>.Member<Exception> and List<List<String>> will be found wherever used in Java search scope... JavaSearchGenericTypeTests has been completed to take into account CodeSelect new functionality. Verified in 200412140800. So far the testing was fine. |