search

typetools / checker-framework

Pluggable type-checking for Java
http://checkerframework.org/
Other
1.01k stars 352 forks source link

error: AsSuperVisitor: type is not an erased subtype of supertype. #6753

Open vishnukk opened 1 month ago

vishnukk commented 1 month ago

Upgraded checker framework to 3.46.0. Seeing lots of failures with detail except one. I have temporarily suppressed other errors. There is no reference to it anywhere in the log. Tried with -X. Still Nothing. How do figure out where the error is coming from?

[INFO] 100 warnings 
[INFO] -------------------------------------------------------------
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] error: AsSuperVisitor: type is not an erased subtype of supertype.
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  02:03 min
[INFO] Finished at: 2024-08-09T14:07:24+05:30
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project config-ms: Compilation failure
[ERROR] error: AsSuperVisitor: type is not an erased subtype of supertype.
[ERROR] 
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
mernst commented 1 month ago

Can you please provide the source code (or a minimized version, if it contains secret IP)? Without that, it is very hard for us to understand and reproduce the problem.

vishnukk commented 1 month ago

It is a huge code base that i can't share. And I have no idea where the error is coming from. So I can't create sample project project to reproduce it. Is there a way to figure where the error is coming from?

mernst commented 1 month ago

I understand.

Maven has known bugs regarding not displaying certain warnings. I'm not positive that is the problem here, but it would be helpful to rule it out.

Could you please run mvn with the -X command-line argument, and find the exact Java command that it is running? (You might need to make Maven fork the compilation process.) Then, please paste that command directly into the command shell, and you should see the diagnostics as the Checker Framework produces them. I expect that will be more informative (but if it is not, please let us know).

There are some Checker Framework command-line arguments you can supply, within or outside Maven:

I hope this helps.

msridhar commented 1 month ago

Not sure if you tried it already but it looks like there is an -e option that might lead to stack traces being printed

kelloggm commented 1 month ago

It is a huge code base that i can't share.

We've been working on an experimental tool that can generate a small test case from your huge code base, if you can locate the part of the program (e.g., the method) that triggers the crash. This new tool is available here: https://github.com/njit-jerse/specimin.

I'd love to know if you find it helpful for generating a reproducer for this crash you're experiencing, and if you decide to give it a try and run into any trouble I'd be happy to provide support.

vishnukk commented 1 month ago

I understand.

Maven has known bugs regarding not displaying certain warnings. I'm not positive that is the problem here, but it would be helpful to rule it out.

Could you please run mvn with the -X command-line argument, and find the exact Java command that it is running? (You might need to make Maven fork the compilation process.) Then, please paste that command directly into the command shell, and you should see the diagnostics as the Checker Framework produces them. I expect that will be more informative (but if it is not, please let us know).

There are some Checker Framework command-line arguments you can supply, within or outside Maven:

  • -Afilenames tells which file is being processed and may help you localize the problem
  • -AdumpOnErrors produces a bit more diagnostic output when the Checker Framework errs
  • -doe to produce a stack trace whenever the Checker Framework prints a warning or error

I hope this helps.

I have the following argument In the command -processor lombok.launch.AnnotationProcessorHider$AnnotationProcessor,org.checkerframework.checker.nullness.NullnessChecker,org.checkerframework.checker.interning.InterningChecker,org.checkerframework.checker.formatter.FormatterChecker

Running it gives Could not instantiate an instance of processor 'lombok.launch.AnnotationProces

Removing "lombok.launch.AnnotationProcessorHider$AnnotationProcessor" gives

An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.IllegalAccessError: class org.checkerframework.javacutil.AbstractTypeProcessor (in unnamed module @0xd6da883) cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.processing to unnamed module @0xd6da883
    at org.checkerframework.javacutil.AbstractTypeProcessor.init(AbstractTypeProcessor.java:97)
    at org.checkerframework.framework.source.SourceChecker.init(SourceChecker.java:609)
    at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.<init>(JavacProcessingEnvironment.java:699)
    at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(JavacProcessingEnvironment.java:826)
    at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:922)
    at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1265)
    at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1380)
    at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1279)
    at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946)
    at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
    at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
    at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:66)
    at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)

If I remove the entire '-processor' It compiles successfully with warning as in maven command.(Without the error) But still nothing related to [error: AsSuperVisitor: type is not an erased subtype of supertype.]

vishnukk commented 1 month ago

Not sure if you tried it already but it looks like there is an -e option that might lead to stack traces being printed

Tried that. Gives no hint With -X and -e I get the following

[INFO] 100 warnings 
[INFO] -------------------------------------------------------------
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] error: AsSuperVisitor: type is not an erased subtype of supertype.
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  02:01 min
[INFO] Finished at: 2024-08-12T12:17:20+05:30
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project config-ms: Compilation failure
[ERROR] error: AsSuperVisitor: type is not an erased subtype of supertype.
[ERROR] 
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project fabric-configuration-ms: Compilation failure
error: AsSuperVisitor: type is not an erased subtype of supertype.

    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions (MojoExecutor.java:355)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:200)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:103)
    at java.lang.reflect.Method.invoke (Method.java:580)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: Compilation failure
error: AsSuperVisitor: type is not an erased subtype of supertype.

    at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:1310)
    at org.apache.maven.plugin.compiler.CompilerMojo.execute (CompilerMojo.java:198)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions (MojoExecutor.java:355)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:200)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:103)
    at java.lang.reflect.Method.invoke (Method.java:580)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
vishnukk commented 1 month ago

It is a huge code base that i can't share.

We've been working on an experimental tool that can generate a small test case from your huge code base, if you can locate the part of the program (e.g., the method) that triggers the crash. This new tool is available here: https://github.com/njit-jerse/specimin.

I'd love to know if you find it helpful for generating a reproducer for this crash you're experiencing, and if you decide to give it a try and run into any trouble I'd be happy to provide support.

I guess I have to first find the error source

vishnukk commented 1 month ago

I noticed that it fails with 3.45.0 and 3.46.0. But passes with 3.44.0

michelkaeser commented 1 month ago

I had the same error and was able to compile successfully just now. Issue was with generics and "redundant" casts (which checker seems to require).

Following code causes issues:

Set<MyClass> resources = incomings == null ? Set.of() : incomings.stream().map(incoming -> map(incoming)).collect(Collectors.toSet()));

and I had to explicitly add the type information to Set.<MyClass>of().

Just as context, IntelliJ had the same issue for a while where I was told that a cast is needed but javac had no issues with it.

The actual code had more nesting so this is a simplified example. If it's not helpful like this I need to invest time to extract the error case I had.

smillst commented 1 month ago

I had the same error and was able to compile successfully just now. Issue was with generics and "redundant" casts (which checker seems to require).

Following code causes issues:

Set<MyClass> resources = incomings == null ? Set.of() : incomings.stream().map(incoming -> map(incoming)).collect(Collectors.toSet()));

and I had to explicitly add the type information to Set.<MyClass>of().

Just as context, IntelliJ had the same issue for a while where I was told that a cast is needed but javac had no issues with it.

The actual code had more nesting so this is a simplified example. If it's not helpful like this I need to invest time to extract the error case I had.

I created a small test case from this code snippet:

import java.util.Collection;
import java.util.Set;
import java.util.stream.Collectors;

public class Issue6753 {
  static class MyClass{}
  void method(Collection<MyClass> incomings){
    Set<MyClass> resources = incomings == null ? Set.of() : incomings.stream().map(incoming -> map(incoming)).collect(
        Collectors.toSet());

  }

  private MyClass map(MyClass incoming) {
    throw new RuntimeException();
  }
}

And it doesn't cause a crash. I had to guess at the signature of incomings and map, so if they are more complicated that could be part of the crash.

But in general adding explicit type argument may be a work around for a crash like this.

michelkaeser commented 1 month ago

This represents the code in question on my end:

import java.util.Set;
import java.util.concurrent.Callable;

public class Issue6753 {

    interface TransactionRunner {
        <T> T call(Callable<T> task);
    }

    static abstract class PanacheEntityBase {
        <T extends PanacheEntityBase> PanacheQuery<T> filter(String filter) {
            return null;
        }
    }

    interface PanacheQuery<Entity> {
        <T extends Entity> Set<T> list();
    }

    static class MyClass extends PanacheEntityBase {}

    public static void main(String...args) {
        Set<MyClass> resources = new TransactionRunner() {
            @Override
            public <T> T call(Callable<T> task) {
                try {
                    return task.call();
                } catch (Exception e) {
                    throw new RuntimeException(e);
                }
            }
        }.call(() -> {
            if (args.length > 1) {
                return new MyClass().filter("").list();
            } else {
                return new MyClass().filter("").list();
            }
        });
    }

}

It is working with these casts/explicit type parameters:

import java.util.Set;
import java.util.concurrent.Callable;

public class Issue6753 {

    interface TransactionRunner {
        <T> T call(Callable<T> task);
    }

    static abstract class PanacheEntityBase {
        <T extends PanacheEntityBase> PanacheQuery<T> filter(String filter) {
            return null;
        }
    }

    interface PanacheQuery<Entity> {
        <T extends Entity> Set<T> list();
    }

    static class MyClass extends PanacheEntityBase {}

    public static void main(String...args) {
        Set<MyClass> resources = (Set<MyClass>) new TransactionRunner() {
            @Override
            public <T> T call(Callable<T> task) {
                try {
                    return task.call();
                } catch (Exception e) {
                    throw new RuntimeException(e);
                }
            }
        }.call(() -> {
            if (args.length > 1) {
                return new MyClass().<MyClass>filter("").list();
            } else {
                return new MyClass().<MyClass>filter("").list();
            }
        });
    }

}
vishnukk commented 1 month ago

I finally got the issue fixed. I had to delete all files and revert one by one to check the source of the error

public static void analyze(Map<String, List<? extends ConfigClientViewObject>> importContentMap) {
        final var map = importContentMap.entrySet()
                .stream()
                .flatMap(importMap -> ImportHelper.updateConfiguration(importMap).entrySet().stream())
                .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue,
                        (v1, v2) -> v2, LinkedHashMap::new));

        importContentMap.clear();
        importContentMap.putAll(map);
    }

The fix was to specify the linkedhashmap type

public static void analyze(Map<String, List<? extends ConfigClientViewObject>> importContentMap) {
        final var map = importContentMap.entrySet()
                .stream()
                .flatMap(importMap -> ImportHelper.updateConfiguration(importMap).entrySet().stream())
                .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue,
                        (v1, v2) -> v2, ()-> new LinkedHashMap<String, List<? extends ConfigClientViewObject>>()));

        importContentMap.clear();
        importContentMap.putAll(map);
    }

Thanks @michelkaeser for the hint. Thanks @msridhar @mernst for the support

smillst commented 1 month ago

I finally got the issue fixed. I had to delete all files and revert one by one to check the source of the error

Sorry it was so difficult to find the code that was causing the crash. Checker Framework exception messages do print which line caused the crash, but it is not in the first line. I've added an option, -AexceptionLineSeparator=" : ", to make the exception message one line. That should make it easier in the future to report Checker Framework crashes.

I've also made changes so that this sort of crash will cause an error message rather than crashing. That way you can just suppress the warning.

Both these changes should be in the Sept. 3rd release.

I'm also working to fix the bugs in the type argument inference code and will make sure these test case pass. Thanks for reporting these issues and all the effort to make testcases!