jimingham wrote: > > So the only advantage to making these persistent definitions (or result > > variables if you want them to be const) is if you wanted to have DIL > > results available to the expression evaluator. > > Or to use these results for subsequent DIL calls (as per this patch), same > usage as in the expression evaluator. >
I want to make a distinction here first. Persistent definitions require that the evaluator be able to create new entities in the target. DIL can probably do that for scalar values and simple POD data types, but it certainly can't produce new objects in pretty much any object system, since that almost always requires running code. So the DIL really can't reliably produce "persistent definitions". I think it would be confusing to have a "yes I can do that for an int or a simple structure but not ..." It could, however, produce result variables, which just report on the result of some computation. In fact, we already do that to some extent in the `dwim-print` command. After all, dwim-print is attempting to emulate the expression parser, so when it finds that it can resolve the expression as a variable path expression, it still needs to produce a result variable for the computation. The expression parser's results are "const results", so they are intended to capture the result of the expression and not to track the future changes in the underlying constituents changes. I think that models what DIL expressions should return whenever they are returning a computation. After all, if I did: (lldb) v foo + 5 $some_result = 10 if I stepped and foo was incremented, I would NOT expect $some_result to become 11... We already have an option to produce or not produce result variables for path expressions. Maybe it would be useful to have the DIL trigger off that? After all, for DIL expressions that were just path expressions there really are two kinds of return values. The one which is "resolve this to the entity in the program, so that it tracks its value" and "report the current state of this value so I can check it against later values". So it seems sensible that we would offer this as an option for people who are using the DIL expressions. https://github.com/llvm/llvm-project/pull/215706 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
