[Lldb-commits] [lldb] [LLDB] Add Lexer (with tests) for DIL (Data Inspection Language). (PR #123521)

[via lldb-commits]

jimingham 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]`.
> 

We would have to change how synthetic children are made currently for array like things for this to work.  If I have a std:vector called `foo` and I write:

(lldb) v foo[0]

and the DIL parses that it will either ask foo for a child named `0`, which doesn't exist, or ask it for the 0th child which currently is not required to be the one called `[0]`.  I think I mentioned this back when we were first discussing this, but if we want to make this part work, then we have to add some API on the synthetic child provider like `AddVectorChild(size_t idx, ValueObjectSP child_sp)` and require you use that to make vector like things.  Then we could require that the child named `[0]` HAS to be the 0th child, etc.

We still have the problem of all the synthetic child providers in the wild that might not do this. 

> 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.

That comes back to how soon we expect to know the language as we are parsing.  `unsigned` is a perfectly good variable name in swift, for instance...  I don't think we want to limit lldb to only C-family languages.

> 
> (*) 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...

Yes, collection classes that use arbitrary types for the keys are problematic.  How would we show the map if the keys are structures with some non-trivial compare function in a way that wouldn't be awful to use?  I don't think we can get around people having to know that `v` path expressions are NOT expressions in the underlying language.

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