Add "grouped diagnostics" that allows rendering across source files

[DougGregor]

Extend the diagnostics renderer to handle a set of "grouped"
diagnostics, where the diagnostics occur across different source files
that are related through source code generation, for example because
one is a macro expansion buffer that was triggered within the other.
These inner source files are shown as nested source files in the
output, underneath the location of where the outer source file where
they logically occur.

Introduce a few other small improvements to the colorization in the
diagnostics formatter that became more apparent when we do this:

• Underline highlighted ranges in the source text
• Make the boxes and line numbers cyan so they feel separate from the code

Here's an example from the tests:

=== main.swift ===
1 │ let pi = 3.14159
2 │ #myAssert(pi == 3)
  │ ╰─ in expansion of macro 'myAssert' here
  ╭-── #myAssert ──────────────────────────────────────────────────────
  │1 │ let __a = pi
  │2 │ let __b = 3
  │3 │ if #invertedEqualityCheck(__a, __b) {
  │  │    ╰─ in expansion of macro 'invertedEqualityCheck' here
  │  ╭-── #invertedEqualityCheck ─────────────────────────────────────
  │  │1 │ !(__a == __b)
  │  │  │       ╰─ no matching operator '==' for types 'Double' and 'Int'
  │  ╰-───────────────────────────────────────────────────────────────
  │4 │   fatalError("assertion failed: pi != 3")
  │5 │ }
  ╰-───────────────────────────────────────────────────────────────────
3 │ print("hello"
  │              ╰─ expected ')' to end function call

[DougGregor]

@swift-ci please test

[DougGregor]

@swift-ci please test

[DougGregor]

@swift-ci please test

[ahoppen]

This looks nice! I’ve got a few minor comments inline.

[ahoppen]

Just a thought: Could we use the root SourceFileSynax as the SourceFileID?

[DougGregor]

Maybe? It felt more fragile than if we made this explicit.

[ahoppen]

Since we are maintaining a map from SourceFileSyntax to SourceFileID, don’t we already have any fragility from SourceFileSyntax now?

Also, note that equality that the identity of Syntax is defined by its SyntaxIdentifier, so we don’t do any tree comparisons or anything of the sort when comparing two syntax nodes.

[DougGregor]

The mapping is only used in cases where the client isn't supplying a buffer ID, so you never need to depend on it. We could either drop the mapping internally (and have clients always supply the buffer ID when adding a diagnostic) or drop the buffer ID (and rely on the mapping everywhere), but this does feel like a weird middle ground.

[DougGregor]

@swift-ci please test

[ahoppen]

Wouldn’t it be conceptually simpler if this was [AbsolutePosition: String] or [AbsolutePosition: [String]] (I’d prefer the former if it’s possible). That would suggest better to me there’s a key value relationship between AbsolutePosition and String here.

That being said, I understand that we’re never accessing suffixTexts by its AbsolutePosition.

[DougGregor]

This is a little nicer, so I went ahead and did it in #1365

[ahoppen]

Since we are maintaining a map from SourceFileSyntax to SourceFileID, don’t we already have any fragility from SourceFileSyntax now?

Also, note that equality that the identity of Syntax is defined by its SyntaxIdentifier, so we don’t do any tree comparisons or anything of the sort when comparing two syntax nodes.