Problem with content assist and hovers of spread-dot expressions

In the case of :

[x:1,y:2,z:3]*.key.toUpperCase()

it's normal that toUpperCase() gets underlined because [x:1,y:2,z:3]*.key returns a list, so .toUpperCase() doesn't exist on List. If the inference engine underlines this :

[x:1,y:2,z:3]*.key*.toUpperCase()

Then, it is an error, because the toUpperCase method should be tested against each element.

That's right. I fixed some things in this area in the past, but it is not complete.

Underlines are indeed removed in this case:

[x:1,y:2,z:3]*.key*.toUpperCase()
[x:1,y:2,z:3]*.value*.value

See GRECLIPSE-1165 for the original bug. Although underlines are being appropriately placed, content assist and hovers are not correct, so there is work to do for this bug.

Updating title to be more reflective of the problem.

Downgrading this bug to minor and I may decide that we shouldn't do anything here at all. Content assist works correctly after a spread dot. And hovering does show the appropriate declaration of the identifier. The only thing that is misleading is that when invoking content assist in this situation:

[x:1,y:2,z:3]*.key.//<--here

Incorrect proposals are shown. Proposals for List should be shown, but proposals for String are incorrectly shown instead. Content assist is being invoked based on the type of key rather than the type of the entire expression.