JDK-6919889 : assorted position errors in compiler syntax trees
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2010-01-25
  • Updated: 2012-01-13
  • Resolved: 2012-01-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b84Fixed
Related Reports
Duplicate :  
JDK-6654037 - JCTree.pos may be incorrect for BinaryTrees
Duplicate :  
JDK-6599152 - End positions incorrect for certain trees
Relates :  
JDK-6919944 - incorrect position given for duplicate annotation value error
Relates :  
JDK-6922429 - extend tree position test waiver
Description
Various minor errors in the position info for tree nodes in JCTree nodes have been identified by a new test program TreePosTest.java when the test program is run over various code bases, such as langtools/test, langtools/src/share/classes, etc.

These errors should be fixed.
Comments
EVALUATION Fix affects some golden file tests. test/tools/generics/diamond/neg/Neg0*.java position for a wildcard such as "? extends String" is moved from beginning of "String" to the "?" OLD: test/tools/javac/generics/diamond/neg/Neg02.java:20: type parameter ? extends String is not within its bound Foo<? extends String> f2 = new Foo<>(""); //new Foo<Integer> created ^ NEW: test/tools/javac/generics/diamond/neg/Neg02.java:20: type parameter ? extends String is not within its bound Foo<? extends String> f2 = new Foo<>(""); //new Foo<Integer> created ^
25-01-2010
EVALUATION Most errors in the parser are minor, such as omitting a call to to(...) or toP(...) to set the end positions for the node. The most significant part of the fix is to maintain an extra stack while reading binary expressions -- this stack maintains the position info for the corresponding entries in the operator stack. There are still some outstanding issues not addressed by the fix: -- position info for annotation nodes -- position info for TypeArray nodes -- position info for enum meber declarations, which are desugared in the parser
25-01-2010