Fix class literal keyword semantic token

[0dinD]

Fixes redhat-developer/vscode-java#1921

The cause of the issue is that some expressions with a period after them are recovered as TypeLiterals, which causes the semantic token visitor to put a keyword semantic token there. To fix this, I added a check to avoid adding the keyword token for recovered TypeLiterals.

[0dinD]

Not sure why the test failed, it shouldn't have anything to do with my changes (and it passes when running locally on my machine).

[snjeza]

test this please

[rgrunber]

Just wanted to confirm this is the expected behaviour :

I would have thought the font of 'keyword' would have been preferred (as opposed to the bolder font) but I guess we can only guarantee the token is correct, and styling is beyond the scope of the language server. If that's the case, I'm fine with merging this.

[0dinD]

Styling is indeed beyond the scope of the language server, but the token isn't really correct either. The reason why string goes bold is that it gets assigned the class token, because JDT thinks that string. is a recovered class literal. Not sure if there's anything we can do to improve this (I imagine it would require fixes in JDT Core), and unfortunately I don't have time to investigate it right now. What we could also do as a workaround is avoid adding the token for the class if it's a recovered class literal, but I'm not sure if that would be better or worse, and if it could have any side effects. You can try it out yourself by moving this line into the if-statement below.

Note that the issue you've mentioned was present before this PR as well, so it's not a regression.

[rgrunber]

Yup, the underlying SimpleName's binding is recognized as a class it seems. I guess we can't entirely ignore the recovered nodes/bindings because there's probably cases where they make good assumptions.

Change looks good to me though.