[libcxx-commits] [libcxx] [libc++] Introduce a new attribute keyword for Clang improves compatibility with Mingw-GCC (PR #141040)

[Tomohiro Kashiwada via libcxx-commits]

kikairoya wrote:

> > I agree that exporting additional symbols wouldn't break existing binaries at the symbol usage level. However, I guess, from user's perspective, needing to upgrade the DLL might be treated as ABI change. Saying it "breaks ABI" may have been too strong but not completely wrong, as seeing manner of ELF world, exporting new symbols will cause change SOVERSION.
> 
> I don't see this (in itself at least) as a reason to rule out this approach.

Yes, I agree. I didn't examine to achieve this by more modifying Clang itself but by modifying libc++ as described in 4., to instantiate and export explicitly.


> So if we, hypothetically, would have the resources/energy to do so, would we fix it in GCC by making the dllexport apply to the nested class too?

It's possible to both approach - to export or not to import. I consider it's appropriate to export inner classes as align to their outer template instantiation, but opposite is also an option like MSVC does. If GCC may do latter is considered, better not to export currently them as once they're exported, can't be removed (though, will not issue to leave them exported).

> In practice, I think it's not all that common to use this construct (explicit template instantiations with nested classes), outside of the standard library. 

LLVM itself has such instantiations but won't matter as `__declspec(dllexport)` isn't used for MinGW.

`Registry<T>` has `class iterator` https://github.com/llvm/llvm-project/blob/989aadf4b112ef55648d801c4003b63f8aad930e/llvm/include/llvm/Support/Registry.h#L150
`GenericDomTreeUpdater<...>` has `struct DomTreeUpdate`
https://github.com/llvm/llvm-project/blob/989aadf4b112ef55648d801c4003b63f8aad930e/llvm/include/llvm/Analysis/DomTreeUpdater.h#L120-L122 https://github.com/llvm/llvm-project/blob/989aadf4b112ef55648d801c4003b63f8aad930e/llvm/include/llvm/Analysis/GenericDomTreeUpdater.h#L23-L24

The cases of satisfy all of conditions (MinGW, built to DLL, use of `__declspec(dllexport)`, instantiate explicitly a class template contains a class that has a member function or a static data member and export it) is rare but could be seen.

> > Have you been able to test using libc++ with GCC in mingw environments so far, so you can reproduce that you run into this issue with the `sentry` nested classes, and so you can verify that this patch indeed would fix that issue, or is it hypothetical?
> 
> I saw [#135910 (comment)](https://github.com/llvm/llvm-project/issues/135910#issuecomment-2859147085), I don't know if the more recent patch has been tried this way though.

I have tested by my hand to this newest patch makes linking with g++ (and BFD ld) against clang-built libc++.dll succeed. Opposite should success too, but I haven't tested yet.


https://github.com/llvm/llvm-project/pull/141040