[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Andy Hippo via lldb-commits]

werat wrote:

Providing more context for answers to Michael's questions.

The original motivation for `lldb-eval` (https://github.com/google/lldb-eval, which is a predecessor for DIL) was to support the evaluation of expressions used in NatVis rules. [NatVis](https://learn.microsoft.com/en-us/visualstudio/debugger/create-custom-views-of-native-objects?view=vs-2022) visualizers support complex logic, including C++-like casts, restricted function calls and state-changing operations like increment/decrement.

To be able to evaluate those expressions as is, lldb-eval had to support all of the commonly used features, hence the extensive and somewhat selective list of supported features :)

For example, `reinterpret_cast<>` is commonly used to cast pointers to structs/classes in order to access their fields (example -- https://github.com/godotengine/godot/blob/cae2f853dcd1ecc26ca68de08cec62089dee1f26/platform/windows/godot.natvis#L146). Visual Studio NatVis evaluator doesn't support dynamic typing (e.g. resolving `foo->bar`, if `bar` is defined in a subclass), therefore the casts are necessary. In the world of dynamic typing this may be not necessary.

State altering operations like increment/decrement are used in advanced visualizers like `<CustomListItems>` for control flow -- e.g. you can define a loop variable, then increment it and break out of the loop under some condition. A real life example -- https://github.com/GaijinEntertainment/DagorEngine/blob/8b340d10814f06aa364e75769d406ec7373c5574/prog/_jBuild/_natvis/dagor_types.natvis#L746. It's not visible in the grammar, but `lldb-eval` has additional knobs for controlling when state changing is allowed. If I recall correctly, this can be done in two cases:
1) the variable being incremented is a "context variable", e.g. an artificial SBValue passed to the expression as context, which doesn't exist in the program. See some explanation and example here -- https://werat.dev/blog/blazing-fast-expression-evaluation-for-c-in-lldb/#maintaning-state
2) when side effects are explecitely allowed via options -- https://github.com/google/lldb-eval/blob/323d48f0b06d7dcf6ed70cdde17b42285450a32a/lldb-eval/api.h#L77. In our debugger this was disabled for all visualizer-related evaluations and enabled for one-off interactive evaluations, basically mimicking the behaviour of Visual Studio debugger.



https://github.com/llvm/llvm-project/pull/95738