[Lldb-commits] [lldb] Draft: [LLDB] Add scalar literal node (PR #147064)

[Ilia Kuklin via lldb-commits]

kuilpd wrote:

> > single interface to traverse the AST tree:
> 
> That's the part that would change in this setup. Instead of one API, we'd have two: `EvaluateValueNode()` and `EvaluateScalarNode()`, and we'd have two node hierarchies: ValueNode and ScalarNode. MemberOfNode would be a ValueNode because it produces a value object. AddNode would be a ScalarNode because it produces a number. ArraySubscriptNode would be a ValueNode (the result is a value), but its `index` member would be a ScalarNode, because we need to use it for indexing.
> 
> The correct types would be ensured when parsing, possibly with the addition of the "rvalue" nodes. `a[1]` would be parsed as `Subscript(Identifier(a), Scalar(1))`, while `a[b]` would turn into `Subscript(Identifier(a), RValue(Identifier(b)))`. `a[b+1]` would be something like `Subscript(Identifier(a), Add(RValue(Identifier(b)), Scalar(1)))`. The evaluator would have access to the right types, so it could invoke the right function. This has nothing to do with the types of the variables, its about the types (kinds) of AST nodes.
> 
> I'm not saying you have to do this, but I find the idea of not constantly wrapping and unwrapping scalars appealing.

I don't know about this... wouldn't this `RValue(ValueNode)` function be pretty much the same process of unwrapping Scalar from ValueObject? We will still need to wrap/unwrap Scalar from ValueObject whenever they interact, so this will only cut down the wraps when Scalar/Scalar interact, which is pretty much just arithmetics with constant literals and subscript with a constant index. 

I think for now it's better to implement a clean interface in ValueObject to create it from a Scalar, and we can optimize the arithmetics the way you suggested later, if this ends up being a performance bottleneck.

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