================
@@ -817,7 +817,7 @@ For later versions of Visual Studio, no setup is required-->
<DisplayString IncludeView="cached">
{IncludeMacroStack._Mypair._Myval2._Mylast - 1,na}</DisplayString>
<DisplayString Condition="CurLexer._Mypair._Myval2 !=
0">{CurLexer._Mypair._Myval2,na}</DisplayString>
<DisplayString Condition="CurTokenLexer._Mypair._Myval2 != 0">Expanding
Macro: {CurTokenLexer._Mypair._Myval2,na}</DisplayString>
- <!-- Can't use CurLexerKind because natvis sees the type rather than the
variable -->
----------------
AaronBallman wrote:
Yeah, this is going to break NATVIS pretty badly. This whole nonsense:
```
IncludeMacroStack._Mypair._Myval2._Mylast -
IncludeMacroStack._Mypair._Myval2._Myfirst
```
is a ridiculous^Wfancy way of saying:
```
IncludeMacroStack.back().CurLexerKind
```
which is used to figure out what kind of lexer we should be displaying a
visualizer for. I don't think there's a way we can repair that now that we're
using function pointers. I checked out the behavior locally to see if the
debugging experience is significantly worse and... it's not *that* bad (I think
the existing NATVIS already needed some repair). The most confusing thing is
that we no longer can quickly see which lexer is the one currently in use, but
we can still access the correct lexer from other contextual information.
So I think this change is "fine".
https://github.com/llvm/llvm-project/pull/70381
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
