[Lldb-commits] [lldb] [LLDB] Add unary plus and minus to DIL (PR #155617)

[Ilia Kuklin via lldb-commits]

kuilpd wrote:

> Do we ever want to support - in the DIL - something like:
> 
> swift_integer = c_integer + rust_integer
> 
> We do know how to do that (variations on the details of integer promotion and the like aside) and given these are data objects we can query for their integer values it seems somewhat artificial to disallow it. But in that case, whose promotion rules should we use?

We can do this, because the arithmetic itself is not typed. Math is implemented through `Scalar` class, which only operates on numbers itself (integer, IEEE float, IEEE double, etc). So we can retrieve the scalars from `c_integer` and `rust_integer` and add them together as scalars, then pick whatever compiler type we want the result to be. In this case, `Int` from Swift. I will show more of this logic once we get to binary operands.

> That's why I've been arguing that we should have a DIL set of promotion rules where integers are not sized. That way all these sort of computations can be done naturally. So I would argue that the DIL code should be its own plugin, not trying to either be C++ or something in the background, nor trying to figure out based on the expression what "Real" Typesystem we should dispatch to.

Basically, the promotion rules of DIL math are from `Scalar` class. The language specific promotion rules I'm implementing now are for picking the resulting type, and it doesn't really influence the math itself. It's so that the result can be a value `ValueObject` with a compiler type, which can be used wherever DIL was called from. By implementing the promotion rules in the respective type system we get the result closer to an actual language. It's just right now the type system for the result is taken from the current execution context, but that can be changed once we start implementing assignment operators.

> When people want to answer the question "what would this expression do at this point in my code" they should be using the expression evaluator for that language. The DIL is there to support the widest range of data introspection tasks we can offer on generic structured data objects.

For the reason above, I don't think we have to sacrifice the correctness of result types to achieve the main goal of DIL. Every language will have to implement something in their type system anyway for DIL to work with it. If it doesn't matter to the language, it can just return a default type, like `Int` for Swift.


> OTOH, type systems deal with a lot more than integral types, so I can also imagine not doing that, and either having the DIL return something other than a ValueObject (for the cases where the result of evaluation is not a program value) or by teaching value objects to not require a type system.

I would really like DIL to be just compatible with the rest of LLDB as is. I don't see much of a problem with picking a type for the result. Other than primitive types, we have to have a type anyway for the result to be usable.


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