[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)
Ilia Kuklin via lldb-commits
lldb-commits at lists.llvm.org
Thu May 8 09:46:36 PDT 2025
kuilpd wrote:
> Because I wanted to avoid this getting bogged down in the discussion about the types of numbers. I don't really mind the "extra capability" of indexing an array with a another variable. The part I have problem with is the precedent it sets about the representation of numbers.
>
> You're right that we can't do math operations without (implicitly or explicitly) assigning them some type, but that's exactly the part I think needs more discussion. Right now, you're assigning the type based on the first type system you find (which is likely going to be C), but I think that's not a good choice. If you're debugging some swift code, I think you'd be surprised if `47` resolves to a C type.
Okay, I see the problem, I didn't really think that retrieving the type system when debugging Swift code would return C type system. Why is it like this though? Is there a reliable way to get a type system of the main language?
I also found now that the function `TypeSystem::GetBasicTypeFromAST` that the code in Eval relies on is not even implemented in [`TypeSystemSwift`](https://github.com/swiftlang/llvm-project/blob/a5b0b3daf26fd41b2caf61551b72f74b0e2a4ab7/lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwift.h#L296).
I don't have any other suggestion how to implement this, so I guess I'll stick to having an integer within the subscript node until we have a better idea.
https://github.com/llvm/llvm-project/pull/138551
More information about the lldb-commits
mailing list