Liam Miller-Cushon

The UnusedVariable crash looks like https://github.com/google/error-prone/issues/1250 The OverrideThrowableToString crash might be https://github.com/google/error-prone/issues/1323. Do you have a self-contained repro for that one?

The most helpful way to reproduce would be if you can minimize the proprietary code into a single small, self-contained source file that reproduces the crash and that doesn't contain...

I think that having a `-XepDisableAllSuggestions` flag would be consistent with other configuration we already have. Would that meet the requirements here? I think that internally checks with 'suggestion' severity...

> There should probably be a new annotation, or a new attribute in `@BugPattern`, to signify that the check should be disabled by default, while still providing a default severity...

Having a mechanism for indicate that plugin checks should be disabled by default, separate from their default severity, SGTM. (I see that we once had a `SeverityLevel.NOT_A_PROBLEM` to indiciate that...

Based on the stack trace the check is analyzing a method with a type parameter, but when it looks at the source code the type parameter isn't there. The config...

Thanks very much for the review! > So, overall, I am not convinced this is a good move. Yes, we have some existing cases where missing stuff produces just warnings...

I added a comment to https://bugs.openjdk.org/browse/JDK-8370800 with some more analysis. I think the core of the new behaviour that is surprising and potentially undesirable is > javac is more eagerly...

> I wonder if a better approach here is to continue to report `cant.attach.type.annotations` as an unconditional error, but to defer the work down by `addTypeAnnotationsToSymbol` until the symbol is...

I have realized this approach doesn't work for all cases, because there are public APIs that allow accessing type annotations on an `ExecutableElement` that don't result in the underlying `MethodSymbol`...