Community
Participate
Working Groups
Created attachment 149624 [details] Proposed patch HEAD Here is a fragment of the java grammar from java.g on HEAD CastExpression ::= PushLPAREN Name PushRPAREN InsideCastExpressionLL1 UnaryExpressionNotPlusMinus InsideCastExpressionLL1 ::= $empty /.$putCase consumeInsideCastExpressionLL1(); $break ./ org.eclipse.jdt.internal.compiler.parser.Parser.consumeInsideCastExpressionLL1() looks like: protected void consumeInsideCastExpressionLL1() { // InsideCastExpressionLL1 ::= $empty pushOnExpressionStack(getUnspecifiedReferenceOptimized()); } and where getUnspecifiedReferenceOptimized() constructs a SingleNameReference or QualifiedNameReference as the case demands. Intuitively as well per spec the Name here is guaranteed to be a Typename (JLS3.0, page 128, 6.5.1) and so we should be constructing a TypeReference. The 4 other productions for CastExpression use TypeReference and the production above is the only one that constructs a NameReference. To give some context as to why this matters - JSR308 adds type annotations to java and so TypeReferences must now be enhanced to capture annotations. Name here is really a TypeReference, but if it was coded to be a NameReference for some unalterable reason, we would need to add annotations fields to these types also.
Olivier, please review, this change is going to be needed to avoid adding annotations to NameReference's and to support type annotations on a construct like: String s = (@Readonly String) o; I would like to treat this as a separate issue and fix it ahead of the JSR308 work.
David, Do you see any issues with this patch ? Thanks for giving it a once over.
I think we should not change the tests in InnerEmulationTest as proposed in the patch. We should modify the problem reporter to better locate the portion of the type that is reported as deprecated inside a QualifiedTypeReference or a QualifiedArrayTypeReference. I'll propose a new patch once all tests are run and updated if necessary.
Created attachment 149660 [details] Proposed fix + updated regression tests Srikanth, please let me know what you think.
(In reply to comment #4) > Created an attachment (id=149660) [details] > Proposed fix + updated regression tests > Srikanth, please let me know what you think. I felt comfortable with the change to InnerEmulationTest since the change was making the behavior for cast type consistent with the all other type usage, but I agree we may as well make the partial type location more precise uniformly. I think there is a problem with the patch as it is: Given : /** @see Type.Inner.InnerMost */ public class X { } and public class Type { /** @deprecated */ public class Inner { public class InnerMost { } } } With compiler deprecated usage reporting set to ignore and javadoc deprecated usage reporting set to warning/error, I see two messages on HEAD vs just one with the patch. I'll try and repair the patch.
Created attachment 149730 [details] Test patch showing problems The attached patch contains tests that show some problems with the proposed fix: - Sometimes instead of reporting IProblem.JavadocUsingDeprecatedType, we incorrectly report IProblem.UsingDeprecatedType - IProblem.JavadocUsingDeprecatedType reporting continues to fail to demarcate partial types in messages. - We also need to inspect the code to see if there are other places we should be using nodeSourceEnd(null, location), instead of location.sourceEnd Since this issue is preexisting & completely unrelated to the current defect and furthermore not a regression with the original patch, I propose that we release the original patch as it is and deal with this issue on a new separate defect basis.
Created attachment 149738 [details] Reproposed patch Releasing in HEAD for 3.6M3 I have raised bug#292510 as a follow up for the open issues.
Released in HEAD for 3.6M3.
(In reply to comment #6) > Since this issue is preexisting & completely unrelated to the current > defect and furthermore not a regression with the original patch, I > propose that we release the original patch as it is and deal with this > issue on a new separate defect basis. Sounds fair.
Verified for 3.6M3 using build I20091026-2000
