This does not affect the libc++ export list now.
It is required for internal_linkage switch to not affect the libc++ export list.
This patch is on top of D15432.
Details
Details
- Reviewers
EricWF
Diff Detail
Diff Detail
- Repository
- rL LLVM
Event Timeline
Comment Actions
Won't this mean that libc++ possibly exports 3 more template definitions? I think this is likely safe but I would rather not export any more symbols if it can be avoided.
I'm probably nitpicking here though.
include/valarray | ||
---|---|---|
823 | So I think we still want the almost every instantiation of valarray<Tp>::~valarray() to have internal linkage except for the specialization valarray<size_t>::~valarray(); Do you see any way to make this possible? |
Comment Actions
Libc++.so does not instantiate valarray for any other types, so this does not add any extra exports.
Definitions valarray members (with types other than size_t) will now be exported from user code. This looks like a positive change to me:
- these methods are already part of the ABI due to the exported template valarray<size_t>
- exported vs hidden/internal can produce smaller code
So I think we still want the almost every instantiation of valarray<Tp>::~valarray() to have internal linkage except for the specialization valarray<size_t>::~valarray(); Do you see any way to make this possible?