-
Bug
-
Resolution: Unresolved
-
P5
-
8
If I modify Check.firstIncompatibleTypeArg as follows, an AssertionError is triggered:
while (args.nonEmpty() && tvars_cap.nonEmpty()) {
// Let the actual arguments know their bound
if (args.head instanceof WildcardType) {
Type oldBound = ((WildcardType) args.head).bound;
Type newBound = tvars_cap.head;
if (oldBound != newBound)
throw new AssertionError("wildcard bound mismatch in type " + type + ": "
+ oldBound + " of " + (oldBound == null ? "_" : oldBound.tsym.owner) + ", "
+ newBound + " of " + (newBound == null ? "_" : newBound.tsym.owner));
}
args = args.tail;
tvars_cap = tvars_cap.tail;
}
Example output (from an OpenJDK 'make'):
wildcard bound mismatch in type com.sun.tools.javac.util.ListBuffer<? super com.sun.tools.javac.tree.JCTree.JCVariableDecl>: E of java.util.Collection, A of com.sun.tools.javac.util.ListBuffer
I don't fully grasp the significance of the 'bound' field (or the implications of changing it), but clearly it is wrong to set it to different type parameters of different classes over the course of compilation.
I imagine the problem is due to a misuse of substitution.
while (args.nonEmpty() && tvars_cap.nonEmpty()) {
// Let the actual arguments know their bound
if (args.head instanceof WildcardType) {
Type oldBound = ((WildcardType) args.head).bound;
Type newBound = tvars_cap.head;
if (oldBound != newBound)
throw new AssertionError("wildcard bound mismatch in type " + type + ": "
+ oldBound + " of " + (oldBound == null ? "_" : oldBound.tsym.owner) + ", "
+ newBound + " of " + (newBound == null ? "_" : newBound.tsym.owner));
}
args = args.tail;
tvars_cap = tvars_cap.tail;
}
Example output (from an OpenJDK 'make'):
wildcard bound mismatch in type com.sun.tools.javac.util.ListBuffer<? super com.sun.tools.javac.tree.JCTree.JCVariableDecl>: E of java.util.Collection, A of com.sun.tools.javac.util.ListBuffer
I don't fully grasp the significance of the 'bound' field (or the implications of changing it), but clearly it is wrong to set it to different type parameters of different classes over the course of compilation.
I imagine the problem is due to a misuse of substitution.
- relates to
-
JDK-8034147 javac crashes with a NullPointerException during bounds checking
- Closed