Open HeikoKlare opened 11 months ago
Did a lot of research over this topic. Came across a few interesting things:
What I tried doing:
The twist in the plot
Conclusion: Hence we can conclude that there is something wrong with the parser and it should not be parsing it as a CompletionOnMessageSendName but CompletionOnQualifiedNameReference.
Another Observation is that when we have a type cast in the following statement followed by a method call, this issue is specific to that case. On printing the scanner in 2 cases, it looks like this:
When we have a following statement which satisfies the condition mentioned above:
public boolean doItFaulty() {
while (true) {
Integer k = 0;
k.
((Object)k)
===============================
Starts here -->.<-- Ends here
===============================
getClass();
}
When there's no satatement as mentioned:
public boolean doItFaulty() {
while (true) {
Integer k = 0;
k.
// ((Object)k).getClass();
In other words, the parser parses for the following statements:
k. ((Integer)k).getClass();
as:
<CompleteOnMessageSendName:k.()>.getClass()
Issue: https://github.com/eclipse-jdt/eclipse.jdt.core/issues/1770
Current Behavior
Under specific conditions, content assist provides proposals as expected in the context. Consider the following code:
Opening auto-completion proposal after the
i.
does not provide content assist fori
but for its context:The conditions for this problems I found so far are as follows:
Expected Behavior
The content assist should provide the methods of
i
as proposals, same as when one of the conditions above is not fulfilled. For example:shows: