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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
