Proposal: make `ASTHelpers#getSymbol(MethodInvocationTree)` throw rather than return `null`

Currently, ASTHelpers#getSymbol(MethodInvocationTree) can return null if there are errors in the AST:

https://github.com/google/error-prone/blob/eda1c1456d48cb2bef38c99b5a69d4eadbe2af1f/check_api/src/main/java/com/google/errorprone/util/ASTHelpers.java#L311-L320

But does Error Prone even run when there are AST errors? If not, it would be helpful for nullability checking if this method just threw an (unchecked) exception in this case rather than returning null. I am working on running NullAway on itself (https://github.com/uber/NullAway/pull/560), and one of the most common “fixes” I had to do was to add castToNonNull around calls to ASTHelpers.getSymbol(MethodInvocationTree) because we have just been assuming it will never return null (and have never observed a case I know of where it did so).

[cushon]

I think this is worth revisiting and will be interested to see what Chris’ testing turns up.

But does Error Prone even run when there are AST errors?

It isn’t supposed to, the relevant logic is here: https://github.com/google/error-prone/blob/2fc829ec53beb33d212b977c4f96f29d3ac0eaa7/check_api/src/main/java/com/google/errorprone/ErrorProneAnalyzer.java#L119-L121

The other thing we’ll want to watch out for here is that we run Error Prone in a couple of environments where the compilation class path has been ‘optimized’ using heuristics to make it shorter. Sometimes having Error Prone try to handle missing symbols allows reporting some diagnostics when there’s missing information, especially if javac doesn’t need to load those symbols itself.

[cpovirk]

Thanks. My in-progress test includes the MemberReferenceTree overload, which I’d noticed, but not the NewClassTree one, which I had not. Depending on how that goes, I’ll see about adding NewClassTree or giving up entirely 😃