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

[Pavel Labath via lldb-commits]

labath wrote:

> >   * The expression `foo["bar"]` tries:
> >     
> >     * `foo.GetChildWithName("bar")`
> >     * `foo.GetChildWithName("[bar]")`
> >   * The expression `foo[<expr>]` -- `expr` is evaluated and treated as cases above. If the result of `expr` is not a number or a string -- produce an error
> 
> 
> I think this is an interesting idea whose usefulness mainly depends on what kind of string operations we have in the language. If there's no way to construct strings, then I don't think it's very useful. You could write things like `some_variable[another_variable]`, but I don't think that's going to be useful because for static types (e.g. C structs) you're unlikely to have a variable with a value that contains the name of a field, and for types with synthetic children the names of the children are not going to have any relation to the way it's seen by the code (map<string, string> is still going to have a child called `[0]`).
> 
> Overall I'd leave this out for the time being because it doesn't impact parsing or lexing, just how some (currently invalid) syntax trees can be interpreted.

Thinking about this further, I can think of one reason to allow this even without sophisticated string operations -- because this allows you to access identifiers with weird child names. This way we could have users write `obj["a+b"]` for accessing the child `a+b` of object `obj` -- and we wouldn't "use up" a quote character in the process. This is sort of like how you can access global variables (even those with weird names) with `globals()["my_var"]` in python.

I'd still try to avoid things like guessing whether the user forgot to add `[]` to the name or not..

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