Community
Participate
Working Groups
By construction, the type is always a type reference. So we should make this clear inside the CastExpression type itself so that we can actually remove a bunch of instanceof checks and clean up some code.
That cleanup would be great, but in my understanding the parser can NOT guarantee that the type is actually a type (that's how I read consumeCastExpressionLL1()). Are you thinking of making the grammar smarter or of converting the expression into a type reference inside CastExpression(Expression,Expression) ? Excuse my curiosity :)
This is what I thought initially as well, but in order to get into consumeCastExpressionLL1(), it means that the rule InsideCastExpressionLL1 was called. And this rule calls: org.eclipse.jdt.internal.compiler.parser.Parser.consumeInsideCastExpressionLL1() where the name is actually converted to a type reference. So I believe that the parser can make sure that it is always a type reference. So there is no need to change the existing grammar.
(In reply to comment #2) cool!
Created attachment 189730 [details] Possible fix First draft.
Another good reason to fix this is that this is actually mandatory to support jsr 308 (annotations on type). Srikanth, I let you review the patch. Thanks.
Created attachment 189740 [details] Proposed fix Same as before with some additional cleanup.
Olivier, is this the same issue discussed here: http://dev.eclipse.org/mhonarc/lists/jdt-core-dev/msg01909.html or a different one ?
May be not, as that issue was resolved under https://bugs.eclipse.org/bugs/show_bug.cgi?id=292364. I'll take a look.
(In reply to comment #7) > Olivier, is this the same issue discussed here: > http://dev.eclipse.org/mhonarc/lists/jdt-core-dev/msg01909.html > or a different one ? yes, but to the difference that the fix for bug 292364 didn't go as far as this one does which means that the corresponding field inside the CastExpression class should be a type refererence and not a name reference.
Released for 3.7M6. Srikanth, this will be verified in the verification phase.
For the records: For a minute I was puzzled about the additional casts to TypeReference inside CompletionParser. It turns out these are safe based on the assumption that consumeInsideCastExpression() has been called before, which in the case of the CompletionParser indeed pushes a type reference onto the expression stack.
Verified for 3.7 M6 via code inspection.
