[clang] [clang] Bounds checking on unclosed parentheses, brackets or braces in Expanded Tokens (PR #69849)

[Nathan Ridge via cfe-commits]

HighCommander4 wrote:

> I am slightly suspicious of source locations pointing at `eof` in the AST in the first place, even in invalid code. I wonder if we would be better off just having an invalid source location there instead of pointing at `eof`.

I think in this case it's deliberate. If you look at the compiler error for the missing brace:

```c++
test.cpp:1:13: error: expected '}'
    1 | int main() {
      |             ^
test.cpp:1:12: note: to match this '{'
    1 | int main() {
      |            ^
```

you can see that the diagnostic location points to one character past the opening brace, which is the `eof` token. I'm not sure how else the diagnostic location could end up there.

> Asserting that `tok::eof` should not be passed to `spelledForExpandedToken` and returning `nullopt` in `spelledForExpanded` looks like a reasonable workaround until we fix this. (The semantics looks reasonable as we don't really have a spelled token we can map `eof` back to).

What do you think about this as an alternative: if `spelledForExpanded` receives as input an expanded token range `[firstExpanded, lastExpanded]` where `lastExpanded` is the `eof` token, return the spelled tokens corresponding to `[firstExpanded, lastExpanded - 1]` instead? (In the case where the `eof` token is the only one in the range, we could return nullopt.)

This would have the advantage of gracefully handling AST nodes like this one whose end location is the `eof`, and return all the spelled tokens actually making up the node.

https://github.com/llvm/llvm-project/pull/69849