kuilpd wrote: @labath @cmtice @jimingham @asl This is a draft with some potential changes I'd like to discuss regarding how to handle the type system of constant literals. I'm also trying to demonstrate how they interact further with other values in a binary addition node. A lot of the code is cut out for better visibility of the important parts, but it's still quite a lot, I will later split this into separate PRs if anything comes out of this.
Things I've tried to address: 1. `DILEval.cpp:406-439`: Upon creation of `ScalarLiteralNode` it will default to the current compile unit's type system, instead of iterating through `target_sp->GetScratchTypeSystems()` [(old code)](https://github.com/kuilpd/llvm-project/blob/ad204cdfd226ca2a886c5475775fe67b29a70926/lldb/source/ValueObject/DILEval.cpp#L244). I think it's a good bet to assume that we want the type system of where we're currently stopped at. The node has to have some type in case it needs to be output as is. 2. `DILEval.cpp:775-791`: However, when it is used in another node, like a + b, we check if operands' type systems match and if not, we check if one of them is a scalar literal, in which case they can be converted to the type system of another operand. The rest of the code in `DILEval.cpp:441-740` is mostly the type promotion and conversion implementation from our downstream, except I changed the compiler type to be retrieved from operands' type system, instead of the same scratch type system iteration. There's no need to review the entire logic here yet, just the part how it handles the types. Here is the problem with types: initial scalar literal type, all the type promotions and conversions are done using `lldb::BasicType` enumeration types, and later converted to `CompilerType` using the `TypeSystem`. In C++, this works perfectly well, because in [`TypeSystemClang.cpp:5468`](https://github.com/llvm/llvm-project/blob/740da004af5ed402b6ddb0d71759f978bc814f7f/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp#L5468C1-L5468C41) it is implemented, but in [`TypeSystemSwift:304`](https://github.com/swiftlang/llvm-project/blob/4cbdeee819f3f2ce36d67af493fdd91c708612f4/lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwift.h#L304) it is not. Do we assume that this was just never needed before, so it can now be implemented and used? Or is there some sort of inherent incompatibility between LLDB's basic type system and Swift type system (talking about primitive types) that this cannot be implemented correctly? If so, what would be an alternative way to abstract the type promotion/conversion from the specific compiler type and type system? https://github.com/llvm/llvm-project/pull/147064 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
