hawkinsw 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.
I think that I grok the distinction that you are making and appreciate the subtlety. As I work on getting this PR ready, I just want to confirm that the distinction is important to understand if/when we added support for storing the result of DIL expression evaluation as persistent/result variables. In other words, simply allowing the use of a persistent/result variable in a DIL expression is ok. https://github.com/llvm/llvm-project/pull/215706 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
