Upstreaming: A way to silence stub-file warnings about checker-framework HOT 5 CLOSED

It turns out that -AstubWarnIfNotFoundIgnoresClasses solves some but probably not all of our problem. We may want to experiment with additional flags to see if we can solve it all.

from checker-framework.

@cpovirk Could you expand on what stub-file warning messages need silencing that don't have any option yet?

from checker-framework.

Here are a couple. I don't know if the list is complete:

• "No supported annotations found! Does stub file java.util.concurrent.atomic.astub import them?"
  • We have a stub whose entirety is class AtomicReference<V> {}. (Its purpose is to override the default class AtomicReference<@Nullable V> {}.)
• "imported type not found: android.graphics.drawable.Icon"
  • We always include all our stub files, so we end up with Android stubs when building non-Android code. (But the solution is not as simple as having separate Android and non-Android stub sets: We also have stubs that apply to specific third-party libraries that may or may not be present in a given build.)

from checker-framework.

Hmm, sorry, it looks like those might be hidden by the current flags after all?

from checker-framework.

Yeah, it looks like -AstubNoWarnIfNotFound hides those. I wouldn't have guessed from the flag name or the description in the manual, and I don't know the history for why our JSpecify integration and main Checker Framework integration both set -AstubWarnIfNotFoundIgnoresClasses but not that one. (I could look.)

I could rebuild our checker without the change from #19 and see what pops up.

But actually: We recently turned off all use of stubs (JDK and otherwise) for our JSpecify integration. So even if the checker still could output some messages for stub usage, we wouldn't see them! So I think we get to not worry about this one :)

(I will have similar thoughts about #11 but sadly with more caveats.)

from checker-framework.