[Lldb-commits] [lldb] [lldb] Note Command Used For DWIM Printing Of Persistent Variable (PR #215650)

[Will Hawkins via lldb-commits]

hawkinsw wrote:

> Unfortunately we've reused "Expression" in a way that is confusing. We have two unrelated entities: `VariableExpressionPaths` and `Expressions`.
> 
> VariableExpressionPaths are what the DIL evaluates. The DIL is a lldb based parser that is for instance what "frame var" uses. It naturally supports synthetic children, and since it evaluates each node as it finds it, it can do tricks like substituting the dynamic type during evaluation so you can do:
> 
> `frame var variable_of_type_base_class_but_actually_derived_class.ivar_of_derived_class `
> 
> which a language accurate parser can't do. But it is a separate entity from the actual "Expression" parser.
> 
> Expressions are what the Expression Parser evaluates. That is the full language accurate evaluator whose job it to evaluate the expression as if it had been compiled in your code at the point where you are currently stopped.
> 
> The code that you cited is using "VariableExpressionPaths".

Yes, I definitely understood that. I was simply commenting on the fact that the note implies that the evaluation of that expression path in DIL in the `dwim-print` is the same as

```
frame variable <expression>
```

but it actually is not (given that the DIL interpreter is configured to operate in "simple" mode for `dwim-print` and "regular" mode for `frame variable`). I suppose, however, that it might be a difference without a distinction because that note would only be printed when the DIL expression _can_ be evaluated in the simple mode and it succeeds. In that case, there may be no functional difference at all that the user could notice. I still found it odd and just wanted to check.

> 
> The goal of dwim-print is to get the same results as the expression parser but using the cheapest method possible. Since DIL evaluations end up resolving to memory reads and casting, it is generally faster and less complex than expressions, so dwim-print is going to do its best to use path expressions or other lookups if it can.
> 
> BTW, I also think DIL expressions should be able to access result variables. They all live in a global namespace and we choose their names such that they don't conflict with valid identifiers in the language. They can be looked up just like local or global variables. So really, the part of `dwim-print` that handles path expression should be able to handle result variables transparently as well.



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