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

[Martin Storsjö via libcxx-commits]

mstorsjo wrote:

> > > Can you elaborate on what would break if we'd try to fix this on the Clang side (making Clang do similarly to what GCC does, but self-consistently by making it export the nested class, like the dllimport behaviour seems to expect)?
> > 
> > 
> > I think that makes a new 'dialect' to be avoided (but I understand should not to emulate GCC's defect, too). As real harm, reverse of #135910 might occur but I don't have any test. Need a time to clarify that harms or not.
> 
> I have tested with this patch: https://gist.github.com/kikairoya/97c6daea92b94db2d5b72fb200ddd1bd and can't find that reverse of #135910 or similar problem occurs from combinations of DLL+EXE or DLL+DLL+EXE built by Clang with this patch or GCC, on Cygwin environment. Thus, I would say the approach can be viable without breaking existing binaries.

Thanks for investigating where and how this can be fixed! That's very much appreciated!

> > (as it is mostly consistent across mingw and linux right now - the only inconsistency in GCC is where dllexport applies)
> 
> My understand through this test, in Clang, handling of dllexport/dllimport quite differs from visibility control and might require a large refactoring to make its semantics consist to visibility control.

Do you mean that within Clang, dllexport/import and visibility are handled in different ways? Yes, that's probably true.

> In fact, my ad-hoc patch causes doubly-exporting constructors of inner class.

Hmm, in which way does it cause them to be doubly exported? Does it emit two `dllexport` attributes somehow, or does it generate two instances of the same function?

> I would prefer to first resolve the incompatibility between Clang and GCC with this PR (and [#135910 (comment)](https://github.com/llvm/llvm-project/issues/135910#issuecomment-2849326422) ), and then discuss how Clang’s behavior should be handled in a follow-up. Would that be acceptable to you, @mstorsjo?

It's not up to me, it's more up to the libc++ maintainers (who are quite limited on time, unfortunately), and how well we can argue the case that the complexity added by these patches is acceptable and warranted.

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