NullArgumentForNonNullParameter thrown by Error Prone about error-prone HOT 11 CLOSED

Yes definitely! It wasn't super reproducible but I'll let you know if I see it again.

from error-prone.

Just FYI I still haven't seen this error again, so feel free to close.

from error-prone.

Thanks. Most of the actual Error Prone team is OOO this week, but I wrote this check, so I'm seeing how easily I can have a look.

Given how much Google's security policies discourage the use of Docker, I've been trying to see if there's a shorter path to reproducing this. I've managed to install scala and sbt, kick off sbt from within server, and run build. That built successfully. Do you see the failure you posted at head (e9f8449aaa13f6402ad41fb3acc14a8b33ad8eff in my clone), or does it appear only with local changes?

from error-prone.

In any case, this whole failure is interesting:

• https://github.com/google/error-prone/blob/v2.23.0/core/src/main/java/com/google/errorprone/bugpatterns/nullness/NullArgumentForNonNullParameter.java#L102
• https://github.com/google/error-prone/blob/v2.23.0/core/src/main/java/com/google/errorprone/bugpatterns/nullness/NullnessUtils.java#L263
• https://github.com/google/error-prone/blob/v2.23.0/check_api/src/main/java/com/google/errorprone/util/ASTHelpers.java#L1207

It looks to me like we have a symbol for which isConstructor is true but for which enclosingClass returns null. At least under JDK11 (which might be what sbt is using on my machine?), I don't see how we could have a MethodSymbol with a null owner (which is what enclosingClass returns) without getting an NPE in the MethodSymbol constructor... unless somehow it gets overwritten later?

As an aside, I'm not sure that my enclosingClass(constructedClass) check could possibly work: If I'm reading it right, that should call constructedClass.enclClass(), which should return constructedClass itself....

from error-prone.

(isContructor() is implemented as a check against the name <init>. I suppose it's possible that something uses that as a name for a non-constructor? Do you have Scala deps? That still seems like a long shot. I'm probably missing something obvious.)

from error-prone.

I realized I misspoke in my original report: The error happens when running browser tests locally, not when running the server. https://github.com/civiform/civiform/wiki/Testing#functional-browser-tests are our browser test directions (specifically bin/run-browser-test-env).

But, it actually looks like I can no longer reproduce the error. Earlier today, I was working on a few different local PRs (civiform/civiform#6254, then civiform/civiform#6272 which is stacked on top) and I had one of those PR branches checked out when I started seeing the error. What I just did was:

1. Checkout main
2. run bin/run-browser-test-env -- works fine.
3. Checkout civiform/civiform#6254.
4. run bin/run-browser-test-env -- works fine.
5. Checkout civiform/civiform#6272.
6. run bin/run-browser-test-env -- works fine.

It seems like something got temporarily mangled, but checking out main un-mangled it somehow?

Since I can't repro and don't have good repro steps, feel free to close as not reproducible.

from error-prone.

Thanks. I'll see if the aforementioned real Error Prone team has any thoughts upon their return. It does seem believable that some file got mangled or something.

In any case, I am going to look more into this whole "I'm not sure that my enclosingClass(constructedClass) check could possibly work" concern. So we will get something out of this one way or another :)

from error-prone.

Oh, I'm wrong: It works fine because the call to enclClass() is made on sym.owner, not on sym. (It's possible that ASTHelpers.enclosingClass() was implementing the same unfortunate behavior as enclClass() up until cl/153079032, when cushon@ gave it the behavior that I need.)

I should probably still have a test for this.

And this is a reminder that it's nice not to have to deal with enclosing classes at all.... Really, the more checking that we can do just based on questions like "Is the target type here a primitive type?" (like https://errorprone.info/bugpattern/NullTernary), the better. Probably NullArgumentForNonNullParameter should handle primitive types differently or leave that to another future checker. Anyway, I digress.

from error-prone.

I don't have any theories about how that NPE could have happened. I don't know much about the interaction between sbt and javac. My current best idea is to add a more descriptive assertion that would catch that NPE, and see if it happens again.

from error-prone.

@caitlinshk I added an assertion that should print more information if this happens again and released that change as v2.24.1, can you try updating your build to use the latest version and let us know if you see this crash again?

from error-prone.

Thanks for following up!

from error-prone.