labath wrote: > There's one small area that our desire to parse the widest range of > identifiers comes into conflict with, namely the "persistent variable" > namespace. For the C family of languages, we reserve the initial `$` for this > purpose, for swift (where `$1` etc. were already taken) we use `$R` as the > namespace identifier. This doesn't matter for the DIL at present, because > `frame var` and the like don't have access to the persistent variables, but I > don't think in the long run that's desirable. But it looks like to get that > right generally we would have to figure out the language of the identifier > which we don't want to do. I'm not sure how to finesse this (other than to > keep not allowing access to persistent variables in the DIL...)
Yeah, access to persistent variables is one of the first things that I'd add to the "frame var" language. It's true that this can create some conflicts and, but I think it we don't need to handle those at the lexer level. And variables with dollars in their names are currently accepted in frame var: ``` 2 int a$b = 47; -> 3 return a$b; 4 } (lldb) v a$b (int) a$b = 47 ``` One way to handle this ambiguity would be to use the (imaginary) identifier disambiguation/scoping mechanism I alluded to in one of my previous comments. We could e.g. say that identifiers that start with a dollar are reserved by lldb, and if you want to access a variable with that name, you do something like `$locals.$47`. The fact that swift uses identifiers like `$1` does complicate things, and I guess it means we may have to have some context-sensitive rules about when does that refer to a program variable and when an lldb internal concept. https://github.com/llvm/llvm-project/pull/123521 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
