Community
Participate
Working Groups
Type references like T<final X> T<@Marker static X> are silently accepted. Parser.modifier is never read in this context. Either the grammar should be changed not to allow normal modifiers in this position or we need to check and report any stored modifiers.
This is a known problem, documented under todo.txt maintained by Olivier. This todo.txt is a part of the remaining changes cached as a patch "Original implementation of code generation from 2010." in bug 383624 (https://bugs.eclipse.org/bugs/attachment.cgi?id=217920) It is a good catch from the reviewer (thanks!) and it helps that we have a bug for it rather than it sitting in some notes somewhere (I had been meaning to raise a bug ...)
(In reply to comment #0) > Either the grammar should be changed not to allow normal modifiers in this > position or we need to check and report any stored modifiers. The latter since these are introduced deliberately to avoid shift/reduce conflicts that result from just introducing annotations in these places.
Jay, we need to check other places where the grammar is extra permissive due to the use of modifiers too.
(In reply to comment #0) > Type references like > T<final X> > T<@Marker static X> > are silently accepted. When this is fixed, please verify we should see two errors in this: class X<T> { Object o = (Object) (public X<final String>) null; } Today, we get one error from this: My suspicion is that once the type parameter modifier is complained against and cleared, we will NOT complain about the "public" where we do complain today. The productions for CastExpressions do not stack the modifiers, but retrieve them directly Parser.modifier and that does not look right. Consult the productions for ReferenceExpressions, which do stack the modifiers properly.
Jay, I'll take over this bug - I ma contemplating some approaches that would dramatically simplify the grammar changes made for JSR308 that would also address this problem if it works out.
(In reply to comment #5) > Jay, I'll take over this bug - I ma contemplating some approaches that > would dramatically simplify the grammar changes made for JSR308 that > would also address this problem if it works out. The redesign alluded to above is the subject matter of bug 390784 which has been resolved. There is no further action required on this bug. The snippets from this bug have been rolled into junits and released via http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA8&id=d7c9dc580ed8a3dd6fc18ee646d5f4f1c40d11ec
