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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
