Improve suppress/warning on signatures #267
Description
There are some problems with the code introduced in #253:
You need to add an exact signature (exactly as it is written in another (bundled) signatures file to suppress it. It also does not work when a failure is generated by some "magic" signatures like jdk-nonportable, which is using some heuristics to report a signature.
We hit the last issue in Lucene while building the Java 24 / MR-JAR code where some tricks (apijars) are used to modify compile classpath. The jdk-nonportable signatures reported a failure, we weren't be able to suppress it as it is not anywhere as plaintext in a signatures file. There was a workaround possible by first adding an explicit signature (which wins before jdk-nonportable) and suppress it:
In my opinion the whole code should a bit rewritten. The suppression/warning signatures should be parsed in the same way like any other signature and at runtime the logic should decide if to report it or not. This would also allow to for example "silence" all warning from a specific package using org.example.package.**.
At runtime the code should first execute the "failure" signatures, then the "warning" signatures and finally the "silence" signatures. If you have multiple matches on exactly the same method call / clas scheck it should "report" the last one found. In that case the "jdk-internal" problem would trigger a failure, but a later explicit "whitelist" would undo the report.
@kwin - any comments?