Michael137 wrote: > @Michael137 Still not sure about the ways things can be printed part, but > here are the motivational examples:
Sorry for the delay. I've been side-tracked with other things. I'll look at the patch separately > * `DWIMPrint` calls `frame var` only for expressions that have variables and > member retrievals with the `.` operator, so it will be using the `simple` > mode to call DIL. Might be late to the party but should DWIMPrint be doing that? I'm guessing the reason you don't want the full DIL capability for DWIM is that it might run an expression differently than the real expression evaluator? E.g., this is one of the things I'd like to see in the PR description. Some examples of where the result is different would be good. > * `lldb-dap` and its tests expect only the capabilities of old `frame var` > and attempt to evaluate expressions using `frame var` without any checks, > with a fallback to full expression evaluation. To maintain the tests and to > limit the subset of expressions evaluated by DIL, `lldb-dap` will be calling > it using the `legacy` mode (which replicates what old `frame var` could do). Hmmm why is DAP not using DWIMPrint. It sounds like this replicating DWIM behaviour. Am I missing something? > * The actual `frame var` console command should always use the full DIL > capabilities, so it will be calling DIL in `full` mode. I agree with this point https://github.com/llvm/llvm-project/pull/178747 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
