| Issue |
184969
|
| Summary |
Make Sema keep track of mangling numbers for anonymous structures (and lambdas)
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
Michael137
|
I wanted to get people's opinion on some mangle numbering changes I'd like to make. I'm preparing some changes to how we emit names for lambdas in debug-info ([draft here](https://github.com/llvm/llvm-project/pull/168533)). Previously when lambdas were passed as template arguments, we'd print the names as follows:
```
foo<(lambda at anon.cpp:10:8)>
```
which is nice because it's unambiguous, but also breaks various tooling in the presence of source code drift, etc.. So instead we want to emit names such as:
```
foo<(main()::'lambda'(int))>
```
which is what GCC does. But we'd like it to be as unique as we can make it. Mangling numbers seemed like a good fit for this. My naive implementation was to just ask `ASTContext::getManglingNumber()` for this. The issue is that for anonymous structures, Sema doesn't assign mangling numbers [in all cases](https://github.com/llvm/llvm-project/blob/8c206a26e408bcbf98b1cc6b0770b17c1e8d0320/clang/lib/Sema/SemaLambda.cpp#L359-L362) (just the ones deemed necessary by the itanium ABI). But the Itanium mangler does assign mangling numbers to them eventually anyway (using its [own naming scheme](https://github.com/llvm/llvm-project/blob/8c206a26e408bcbf98b1cc6b0770b17c1e8d0320/clang/include/clang/AST/Mangle.h#L96))
Could we let Sema assign mangling numbers for structures/lambdas regardless of linkage/ABI requirements? If we loosen that restriction, that would also address https://github.com/llvm/llvm-project/issues/73521#issuecomment-1828673100 (where we'd like to use the <lambda-sig> mangling for internal linkage lambdas, for consistency and works better with the LLVM demangler). Perhaps we could even remove the naming that the mangler assigns to local anonymous structures (and instead use the ones assigned by Sema, they should more or less be the same i think).
Something similar was attempted for CUDA/HIP a while back https://reviews.llvm.org/D63164 but they adopted a different strategy for their use-case (https://reviews.llvm.org/D68818)
CC @zygoloid @rjmccall @efriedma-quic
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
