This is failing on the lldb-aarch64-windows bots with (see error below).
XFAIL for now because it's unlikely that these expression evaluator
calls were supported before they were added.
```
======================================================================
FAIL: test_nested_no_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_nested_no_structor_linkage_names_dwarf)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method
return attrvalue(self)
^^^^^^^^^^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 108, in test_nested_no_structor_linkage_names
self.do_nested_structor_test()
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 102, in do_nested_structor_test
self.expect(
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2453, in expect
self.assertFalse(
AssertionError: True is not false : Command 'expression TaggedLocal()' is expected to fail!
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
======================================================================
FAIL: test_nested_with_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_nested_with_structor_linkage_names_dwarf)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method
return attrvalue(self)
^^^^^^^^^^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 112, in test_nested_with_structor_linkage_names
self.do_nested_structor_test()
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 102, in do_nested_structor_test
self.expect(
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2453, in expect
self.assertFalse(
AssertionError: True is not false : Command 'expression TaggedLocal()' is expected to fail!
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
======================================================================
FAIL: test_no_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_no_structor_linkage_names_dwarf)
Test that without linkage names on structor declarations we can't call
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method
return attrvalue(self)
^^^^^^^^^^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 81, in test_no_structor_linkage_names
self.expect("expr Tagged t3(t1)", error=True)
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2453, in expect
self.assertFalse(
AssertionError: True is not false : Command 'expr Tagged t3(t1)' is expected to fail!
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
======================================================================
FAIL: test_with_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_with_structor_linkage_names_dwarf)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method
return attrvalue(self)
^^^^^^^^^^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 20, in test_with_structor_linkage_names
self.expect_expr(
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2596, in expect_expr
value_check.check_value(self, eval_result, str(eval_result))
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 301, in check_value
test_base.assertSuccess(val.GetError())
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2631, in assertSuccess
self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
AssertionError: 'error: Internal error [IRForTarget]: Result variable (??__F$__lldb_expr_result@?1??$__lldb_expr@@YAXPEAX@Z@YAXXZ) is defined, but is not a global variable
```
Depends on * https://github.com/llvm/llvm-project/pull/148877 * https://github.com/llvm/llvm-project/pull/155483 * https://github.com/llvm/llvm-project/pull/155485 * https://github.com/llvm/llvm-project/pull/154137 * https://github.com/llvm/llvm-project/pull/154142 This patch is an implementation of [this discussion](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816/7) about handling ABI-tagged structors during expression evaluation. **Motivation** LLDB encodes the mangled name of a `DW_TAG_subprogram` into `AsmLabel`s on function and method Clang AST nodes. This means that when calls to these functions get lowered into IR (when running JITted expressions), the address resolver can locate the appropriate symbol by mangled name (and it is guaranteed to find the symbol because we got the mangled name from debug-info, instead of letting Clang mangle it based on AST structure). However, we don't do this for `CXXConstructorDecl`s/`CXXDestructorDecl`s because these structor declarations in DWARF don't have a linkage name. This is because there can be multiple variants of a structor, each with a distinct mangling in the Itanium ABI. Each structor variant has its own definition `DW_TAG_subprogram`. So LLDB doesn't know which mangled name to put into the `AsmLabel`. Currently this means using ABI-tagged structors in LLDB expressions won't work (see [this RFC](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816) for concrete examples). **Proposed Solution** The `FunctionCallLabel` encoding that we put into `AsmLabel`s already supports stuffing more info about a DIE into it. So this patch extends the `FunctionCallLabel` to contain an optional discriminator (a sequence of bytes) which the `SymbolFileDWARF` plugin interprets as the constructor/destructor variant of that DIE. So when searching for the definition DIE, LLDB will include the structor variant in its heuristic for determining a match. There's a few subtleties here: 1. At the point at which LLDB first constructs the label, it has no way of knowing (just by looking at the debug-info declaration), which structor variant the expression evaluator is supposed to call. That's something that gets decided when compiling the expression. So we let the Clang mangler inject the correct structor variant into the `AsmLabel` during JITing. I adjusted the `AsmLabelAttr` mangling for this in https://github.com/llvm/llvm-project/pull/155485. An option would've been to create a new Clang attribute which behaved like an `AsmLabel` but with these special semantics for LLDB. My main concern there is that we'd have to adjust all the `AsmLabelAttr` checks around Clang to also now account for this new attribute. 2. The compiler is free to omit the `C1` variant of a constructor if the `C2` variant is sufficient. In that case it may alias `C1` to `C2`, leaving us with only the `C2` `DW_TAG_subprogram` in the object file. Linux is one of the platforms where this occurs. For those cases I added a heuristic in `SymbolFileDWARF` where we pick `C2` if we asked for `C1` but it doesn't exist. This may not always be correct (e.g., if the compiler decided to drop `C1` for other reasons). 3. In https://github.com/llvm/llvm-project/pull/154142 Clang will emit `C4`/`D4` variants of ctors/dtors on declarations. When resolving the `FunctionCallLabel` we will now substitute the actual variant that Clang told us we need to call into the mangled name. We do this using LLDB's `ManglingSubstitutor`. That way we find the definition DIE exactly the same way we do for regular function calls. 4. In cases where declarations and definitions live in separate modules, the DIE ID encoded in the function call label may not be enough to find the definition DIE in the encoded module ID. For those cases we fall back to how LLDB used to work: look up in all images of the target. To make sure we don't use the unified mangled name for the fallback lookup, we change the lookup name to whatever mangled name the FunctionCallLabel resolved to. rdar://104968288
The original PR has been reverted because of an LLDB test failure. This patch now works around the test failure by simply allowing the new symbols to show up in a stack trace. This reverts commit 72c04bb882ad70230bce309c3013d9cc2c99e9a7. Original commit message: This patch replaces `__can_extract_key` with an overload set to try to extract the key. This simplifies the code, since we don't need to have separate overload sets for the unordered and associative containers. It also allows extending the set of extraction cases more easily, since we have a single place to define how the key is extracted.
This patch works around an assertion that we hit in the `LambdaExpr` constructor when we call it from `ASTNodeImporter::VisitLambdaExpr` (see https://github.com/llvm/llvm-project/issues/149477). The lambda that we imported doesn't have the `NumCaptures` field accurately set to the one on the source decl. This is because in `MinimalImport` mode, we skip importing of lambda definitions: https://github.com/llvm/llvm-project/blob/e21b0dd81928a3266df0e3ede008fb7a6676ff95/clang/lib/AST/ASTImporter.cpp#L2499 In practice we have seen this assertion occur in our `import-std-module` test-suite when libc++ headers decide to use lambdas inside inline function bodies (the latest failure being caused by https://github.com/llvm/llvm-project/pull/144602). To avoid running into this whenever libc++ decides to use lambdas in headers, this patch skips `ASTImport` of lambdas alltogether. Ideally this would bubble up to the user or log as an error, but we swallow the `ASTImportError`s currently. The only way this codepath is hit is when lambdas are used inside functions in defined in the expression evaluator, or when importing AST nodes from Clang modules. Both of these are very niche use-cases (for now), so a workaround seemed appropriate.
Fixes a bug that surfaces in frame recognizers. Details about the bug: A new frame recognizer is configured to match a specific symbol (`swift_willThrow`). This is an `extern "C"` symbol defined in a C++ source file. When Swift is built with debug info, the function `ParseFunctionFromDWARF` will use the debug info to construct a function name that looks like a C++ declaration (`::swift_willThrow(void *, SwiftError**)`). The `Mangled` instance will have this string as its `m_demangled` field, and have _no_ string for its `m_mangled` field. The result is the frame recognizer would not match the symbol to the name (`swift_willThrow` != `::swift_willThrow(void *, SwiftError**)`. By changing `ParseFunctionFromDWARF` to assign both a demangled name and a mangled, frame recognizers can successfully match symbols in this configuration.
Currently failing with the following when building the test file: ``` C:\buildbot\as-builder-10\lldb-x86-64\build\bin\clang.exe lib.o -gdwarf -O0 -m64 -IC:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\packages\Python\lldbsuite\test\make/../../../../..//include -IC:/buildbot/as-builder-10/lldb-x86-64/build/tools/lldb/include -IC:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\test\API\lang\cpp\expr-definition-in-dylib -IC:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\packages\Python\lldbsuite\test\make -include C:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\packages\Python\lldbsuite\test\make/test_common.h -fno-limit-debug-info -fuse-ld=lld --driver-mode=g++ -shared -o "lib.dll" lld-link: warning: section name .debug_abbrev is longer than 8 characters and will use a non-standard string table lld-link: warning: section name .debug_info is longer than 8 characters and will use a non-standard string table lld-link: warning: section name .debug_line is longer than 8 characters and will use a non-standard string table lld-link: warning: section name .debug_str is longer than 8 characters and will use a non-standard string table C:\buildbot\as-builder-10\lldb-x86-64\build\bin\clang.exe main.o -L. -llib -gdwarf -O0 -m64 -IC:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\packages\Python\lldbsuite\test\make/../../../../..//include -IC:/buildbot/as-builder-10/lldb-x86-64/build/tools/lldb/include -IC:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\test\API\lang\cpp\expr-definition-in-dylib -IC:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\packages\Python\lldbsuite\test\make -include C:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\packages\Python\lldbsuite\test\make/test_common.h -fno-limit-debug-info -fuse-ld=lld --driver-mode=g++ -o "a.out" lld-link: error: undefined symbol: public: int __cdecl Foo::method(void) >>> referenced by main.o:(main) clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Makefile.rules:531: a.out] Error 1 make: Leaving directory 'C:/buildbot/as-builder-10/lldb-x86-64/build/lldb-test-build.noindex/lang/cpp/expr-definition-in-dylib/TestExprDefinitionInDylib.test' ``` Skip for now
LLDB currently attaches `AsmLabel`s to `FunctionDecl`s such that that the `IRExecutionUnit` can determine which mangled name to call (we can't rely on Clang deriving the correct mangled name to call because the debug-info AST doesn't contain all the info that would be encoded in the DWARF linkage names). However, we don't attach `AsmLabel`s for structors because they have multiple variants and thus it's not clear which mangled name to use. In the [RFC on fixing expression evaluation of abi-tagged structors](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816) we discussed encoding the structor variant into the `AsmLabel`s. Specifically in [this thread](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816/7) we discussed that the contents of the `AsmLabel` are completely under LLDB's control and we could make use of it to uniquely identify a function by encoding the exact module and DIE that the function is associated with (mangled names need not be enough since two identical mangled symbols may live in different modules). So if we already have a custom `AsmLabel` format, we can encode the structor variant in a follow-up (the current idea is to append the structor variant as a suffix to our custom `AsmLabel` when Clang emits the mangled name into the JITted IR). Then we would just have to teach the `IRExecutionUnit` to pick the correct structor variant DIE during symbol resolution. The draft of this is available [here](https://github.com/llvm/llvm-project/pull/149827) This patch sets up the infrastructure for the custom `AsmLabel` format by encoding the module id, DIE id and mangled name in it. **Implementation** The flow is as follows: 1. Create the label in `DWARFASTParserClang`. The format is: `$__lldb_func:module_id:die_id:mangled_name` 2. When resolving external symbols in `IRExecutionUnit`, we parse this label and then do a lookup by DIE ID (or mangled name into the module if the encoded DIE is a declaration). Depends on https://github.com/llvm/llvm-project/pull/151355
In some places it was printing "= {...}" and some "={...}" with no
space. I think the space looks nicer so do that in both cases.