llvm-project.git/lldb/test/Shell/SymbolFile/DWARF/vla.cpp, branch main Unnamed repository; edit this file 'description' to name the repository. [lldb][test] Disable vla test on Windows 2024-08-01T12:59:49+00:00 David Spickett david.spickett@linaro.org 2024-08-01T12:49:26+00:00 229a16590a3cd65da77bb868498d3eed63bf6263 For the same reasons as 6cfac497e96978f2bfc50a00b51c198f2ed50f82. This test was added in https://github.com/llvm/llvm-project/pull/100710. It fails because when we're linking with link.exe, -gdwarf has no effect and we get a PDB file anyway. The Windows on Arm lldb bot uses link.exe. "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.34.31933\\bin\\Hostx86\\arm64\\link.exe" <...> 08/01/2024 01:47 PM 2,956,488 vla.cpp.ilk 08/01/2024 01:47 PM 6,582,272 vla.cpp.pdb 08/01/2024 01:47 PM 734,208 vla.cpp.tmp 
For the same reasons as 6cfac497e96978f2bfc50a00b51c198f2ed50f82.

This test was added in https://github.com/llvm/llvm-project/pull/100710.

It fails because when we're linking with link.exe, -gdwarf has no
effect and we get a PDB file anyway. The Windows on Arm lldb bot
uses link.exe.

 "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.34.31933\\bin\\Hostx86\\arm64\\link.exe" <...>

08/01/2024  01:47 PM         2,956,488 vla.cpp.ilk
08/01/2024  01:47 PM         6,582,272 vla.cpp.pdb
08/01/2024  01:47 PM           734,208 vla.cpp.tmp
[lldb][TypeSystemClang] Create VLAs of explicitly 0-size as ConstantArrayType (#100710) 2024-07-29T08:35:00+00:00 Michael Buch michaelbuch12@gmail.com 2024-07-29T08:35:00+00:00 d72c8b02802c87386f5db3c7de6c79e921618fa3 Depends on https://github.com/llvm/llvm-project/pull/100674 Currently, we treat VLAs declared as `int[]` and `int[0]` identically. I.e., we create them as `IncompleteArrayType`s. However, the `DW_AT_count` for `int[0]` *does* exist, and is retrievable without an execution context. This patch decouples the notion of "has 0 elements" from "has no known `DW_AT_count`". This aligns with how Clang represents `int[0]` in the AST (it treats it as a `ConstantArrayType` of 0 size). This issue was surfaced when adapting LLDB to https://github.com/llvm/llvm-project/issues/93069. There, the `__compressed_pair_padding` type has a `char[0]` member. If we previously got the `__compressed_pair_padding` out of a module (where clang represents `char[0]` as a `ConstantArrayType`), and try to merge the AST with one we got from DWARF (where LLDB used to represent `char[0]` as an `IncompleteArrayType`), the AST structural equivalence check fails, resulting in silent ASTImporter failures. This manifested in a failure in `TestNonModuleTypeSeparation.py`. **Implementation** 1. Adjust `ParseChildArrayInfo` to store the element counts of each VLA dimension as an `optional<uint64_t>`, instead of a regular `uint64_t`. So when we pass this down to `CreateArrayType`, we have a better heuristic for what is an `IncompleteArrayType`. 2. In `TypeSystemClang::GetBitSize`, if we encounter a `ConstantArrayType` simply return the size that it was created with. If we couldn't determine the authoritative bound from DWARF during parsing, we would've created an `IncompleteArrayType`. This ensures that `GetBitSize` on arrays with `DW_AT_count 0x0` returns `0` (whereas previously it would've returned a `std::nullopt`, causing that `FieldDecl` to just get dropped during printing) 
Depends on https://github.com/llvm/llvm-project/pull/100674

Currently, we treat VLAs declared as `int[]` and `int[0]` identically.
I.e., we create them as `IncompleteArrayType`s. However, the
`DW_AT_count` for `int[0]` *does* exist, and is retrievable without an
execution context. This patch decouples the notion of "has 0 elements"
from "has no known `DW_AT_count`".

This aligns with how Clang represents `int[0]` in the AST (it treats it
as a `ConstantArrayType` of 0 size).

This issue was surfaced when adapting LLDB to
https://github.com/llvm/llvm-project/issues/93069. There, the
`__compressed_pair_padding` type has a `char[0]` member. If we
previously got the `__compressed_pair_padding` out of a module (where
clang represents `char[0]` as a `ConstantArrayType`), and try to merge
the AST with one we got from DWARF (where LLDB used to represent
`char[0]` as an `IncompleteArrayType`), the AST structural equivalence
check fails, resulting in silent ASTImporter failures. This manifested
in a failure in `TestNonModuleTypeSeparation.py`.

**Implementation**
1. Adjust `ParseChildArrayInfo` to store the element counts of each VLA
dimension as an `optional<uint64_t>`, instead of a regular `uint64_t`.
So when we pass this down to `CreateArrayType`, we have a better
heuristic for what is an `IncompleteArrayType`.
2. In `TypeSystemClang::GetBitSize`, if we encounter a
`ConstantArrayType` simply return the size that it was created with. If
we couldn't determine the authoritative bound from DWARF during parsing,
we would've created an `IncompleteArrayType`. This ensures that
`GetBitSize` on arrays with `DW_AT_count 0x0` returns `0` (whereas
previously it would've returned a `std::nullopt`, causing that
`FieldDecl` to just get dropped during printing)