Community
Participate
Working Groups
Created attachment 237155 [details] Couple of test cases Subwords completion doesn't find most constructors of available types when completing with a pattern like this: Deque<Path> paths = new deque| None of the available constructors from ArrayDeque, ConcurrentLinkedDeque or LinkedBlockingDeque are offered. Tested with Eclipse SDK Version: 4.4.0 Build id: I20131030-2000 Recommenders 2.0.1.v20131101-0937
Created attachment 237156 [details] Resulting proposals
Think you describe a known issue we have with JDT's type completion. Unfortunately, there is no simple fix possible yet with JDT's infrastructure. In order to fix this, one needs to 1. list of all known types in the project code completion was triggered in (potentially thousands of types), 2. has to filter all these names by subwords-matching, 3. create new type completion proposals and 4. add them to the list. While 3 and 4 are (kind of) easy, I'm not sure whether we could efficiently solve 1+2. Stephan, any idea which (maybe internal) classes we should use for step 1.?
To clarify: type completions and constructor completions have the same restrictions in JDT.
1 and 2 don't have to be that hard in this particular usage pattern. The tokens preceding the caret position have a distinctive pattern: Type TYPEOPEN Type TYPECLOSE Identifier ASSIGN NEW Hint? CARET The types mentioned have already gone through the proposal'n'acceptance cycle and their imports are in place. They might have been written to disk too (I save constantly to keep my code properly formatted). In this case Quick Type Hierarchy at the beginning of the line (press Home, Ctrl-T) would be almost exactly what I wanted to see. Could those types from earlier completions be tagged to the dirty AST temporarily until the file is saved? Then the unsaved portions of the file could have as much type information as the rest of it.
That's unfortunately not possible. Caching types used earlier and adding them into completion if not already in also feels a bit too much like magic/would be even much more inconsistent with subwords completion for methods. I'd prefer an approach that finds all available types and filters them according to the prefix. FWIW, this list of types may be cached to make this approach faster. Just to let you know: We are currently focussing on other areas and this is likely not happening in 2.0.x except someone volunteers to look into this.
I've been looking into it on and off but the different AST and type hierarchy and model APIs are numerous and connected in obscure ways. It turns out that the "magic" is not needed, the code has already been scrubbed and "compiled" by the time the completion engine gets it. My current thinking is to populate expectedTypes ObjectVector which already contains the type mentioned in the editor with all of its subtypes too. Then all that's needed is to relax the prefix test and everything should proceed from there. Now how do I get an IType from a ReferenceBinding?
Can you push a draft of what you are doing into Gerrit? I'm not sure why you need to convert a compiler binding to an IType first. But maybe I miss some details in which case the code you are writing could shed some more light on :) FWIW, converting ReferenceBinding to an IType is (AFAIK) not a frequently used approach. The only code I'm aware of that does that conversion is in org.eclipse.jdt.internal.core.search.matching.MatchLocator.lookupType(ReferenceBinding) Maybe Stephan knows a better approach. But as I said, I don't think we need that conversion (the other way is simpler :).
I really don't have much to commit. My latest foray was into trying to add subtypes at CompletionEngine.findTypesFromExpectedTypes() which got me thinking about doing it in CompletionEngine.computeExpectedTypes() instead. But both of those need the list of subtypes, which IType.newTypeHierarchy() provides. Quick Type Hierarchy uses that as well. Oh right, I also need the IType to ReferenceBinding conversion :) I'll check out MatchLocator, thanks.
Regarding subtype matches: Don't use IType.newTypeHierarchy and IType in general to do subtype checks. It's too slow. We have a prototype that uses the compiler internal bindings that works quite well. But note that even this solution causes some recognizable delays when there are hundreds to thousand of type proposals. Regarding subwords matches: This still needs a list of all available types to be filtered. We shouldn't mix these two topics in this bug. Please create a new one if you like to discuss subtype matchings.
Closing this as a duplicate of bug 377373. regarding subtype discussion in this thread: I've implemented an experimental subtype-aware type completion (which has the prefix limitations as mentioned above). If interested, please check out https://plus.google.com/100908752439953740476/posts/jfeAHvsJAC5 and provide feedback there. FWIW, I'd be glad to get rid of the prefix issue for type completions. Any patches for this feature are highly welcome. *** This bug has been marked as a duplicate of bug 377373 ***
You're in luck, I just happen to have that implemented :) Commented in bug 377373.
