On Fri, 16 Jan 2026 11:05:37 GMT, Maurizio Cimadamore <[email protected]> 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
