Skip serialization for elements in generated classes in Scanner #231
Conversation
nimakarimipour
changed the title
There was a problem hiding this comment.
Couple of minor comments. But I have a higher-level question. Technically, whether NullAway checks @Generated code or not is configurable via flags, see here. In fact, by default, I think NullAway will check code inside @Generated classes. This PR seems to unconditionally assume that @Generated code will not be checked, is this correct? If so, we might want to make this configurable via a flag, and probably that flag should have the same default as NullAway itself.
| @@ -122,14 +131,15 @@ public Description matchNewClass(NewClassTree tree, VisitorState state) { | |||
| if (methodSymbol == null) { | |||
| throw new RuntimeException("not expecting unresolved method here"); | |||
| } | |||
| if (methodSymbol.owner.enclClass().getSimpleName().isEmpty()) { | |||
| if (methodSymbol.owner.enclClass().getSimpleName().isEmpty() | |||
| || isInGeneratedClass(methodSymbol, state.context)) { | |||
| // An anonymous class cannot declare its own constructors, so we do not need to serialize it. | |||
| } | ||
|
|
||
| /** | ||
| * Retrieve the (outermostClass, isNullMarked) record for a given class symbol. |
There was a problem hiding this comment.
I think this copy-pasted comment is wrong, since the code around null-markedness has been removed
|
@msridhar Yes this PR unconditionally skips all serializations in generated classes. I will work on adding a controlling option for that. I think this should be an option that is provided to Annotator, and Annotator pass that to Scanner in config file rather than directly providing to Scanner. But what I am not sure of is that how we can describe this option to avoid confusion. Anything similar to |
|
@nimakarimipour I think it makes sense for NullAway for serialize the options it used to handle generated code; this would certainly be easiest. But to pass this information to the scanner, we would need to run NullAway once before running the scanner, correct? Not sure what order things are run right now. Taking a step back, #230 seems to have yielded a big performance improvement for the use case we cared about. So maybe this change can be lower priority? |
NullAway does not report any error within classes that are generated (annotated as
@Generated). This PR update all scanner serialization outputs to skip all serializations within a generated class file to reduce I/O and memory usage.