RFR: 8361499: Intersection type cast causes javac crash with -Xjcov

[Vicente Romero]

On Wed, 9 Jul 2025 10:30:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> After TransTypes decomposes an intersection type in its components, there is no point keeping the intersection AST around. This could lead to errors in the backend. This PR is proposing lowering the intersection AST to it's first component,
>> 
>> TIA
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java line 1145:
> 
>> 1143: 
>> 1144:     public void visitTypeIntersection(JCTypeIntersection tree) {
>> 1145:         result = translate(tree.bounds, null).head;
> 
> Are we 100% sure that the type of the new result is the same as the old one? I'm trying to locate what `erasure(tree.type)` might have done -- but I can't see any code in `Types.erasure` that deals with intersections??

The way the compiler deals with the erasure of intersections is a bit convoluted. Basically when the class symbol representing the intersection is created, its erasure is preset to its first explicit bound, provided that it is not a type variable. The code is at `Types::makeIntersectionType`. Later on, if `Types::erasure` is invoked on the intersection type, this already erased type is just read and returned, see method `visitClassType` at the erasure visitor in `Types`. Pasted below:

           public Type visitClassType(ClassType t, Boolean recurse) {
                Type erased = t.tsym.erasure(Types.this);
                if (recurse) {
                    erased = new ErasedClassType(erased.getEnclosingType(),erased.tsym,
                            t.dropMetadata(Annotations.class).getMetadata());
                    return erased;
                } else {
                    return combineMetadata(erased, t);
                }
            }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26203#discussion_r2195630514