labath 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? > > 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.
I agree with that. > 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. .. but I'm not sure what you meant by "its own plugin". Can you elaborate on that? If DIL is going to be language agnostic, then I don't think it needs to be a plugin. What I can imagine is having some sort of a `DILTypeSystem` plugin(*), which would be "The type system used in DIL expressions". Something like that might be necessary if we want to create ValueObjects representing DIL values (since ValueObjects require types, and types require type systems). 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. (*) Technically, that also shouldn't be, as it's depended on by core functionality (the DIL), which would break if its plugged "out". However, it would be an implementation of the TypeSystem interface. https://github.com/llvm/llvm-project/pull/155617 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
