Add _LIBCPP_TEMPLATE_VIS. The new name is more descriptive of what the
intention is. The previous name did not convey the intention of the decoration.
This is mostly a mechanical change, changing instances of _LIBCPP_TYPE_VIS_ONLY
where they were applied to template instances.
Details
- Reviewers
mclow.lists nrieck
Diff Detail
Event Timeline
This naming change makes a lot of sense to me.
The reason we have this alternative macro is because it makes no sense to dllexport a template. MSVC's semantics for it are not useful at all.
See : http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-July/030629.html
and: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html
and: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130805/085523.html
for history on this issue.
The last one is Howard's take on some of the (non-mechanical) changes you've proposed.
I don't think we should be using this linkage on non-template types, even if Howard thought they were "header only". Even those tag types can be exported from libc++. If someone takes the address of a tag or once_flag assignment operator, libc++ should have a definition of it. Marking it as dllexport (aka _LIBCPP_TYPE_VISIBILITY) makes that work.
On the other hand, we have things like struct nullptr_t, which are never compiled while building libc++ itself. Saleem has moved to give them no decoration, which means each DSO would get its own set of member functions with distinct addresses.
The upshot is I think we should go forward with this change. This attribute really shouldn't be applied to non-template types, despite what Howard said in the past.
This version of the patch is super old. A branch new version is up for review here: https://reviews.llvm.org/D28174 If there are no objections I'll commit that patch tomorrow.