Fix RichDiagnosticFormatter not to strip metadata when computing where clauses

[mcimadamore]

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 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.

---

Progress

• Change must not contain extraneous whitespace

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/valhalla.git pull/1921/head:pull/1921
$ git checkout pull/1921

Update a local copy of the PR:
$ git checkout pull/1921
$ git pull https://git.openjdk.org/valhalla.git pull/1921/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1921

View PR using the GUI difftool:
$ git pr show -t 1921

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/valhalla/pull/1921.diff

Using Webrev

Link to Webrev Comment

[mcimadamore]

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.

[bridgekeeper]

👋 Welcome back mcimadamore! A progress list of the required criteria for merging this PR into bworld will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@mcimadamore This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

Fix RichDiagnosticFormatter not to strip metadata when computing where clauses

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 1 new commit pushed to the bworld branch:

• 7dff1a6: Disable null-restricted varargs

Please see this link for an up-to-date comparison between the source branch of this pull request and the bworld branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the bworld branch, type /integrate in a new comment.

[mlbridge]

Webrevs

• 00: Full (c099910a)