Similar motivation to https://github.com/llvm/llvm-project/pull/165702. It was unused in all callsites and inconsistent with other APIs like `IsIntegerType` (which doesn't take a `count` parameter). If we ever need a "how many elements does this type represent", we can implement one with a new TypeSystem API that does exactly that. Some callsites checked for `count == 1` previously, but I suspect what they intended to do is check for whether it's a vector type or complex type, before reading the FP register. I'm somewhat confident that's the case because the `TypeSystemClang::GetTypeInfo` currently incorrectly sets the integer and floating point bits for complex and vector types (will fix separately). But some architectures might choose to pass single-element vectors in scalar registers. I should probably changes these to check the vector element size. All the `count == 2 && is_complex` were redundant because `count == 2` iff `is_complex == true`. So I just removed the count check there.
There were a couple of quirks with this parameter: 1. It wasn't being set consistently. E.g., vector types would be of count `1` but complex types would be `2`. Hence, it wasn't clear what count was referring to. 2. `count` was not being set if the input type was invalid, possibly leaving the input reference uninitialized. 3. Only one callsite actually made use of `count`, and that in itself seems like it could be improved (added a FIXME). If we ever need a "how many elements does this type represent", we can implement one with a new `TypeSystem` API that does exactly that.
`SBType::GetBasicType` fails on typedefs to primitive types. The docs for `GetBasicType` state: ``` Returns the BasicType value that is most appropriate to this type ``` But, e.g., for `uint64_t` this would currently return `eBasicTypeInvalid`. `TypeSystemClang::GetBasicTypeEnumeration` (which is what `SBType::GetBasicType` uses) doesn't see through typedefs. Inside LLDB we almost always call `GetBasicTypeEnumeration` on the canonical type. In the cases we don't I suspect those were just subtle bugs. This patch gets the canonical type inside of `GetBasicTypeEnumeration` instead. rdar://155829208
Add a function `GetDereferencedType` to `CompilerType` and allow `TypeSystemClang` to dereference arrays.
This patch replaces the use of `UINT32_MAX` as the error return value of `GetIndexOfChildWithName` with `llvm::Expected`. # Tasks to do in another PR 1. Replace `CalculateNumChildrenIgnoringErrors` with `CalculateNumChildren`. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056319358). 2. Update `lldb_private::formatters::ExtractIndexFromString` to use `llvm::Expected`. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2054217536). 3. Create a new class which carries both user and internal errors. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056439608).
This patch removes the unused `CompilerType::GetIndexOfFieldWithName` API (it wasn't used apart from in a single testcase). Given we have so many similarly named APIs already, it's best not to maintain this API that's not really used (and isnt tested).
This patch pushes the error handling boundary for the GetBitSize() methods from Runtime into the Type and CompilerType APIs. This makes it easier to diagnose problems thanks to more meaningful error messages being available. GetBitSize() is often the first thing LLDB asks about a type, so this method is particularly important for a better user experience. rdar://145667239
A bit or byte size of 0 is not a bug. It can legitimately (and frequently) happen in Swift and C, just not in C++. However, it doesn't make sense to read a scalar of zero bytes. Currently, when this happens, we trigger an `lldb_assert` in the data extractor and return 0, which isn't accurate. I have a bunch of reports of the assert triggering, but nobody has been able to provide me with a reproducer that I can turn into a test and I wasn't able to concoct a test case by reverse-engineering the code. rdar://141630334
Swift types have mangled names, so there should be a way to read those from the compiler type. This patch upstreams these two changes from swiftlang/llvm-project (which were added there since at least 2016).
For the significant amount of call sites that want to create an incontrovertible error, such a wrapper function creates a significant readability improvement and lowers the cost of entry to add error handling in more places.