[libcxx-commits] [PATCH] D97168: [libcxx] Don't use dllimport for a static member in a template
Martin Storsjö via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Mar 2 08:30:11 PST 2021
mstorsjo added inline comments.
================
Comment at: libcxx/include/__config:673
+#ifndef _LIBCPP_DATA_VIS
+# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
----------------
rnk wrote:
> mstorsjo wrote:
> > ldionne wrote:
> > > Maybe this can just be called `_LIBCPP_DEFAULT_VISIBILITY`?
> > >
> > > And we could maybe also reuse this macro in the various `_LIBCPP_FUNC_VIS` & other macros (as a separate patch, I can try to clean this up).
> > Hmm, not entirely sure, that changes the semantics a bit: Currently the attributes say what they're supposed to annotate (function visibility, type visibility, etc), but that'd make it say what it does (on one platform) - which actually isn't the same across all platforms (the point here being we expressly want a different visibility for windows targets, for static members in a template, contrary to the other cases).
> Yeah, this is tough. Seeing the new name, I'm not sure I like it. @ldionne is right, we can export data. The restriction is that things with weak linkage can't be imported/exported, since they don't belong only to the libc++ DLL.
>
> Do you think it's reasonable to use `_LIBCPP_TEMPLATE_VIS`? `std::basic_string<T...>::npos` is a "templated entitiy" (temploid?). It should work as is.
`_LIBCPP_TEMPLATE_VIS` seems ok to me; a new `_LIBCPP_TEMPLATE_DATA_VIS` would work too if we'd want a more precise name.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D97168/new/
https://reviews.llvm.org/D97168
More information about the libcxx-commits
mailing list