PR58819: Correct linkage and mangling of lambdas in inline static member initializers
authorDavid Blaikie <dblaikie@gmail.com>
Fri, 18 Nov 2022 00:26:40 +0000 (00:26 +0000)
committerDavid Blaikie <dblaikie@gmail.com>
Tue, 4 Apr 2023 04:45:32 +0000 (04:45 +0000)
commite9c9db34a9b04706937e9dd764d1d97ca84337b6
treedb771da8f0eaf574e9e9232eb156c9fb0c1349ec
parent1e2f87868f6fb64179b02c1076c6b3cd26576907
PR58819: Correct linkage and mangling of lambdas in inline static member initializers

https://llvm.org/pr58819 - clang is giving an externally visible lambda in a static data member internal linkage and the wrong linkage name.

Looks like we should be classifying this case the same as a non-static data member, so far as I can tell from the ABI docs and template examples (seems like the non-template inline-defined case should be the same).

This is a change in ABI, but not sure it qualifies as an ABI break as far as Apple and Sony are concerned - do you folks want this change? (it should fix the example in the bug where a static member in such a lambda ends up bifurcated, and I don't /think/ it'll break existing code since the symbol was previously internal anyway)

Looks like GCC has got this mangling slightly wrong (so we'd still end up with GCC+Clang bifurcation of the local static in the lambda, function address inequality, etc) in that they miss the variable name in the mangling in the non-template case. GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107741

Differential Revision: https://reviews.llvm.org/D138247
clang/lib/Sema/SemaLambda.cpp
clang/test/CodeGenCXX/mangle-lambdas.cpp