[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:

> > 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.


> (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. In fact, my ad-hoc patch causes doubly-exporting constructors of inner class.

I would prefer to first resolve the incompatibility between Clang and GCC with this PR (and 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?

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