cmtice wrote: > Haven't gone through this in detail yet (having an example of how these > structures will be used would be helpful), but something I was curious about > is whether this `DIL` is going to be used in the implementation of a new > command, or if we're going to extend the `frame var` language? I didn't see a > concrete conclusion on this in the RFC
The plan is for the DIL implementation to eventually replace the current 'frame variable' command (see Milestone 1 in the implementation plan). Once that is done, it will be expanded to also replace calls to GetValueForExpressionPath, for parsing & handling pieces of LLDB's data formatters. I couldn't put the whole implementation into a single PR, as it would have been much too big to review (even some of the pieces are going to be pretty big). So I broke it up into: the helper functions (which have already been committed now); the AST (this PR); and then three more PR's, each one coming after the preceding one is approved: the DIL Parser (a recursive-descent parser), which constructs (and returns) the appropriate DIL AST; the DIL Evaluator, which takes a DIL AST, evaluates it in the current context (frame), and returns an appropriate ValueObjectSP; and the code to actually hook this up to the 'frame variable' command. I have the whole thing implemented (complete with test cases). If you really want to dig through the complete code, you can see it at https://github.com/cmtice/llvm-project/tree/DIL-work-new/ (note that I will be cleaning up the Parser & Evaluator code before actually being put into a PR). The current implementation there still has both implementations for 'frame variable' (original and DIL), and with 'original' being the default and 'DIL' being turned on by an option. https://github.com/llvm/llvm-project/pull/95738 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
