kikairoya wrote: It appears that libc++ already expects that `exclude_from_explicit_instantiation` to take precedence over `dllexport`/`dllimport` in a non-template context.
https://github.com/llvm/llvm-project/blob/b72d8ac98c6eee51ac66bc865c81a23a16c37731/libcxx/include/__format/format_error.h#L27-L35 This is effectively expanded to ```c++ class __declspec(dllimport) format_error : public runtime_error { public: __attribute__((__exclude_from_explicit_instantiation__)) __attribute__((__abi_tag__(...))) explicit format_error(const string& __s) : runtime_error(__s) {} __attribute__((__exclude_from_explicit_instantiation__)) __attribute__((__abi_tag__(...))) explicit format_error(const char* __s) : runtime_error(__s) {} __attribute__((__exclude_from_explicit_instantiation__)) __attribute__((__abi_tag__(...))) format_error(const format_error&) = default; __attribute__((__exclude_from_explicit_instantiation__)) __attribute__((__abi_tag__(...))) format_error& operator=(const format_error&) = default; __attribute__((__exclude_from_explicit_instantiation__)) ~format_error() noexcept override = default; }; ``` Should we export/import these methods? Regarding the intent of `_LIBCPP_HIDE_FROM_ABI`, we shouldn't. However, the name `__exclude_from_explicit_instantiation__` doesn't imply any effect to a non-template (more precisely, to a non explicitly instantiated template specialization) entity. Ideally, I think the `_LIBCPP_HIDDEN` macro, that used in `_LIBCPP_HIDE_FROM_ABI`, should be expanded to a (maybe new?) attribute that means "not to export/import this" more directly. Anyways, I'll keep the attribute silently ignored in a non-template context for now, except when both of the exclude and dll attributes are attached directly. https://github.com/llvm/llvm-project/pull/183514 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
