Bugzilla – Full Text Bug Listing
| Summary: | Make assistScope accessible from InternalCompletionContext | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Marcel Bruch <marcel.bruch> | ||||
| Component: | Core | Assignee: | Ayushman Jain <amj87.iitr> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | amj87.iitr | ||||
| Version: | 3.8 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Marcel Bruch
(In reply to comment #0) > Just an additional question. The compilation unit this scope belongs to is a > flat compilation unit, right? I.e., it does not contain other statements than > the completion node and its parents. Do you mean the InternalExtendedCompletionContext$compilationUnitDeclaration? Yes, it does not contain the method bodies for other methods, but only top level elements. is the current method ( the one code completion was triggered in) complete, i.e., does it contain all method calls, assignments and the like? Last time I looked at it, it only contained a small subset of statements. But I might be wrong here. (In reply to comment #2) > is the current method ( the one code completion was triggered in) complete, > i.e., does it contain all method calls, assignments and the like? Last time I > looked at it, it only contained a small subset of statements. Yes, you're right. It doesn't contain everything, but it does contain the assist node and the parent for sure. Why do you care about the other statements? Created attachment 211819 [details]
proposed fix
Something for you to play around with.
I'll add tests and release the patch if you think this suffices.
(In reply to comment #3) > (In reply to comment #2) > > is the current method ( the one code completion was triggered in) complete, > > i.e., does it contain all method calls, assignments and the like? Last time I > > looked at it, it only contained a small subset of statements. > Yes, you're right. It doesn't contain everything, but it does contain the > assist node and the parent for sure. Why do you care about the other > statements? As of 0.5 we perform an analysis of the dom.MethodDeclaration of the enclosing method. There we extract for each variable, which methods have been invoked on them, where they have been used as parameter, and how they were defined (e.g. as method return value, or parameter etc.) This information is then fed into the recommender to compute the proposals. To make this as performant as possible, we use an IElementChangedListener that stores for each ICompilationUnit its latest dom.CompilationUnit. On completion, we fetch the latest dom.CompilationUnit and perform the ast analysis using an ast visitor. I wonder how/whether this could be done in a more performant (and more straight-forward) way. Since we do the analysis every time completion was triggered, I thought, maybe performing this analysis on the compiler AST could be even fast and we wouldn't need the caching anymore. What do you think? (In reply to comment #5) > I wonder how/whether this could be done in a more performant (and more > straight-forward) way. Since we do the analysis every time completion was > triggered, I thought, maybe performing this analysis on the compiler AST could > be even fast and we wouldn't need the caching anymore. What do you think? The problem is that in case a user invokes content assist, the code is basically broken at some point, because of which recovery kicks in to recover atleast the completion node and its parent. However, we just end there because that information is sufficient to suggest proposals. Even if we did parse further to build the AST, we won't be sure of a graceful recovery, so that info will be unreliable. I don't know of any other way to do this than what you're already doing. (In reply to comment #6) > I don't know of any other way to do this than what you're > already doing. Ok. than this will be the solution for Juno. Thanks. I applied the patch and will test it this weekend. Students continue to keep me busy for two more days :) 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. If you have further information on the current state of the bug, please add it. 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. |