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 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
