RFR: Fix RichDiagnosticFormatter not to strip metadata when computing where clauses

[Maurizio Cimadamore]

On Fri, 16 Jan 2026 11:05:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The rich diagnostic formatter computes a list of "where clauses" -- that is, extra diagnostics that are meant to explain what the types in the main diagnostic are.
> 
> At some [point](https://bugs.openjdk.org/browse/JDK-8291643) it was decided to strip type annotations from the types in the diagnostics, to eliminate some noise. This created some issues:
> 
> * the logic to (pre)compute where clauses had to be adjusted to also strip metadata, otherwise discrepancies could lead to types not being found in the where clause table at the time of emitting references to them
> * the preprocessing logic uses Type::toString to compare whether two where clauses types are the same -- this check is too fragile and sometimes leads to duplicated where clauses (esp. for intersection types)
> 
> In addition to these general issues, calling `stripMetadata` unconditionally in `AbstractDiagnosticFormatter`, also means that we cannot correctly render null-restricted types. While we could do something to re-add the null-restriction after stripping, this silent coupling between `AbstractDiagnosticFormatter` and pre-processing of where clauses in `RichDiagnosticFormatter` is problematic, and an obstable to improve the treatment of null-restricted types.
> 
> The solution is to avoid string-y comparison when populating where clauses. All comparison should occur either by symbol (e.g. type variables, captured types), or by `Types::isSameType` (for intersection type). Note that, since symbols are more stable, and since `isSameType` ignores metadata, we no longer need metadata stripping when computing and/or searching for where clauses.
> 
> To make the code more robust I've centralized all the logic corresponding to populating and searching where clauses inside the already-existing `WhereClauses` class. This allows the code to control how de-duplication of similarly named (but different) type-variables should occur, etc. It also leads to slightly improved client code.
> 
> This means we can now tweak `AbstractDiagnosticFormatter` to restore null-restriction after stripping. And this will now have no effect on the correctness of the rich formatter.
> 
> I've also added a separate regression test to make sure that there's only one intersection where clause generated in cases where we have two intersection types with the same component types, but different annotations. Since the annotations are stripped, this leads (before this PR) to redundant where clauses with same content.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 4390:

> 4388: compiler.warn.suspicious.nullness.conversion=\
> 4389:     Suspicious nullness conversion\n\
> 4390:     required: {0}\n\

Removing this hack is really the goal of this PR -- now all null-restricted types are rendered correctly in the formatter machinery. In fact -- see some changes in the raw diagnostics in some negative tests, where null-restriction now (correctly) appear.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1921#discussion_r2698079635