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

I'll try to elaborate here...

> It seems that @mstorsjo doesn’t have a strong position either way, and I understand that this PR may not have enough support at the moment.

First I wanted to clarify, that for the scope of this change, my original preference was that we should fix Clang instead.

---

However I'd like to add, that I'm pleasantly surprised to see that this change looks very small in scope. But it's also quite non-obvious.

About this change in itself, as far as I see, we're explicitly adding the `inline` keyword, across all platforms. Does that have any effect on what code gets generated on other platforms? Then for mingw platforms, we're adding the `_LIBCPP_HIDE_FROM_ABI` annotation. (Also, if we go the way of this platform, it would be good to include a link to the bugzilla entry in the large comment in `__config`.)

(I'm sorry I haven't had so much time to spend on getting deeply familiar with the solutions here, lately. I'm interested in understanding the fix better.)

---

One reason for why I'd want to avoid this, is that getting dllexport/import attribute annotations right is complex already. By going this way, we add even more nuanced rules for how library designers need to annotate their classes, to work across DLLs. There's already some divergence between msvc and mingw for template instantiations, see `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` vs `_LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS`, and by codifying this, we'd be essentially enforcing another arbitrary rule that requires diverging. Will we possibly need to apply the same trick on other codebases going forward as well.

One concrete case, is that the LLVM/Clang codebases themselves are getting dllexport/import annotations (in progress). Mingw builds don't use them currently, but once they are complete enough for MSVC style builds, we should transition mingw builds to use that as well. If there are similar cases there (which I understand there may be?) we would need to add similar tricks there as well.

So to simplify development/maintainance of other code bases, I'd prefer to have the fix on the Clang side, to reduce the differences needed between msvc and mingw style builds.

> I still think that this is probably the best option, given the intransigence of GCC

I do see this point though. And given the case of LLVM/Clang dylib builds, which currently are somewhat broken with GCC for mingw targets, it would be good if they also would work. So that would maybe require some tricks like these.


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