labath wrote:
I agree with everything except for the last part. The current parser already
threats `[]` [very
specially](https://github.com/llvm/llvm-project/blob/89ca3e72ca03efbbfb5ae9b1c71d81f2d1753521/lldb/source/Target/StackFrame.cpp#L781).
I think it has to do that so it can treat pointers as C arrays (and then it
just special cases synthetic objects). I think that's a (mostly *) reasonable
setup that we could replicate in the new DIL implementation, particularly as we
would need special handling of `[]` to implement things like `[i+1]`.
FWIW, I believe that the main source of keywords in Caroline's implementation
is types (for casts). I think they could be handled generically (just ask the
target whether the identifier names a type), were it not for the nasty C(++)
habit of creating multiword types (`unsigned long long long long int`). Still,
it feels there ought to be recognise these without making `unsigned` a
full-fledged keyword.
(*) I was recently made aware of an unfortunate difference in behavior of
`frame var` and `expr` for map types:
```
(lldb) v m
(std::map<int, int>) m = size=3 {
[0] = (first = -42, second = -47)
[1] = (first = 0, second = 42)
[2] = (first = 42, second = 47)
}
(lldb) v m[0]
(std::__1::__value_type<int, int>::value_type) m[0] = (first = -42, second =
-47)
(lldb) expr m[0]
(std::map<int, int>::mapped_type) $0 = 42
```
I know that these are different languages, but this still seems like it could
confuse some people. I don't have any specific ideas on how to fix/improve this
though...
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
