This is a SUNBUG for https://bugs.openjdk.java.net/show_bug.cgi?id=100115
Description From Jan
Created an attachment (id=164) [details]
Proposed patch.
Consider the following type:
List<? extends List<? extends String>>
the source positions produced by JavacParser/EndPosParser are not correct for
the type argument of the outer type ("? extends List<? extends String>"): the
start position is the second '<', the end position is before the '>>' (i.e. the
text covered by the positions is: "<? extends String").
The fix for the positions is twofold:
-starting position: creation of the WildcardTree/JCWildcard is done as follows:
"F.at(pos).Wildcard(t, parseType())". As parseType() is this case changes the
selected position in F, the starting position of the created tree is incorrect.
Can be fixed by:
JCExpression type = parseType();
result = F.at(pos).Wildcard(t, type);
-ending position: as '>>' is one lexical token, the most appropriate end
position for the bound is inside this token. Can be solved by correcting "pos"
and "prevEndPos" in Scanner.token(Token):
this.pos += this.token.name.length() - token.name.length();
this.prevEndPos = this.pos;
A patch (against changeset a491ad1bb624 from
http://hg.openjdk.java.net/jdk7/tl/langtools) is attached, that does these two
changes. It also contains a test
(test/tools/javac/positions/WildcardPositionsTest.java) which tests positions
sanity (the children positions are inside positions of their parent) and
correct positions of the wildcard type argument. As a consequence of changing
the, positions of some errors reported by javac changed, namely in
test/tools/javac/generics/diamond/neg/Neg0[1-4]. As I consider the new
positions of the errors to be more appropriate, the patch also changes the
"out" files for these test.
Thanks.
Description From Jan
Created an attachment (id=164) [details]
Proposed patch.
Consider the following type:
List<? extends List<? extends String>>
the source positions produced by JavacParser/EndPosParser are not correct for
the type argument of the outer type ("? extends List<? extends String>"): the
start position is the second '<', the end position is before the '>>' (i.e. the
text covered by the positions is: "<? extends String").
The fix for the positions is twofold:
-starting position: creation of the WildcardTree/JCWildcard is done as follows:
"F.at(pos).Wildcard(t, parseType())". As parseType() is this case changes the
selected position in F, the starting position of the created tree is incorrect.
Can be fixed by:
JCExpression type = parseType();
result = F.at(pos).Wildcard(t, type);
-ending position: as '>>' is one lexical token, the most appropriate end
position for the bound is inside this token. Can be solved by correcting "pos"
and "prevEndPos" in Scanner.token(Token):
this.pos += this.token.name.length() - token.name.length();
this.prevEndPos = this.pos;
A patch (against changeset a491ad1bb624 from
http://hg.openjdk.java.net/jdk7/tl/langtools) is attached, that does these two
changes. It also contains a test
(test/tools/javac/positions/WildcardPositionsTest.java) which tests positions
sanity (the children positions are inside positions of their parent) and
correct positions of the wildcard type argument. As a consequence of changing
the, positions of some errors reported by javac changed, namely in
test/tools/javac/generics/diamond/neg/Neg0[1-4]. As I consider the new
positions of the errors to be more appropriate, the patch also changes the
"out" files for these test.
Thanks.
- relates to
-
JDK-7073631 (javac) javac parser improvements for error position reporting
-
- Closed
-