Community
Participate
Working Groups
Looks like the AspectsConvertingParser is not properly setting up the buffer for content assist inside of an ITD so that ITDs on target fields cannot be found.
In AJCompilationUnit.codeComplete, there is a line: ((ProposalRequestorFilter)requestor).setAcceptMemberMode(false); What this does is that it filters out all method and field ref proposals. Presumably, this was set so that aspect fields do not erroneously appear as content assist proposals, but this also filters out method and field ref proposals from local variables. Setting this to true, will mean that field and method refs from local vars will appear (good), but non-static aspect fields and methods will also appear (bad). What needs to happen here is to have better analysis and use the following to filter proposals: Is the field or method ref non-static and coming from the aspect? If so filter, otherwise, don't filter.
OK. Did a bit of work here cleaning things up. Also, found some more issues related to bug 283030. I am now confident that that bug is fixed. The problem here, more specifically is in this situation. Inside of an ITD, content assist happens in 2 phases. In phase 1, a "this" field is prepended to the completion location (where "this" corresponds to a type of the target type. Eg- void Foo.x() { <here> } becomes void Foo$x() { Foo ___ITD___; ___ITD___.<here> } This allows the collector to pick up all declarations inside the target type and supers. Then, content assist is run again without this mock local variable: void Foo$x() { <here> } This time the collector is configured to ignore methods and fields (because they would presumably be coming from the aspect and should be ignored). So, this allows the collector to get the local variables. This works fine in the above situation and when content assist is on a prefix of a local variable or declaration from the target type. However, in this situation, there is a problem: void Foo.x() { List g = new LinkedList(); g.<here> } In the first iteration of content assist, the "___ITD___" variable is prepended and since g is coming from the target type, this yields no results. In the second iteration, all of g's methods (from List) are found but are filtered out for reasons described above. The way to solve this is to be able to determine when we are in the first situation vs the second situation. The difference between the two will be whether or not we apply filtering in the second iteration. We need to be able to check back from the completion position to the start of the current statement and see if there is a '.', which indicates that we should not do the filtering.
Fixed with regression tests.
