Commit Graph

65 Commits

Author SHA1 Message Date
zoecarver fab194898b [lic++][docs] Explain noexcept policy for narrow contracts.
Adds documentation around libc++'s policy to add noexcept to things that cannot throw but aren't marked as noexcept.

Refs LWG 3518 and D95251.

Differential Revision: https://reviews.llvm.org/D95821
2021-02-05 11:27:19 -08:00
Shoaib Meenai 0066a09579 [libc++] Give extern templates default visibility on gcc
Contrary to the current visibility macro documentation, it appears that
gcc does handle visibility attribute on extern templates correctly, e.g.
https://godbolt.org/g/EejuV7. We need this so that extern template
instantiations of classes not marked _LIBCPP_TEMPLATE_VIS (e.g.
__vector_base_common) are correctly exported with gcc when building with
hidden visibility.

Reviewed By: ldionne

Differential Revision: https://reviews.llvm.org/D35388
2021-01-12 18:30:56 -08:00
Marek Kurdej 044b892c79 [libc++] Use c++20 instead of c++2a consistently.
* The only exception is that the flag -std=c++2a is still used not to break compatibility with older compilers (clang <= 9, gcc <= 9).
* Bump _LIBCPP_STD_VER for C++20 to 20 and use 21 for the future standard (C++2b).

That's a preparation step to add c++2b support to libc++.

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D93383
2021-01-07 13:11:33 +01:00
Louis Dionne 2eadbc8614 [libc++] Rework the whole availability markup implementation
Currently, vendor-specific availability markup is enabled by default.
This means that even when building against trunk libc++, the headers
will by default prevent you from using some features that were not
released in the dylib on your target platform. This is a source of
frustration since people building libc++ from sources are usually not
trying to use some vendor's released dylib.

For that reason, I've been thinking for a long time that availability
annotations should be off by default, which is the primary change that
this commit enables.

In addition, it reworks the implementation to make it easier for new
vendors to add availability annotations for their platform, and it
refreshes the documentation to reflect the current state of the codebase.

Finally, a CMake configuration option is added to control whether
availability annotations should be turned on for the flavor of libc++
being created. The intent is for vendors like Apple to turn it on, and
for the upstream libc++ to leave it off (the default).

Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 12:28:52 -05:00
Louis Dionne 647fb6b374 [libc++] Update the <version> header in-place from generate_feature_test_macro_components
This simplifies the workflow for adding new feature-test macros for
contributors. Previously, they would have to move the generated <version>
header from a temporary directory to libc++'s include directory by hand.
This makes the behavior for the <version> header consistent with what's
done for the tests and the documentation.
2020-10-13 09:18:35 -04:00
Louis Dionne f980ed4184 [libcxx] Remove the 'availability' Lit feature
Instead, use with_system_cxx_lib with various compile-only tests to ensure
that we're getting compile-time errors, as expected. This follows the
lead of ec46cfefe8.
2020-09-11 11:34:49 -04:00
Louis Dionne ec46cfefe8 [libcxx] Simplify back-deployment testing
The needs of back-deployment testing currently require two different
ways of running the test suite: one based on the deployment target,
and one based on the target triple. Since the triple includes all the
information we need, it's better to have just one way of doing things.

Furthermore, `--param platform=XXX` is also supersedded by using the
target triple. Previously, this parameter would serve the purpose of
controling XFAILs for availability markup errors, however it is possible
to achieve the same thing by using with_system_cxx_lib only and using
.verify.cpp tests instead, as explained in the documentation changes.

The motivation for this change is twofold:
1. This part of the Lit config has always been really confusing and
   complicated, and it has been a source of bugs in the past. I have
   simplified it iteratively in the past, but the complexity is still
   there.
2. The deployment-target detection started failing in weird ways in
   recent Clangs, breaking our CI. Instead of band-aid patching the
   issue, I decided to remove the complexity altogether by using target
   triples even on Apple platforms.

A follow-up to this commit will bring the test suite in line with
the recommended way of handling availability markup tests.
2020-09-10 08:17:26 -04:00
Vy Nguyen 76887bc4c1 Reland [libcxx]Put clang::trivial_abi on smart pointers
Reviewed By: ldionne,EricWF

    Tags: #libcxx

    Differential Revision: https://reviews.llvm.org/D82490
2020-07-20 11:54:34 -04:00
Stephan Herhut 3341d470fc Revert "Revert "Revert "[libcxx] Put clang::trivial_abi on std::unique_ptr, std::shared_ptr, and std::weak_ptr"""
This reverts commit f706b01a00.
2020-07-06 12:18:17 +02:00
Vy Nguyen f706b01a00 Revert "Revert "[libcxx] Put clang::trivial_abi on std::unique_ptr, std::shared_ptr, and std::weak_ptr""
This reverts commit dc13ac0280.

Rolling forward + fix typos and unused variables in tests

    Differential Revision: https://reviews.llvm.org/D82490
2020-07-05 13:44:42 -04:00
Vy Nguyen dc13ac0280 Revert "[libcxx] Put clang::trivial_abi on std::unique_ptr, std::shared_ptr, and std::weak_ptr"
This reverts commit 5cde3c9633.

The tests were reported failing on clang10
2020-07-04 11:29:08 -04:00
Vy Nguyen 5cde3c9633 [libcxx] Put clang::trivial_abi on std::unique_ptr, std::shared_ptr, and std::weak_ptr
Reviewers: jyknight, EricWF, #libc!

Subscribers: arphaman, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D82490
2020-07-03 17:23:13 -04:00
Louis Dionne 21b0ec2fc6 [libc++] Do not rely on use_system_cxx_lib to specify the path of the library to run against
This is already handled by setting cxx_runtime_root instead -- I don't
see a reason to have two ways of setting the runtime path of the library
we're running against.
2020-05-15 13:01:37 -04:00
Louis Dionne 80aea8e4a8 [libc++] Simplify how with_system_cxx_lib and availability features are defined
Instead of spamming a bunch of available features that are not actually
used anywhere, only set those that are actually used in the test suite.
In the future, this should probably be based on the target triple only,
with the ability to have wildcards in the triple.
2020-04-14 08:28:05 -04:00
Louis Dionne 7149bb7068 [libc++] NFC: Clean up a lot of old Lit features
The libc++ test suite has a lot of old Lit features used to XFAIL tests
and mark them as UNSUPPORTED. Many of them are to workaround problems on
old compilers or old platforms. As time goes by, it is good to go and
clean those up to simplify the configuration of the test suite, and also
to reflect the testing reality. It's not useful to have markup that gives
the impression that e.g. clang-3.3 is supported, when we don't really
test on it anymore (and hence several new tests probably don't have the
necessary markup on them).
2020-04-10 17:20:29 -04:00
Eric Fiselier 4959542657 Add documentation and tests for Clangs C++11 extensions in C++03.
As we gear up to drop support for GCC in C++03, we should make clear
what our C++03 mode is, the C++11 extensions it provides,
and the C++11 extensions it depends on.

The section of this document discussing user-facing extensions has
been left blank while the community discusses new directions. For now
it's just a warning to users.

Additionally, the document contains examples of how these extensions
should be used and why. For example, using alias templates over class
templates.

llvm-svn: 363110
2019-06-11 22:53:49 +00:00
Louis Dionne 776acf225b [libcxx] Slightly improved policy for handling experimental features
Summary:
Following the discussion on the libcxx-dev mailing list
(http://lists.llvm.org/pipermail/libcxx-dev/2019-May/000358.html),
this implements the new policy for handling experimental features and
their deprecation. We basically add a deprecation warning for
std::experimental::filesystem, and we remove a bunch of <experimental/*>
headers that were now empty.

Reviewers: mclow.lists, EricWF

Subscribers: mgorny, christof, jkorous, dexonsmith, arphaman, libcxx-commits, jfb

Tags: #libc

Differential Revision: https://reviews.llvm.org/D62428

llvm-svn: 363072
2019-06-11 14:48:40 +00:00
Eric Fiselier 99dfd7084d update debugging docs to be less out of date
llvm-svn: 362866
2019-06-08 04:59:41 +00:00
Louis Dionne 51358e45e2 [libcxx] Start defining lit features for tests depending on availability
This patch removes some vendor-specific availability XFAILs from the
test suite. In the future, when a new feature is introduced in the
dylib, an availability macro should be created and a matching lit
feature should be created. That way, the test suite can XFAIL whenever
the implementation lacks the necessary feature instead of being
cluttered by vendor-specific annotations.

Right now, those vendor-specific annotations are still somewhat cluttering
the test suite by being in `config.py`, but at least they are localized.
In the future, we could design a way to define those less intrusively or
even automatically based on the availability macros that already exist
in <__config>.

llvm-svn: 353201
2019-02-05 19:22:38 +00:00
JF Bastien 2df59c5068 Support tests in freestanding
Summary:
Freestanding is *weird*. The standard allows it to differ in a bunch of odd
manners from regular C++, and the committee would like to improve that
situation. I'd like to make libc++ behave better with what freestanding should
be, so that it can be a tool we use in improving the standard. To do that we
need to try stuff out, both with "freestanding the language mode" and
"freestanding the library subset".

Let's start with the super basic: run the libc++ tests in freestanding, using
clang as the compiler, and see what works. The easiest hack to do this:

In utils/libcxx/test/config.py add:

  self.cxx.compile_flags += ['-ffreestanding']

Run the tests and they all fail.

Why? Because in freestanding `main` isn't special. This "not special" property
has two effects: main doesn't get mangled, and main isn't allowed to omit its
`return` statement. The first means main gets mangled and the linker can't
create a valid executable for us to test. The second means we spew out warnings
(ew) and the compiler doesn't insert the `return` we omitted, and main just
falls of the end and does whatever undefined behavior (if you're luck, ud2
leading to non-zero return code).

Let's start my work with the basics. This patch changes all libc++ tests to
declare `main` as `int main(int, char**` so it mangles consistently (enabling us
to declare another `extern "C"` main for freestanding which calls the mangled
one), and adds `return 0;` to all places where it was missing. This touches 6124
files, and I apologize.

The former was done with The Magic Of Sed.

The later was done with a (not quite correct but decent) clang tool:

  https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed

This works for most tests, though I did have to adjust a few places when e.g.
the test runs with `-x c`, macros are used for main (such as for the filesystem
tests), etc.

Once this is in we can create a freestanding bot which will prevent further
regressions. After that, we can start the real work of supporting C++
freestanding fairly well in libc++.

<rdar://problem/47754795>

Reviewers: ldionne, mclow.lists, EricWF

Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits

Differential Revision: https://reviews.llvm.org/D57624

llvm-svn: 353086
2019-02-04 20:31:13 +00:00
Eric Fiselier 508da4156a Move the feature test macros script to the utils directory.
It doesn't make a lot of sense to keep it with the tests,
deep into the test suite directonies.

llvm-svn: 352970
2019-02-02 23:13:49 +00:00
Chandler Carruth bd9dafecf7 Update an example to use the new LLVM file header.
llvm-svn: 351653
2019-01-19 11:54:04 +00:00
Eric Fiselier 32784a740a Implement feature test macros using a script.
Summary:
This patch implements all the feature test macros libc++ currently supports, as specified by the standard or cppreference prior to C++2a.

The tests and `<version>` header are generated using a script. The script contains a table of each feature test macro, the headers it should be accessible from, and its values of each dialect of C++.
When a new feature test macro is added or needed, the table should be updated and the script re-run.



Reviewers: mclow.lists, jfb, serge-sans-paille

Reviewed By: mclow.lists

Subscribers: arphaman, jfb, ldionne, libcxx-commits

Differential Revision: https://reviews.llvm.org/D56750

llvm-svn: 351286
2019-01-16 01:37:43 +00:00
Louis Dionne 737be83d20 [libcxx] Remove the availability_markup LIT feature
It is now equivalent to the 'availability' LIT feature, so there's no
reason to keep both.

llvm-svn: 348653
2018-12-07 21:48:39 +00:00
Louis Dionne f14927e98e [libcxx] Always enable availability in the lit test suite.
Summary:
Running the tests without availability enabled doesn't really make sense:
availability annotations allow catching errors at compile-time instead
of link-time. Running the tests without availability enabled allows
confirming that a test breaks at link-time under some configuration,
but it is more useful to instead check that it should fail at compile-time.

Always enabling availability in the lit test suite will greatly simplify
XFAILs and troubleshooting of failing tests, which is currently a giant
pain because we have these two levels of possible failure: link-time and
compile-time.

Reviewers: EricWF, mclow.lists

Subscribers: christof, jkorous, dexonsmith, libcxx-commits

Differential Revision: https://reviews.llvm.org/D55079

llvm-svn: 348296
2018-12-04 19:31:08 +00:00
Louis Dionne 2e5f0c4e16 [NFC] Fix formatting in availability documentation
llvm-svn: 347362
2018-11-20 23:07:01 +00:00
Louis Dionne 9b3222f613 [libc++] Make sure we can build libc++ with -fvisibility=hidden
Summary:
When building with -fvisibility=hidden, some symbols do not get exported from
libc++.dylib. This means that some entities are not explicitly given default
visibility in the source code, and that we rely on the fact -fvisibility=default
is the default. This commit explicitly gives default visibility to those
symbols to avoid being dependent on the command line flags used.

The commit also remove symbols from the dylib -- those symbols do not
actually need to be exported from the dylib and this should not be an
ABI break.

Finally, in the future, we may want to mark the whole std:: namespace as
having hidden visibility (to switch from opt-out to opt-in), in which
case the changes done in this commit will be required.

Reviewers: EricWF

Subscribers: mgorny, christof, dexonsmith, libcxx-commits

Differential Revision: https://reviews.llvm.org/D52662

llvm-svn: 345260
2018-10-25 12:13:43 +00:00
Sylvestre Ledru 6616b4c9e9 fix some typos in the doc
llvm-svn: 342628
2018-09-20 08:05:01 +00:00
Louis Dionne 61cd687009 [libcxx] By default, do not use internal_linkage to hide symbols from the ABI
Summary:
https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and
we expect this may be the case in other projects built in debug mode too.
Instead, unless users explicitly ask for internal_linkage, we use always_inline
like we used to.

In the future, when we have a solution that allows us to drop always_inline
without falling back on internal_linkage, we can replace always_inline by
that.

Note that this commit introduces a change in contract for existing libc++
users: by default, libc++ used to guarantee that TUs built with different
versions of libc++ could be linked together. With the introduction of the
_LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built
with different libc++ versions are not guaranteed to link. This is a change
in contract but not a change in behavior, since the current implementation
still allows linking TUs built with different libc++ versions together.

Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk

Subscribers: christof, cfe-commits

Differential Revision: https://reviews.llvm.org/D50652

llvm-svn: 339874
2018-08-16 12:44:28 +00:00
Louis Dionne ba71bd7c55 [libc++] Add the _LIBCPP_HIDE_FROM_ABI_AFTER_V1 macro
Summary:
This macro allows hiding symbols from the ABI when the library is built
with an ABI version after ABI v1, which is currently the only stable ABI.
This commit defines `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` to be
`_LIBCPP_HIDE_FROM_ABI_AFTER_V1`, meaning that symbols that were only
exported by the library for historical reasons are not exported anymore
in the unstable ABI.

Because of that, this commit is an ABI break for ABI v2. This ABI version
is not stable, however, so this should not be a problem.

Reviewers: EricWF, mclow.lists

Subscribers: christof, dexonsmith, cfe-commits

Differential Revision: https://reviews.llvm.org/D49914

llvm-svn: 339012
2018-08-06 14:11:50 +00:00
Louis Dionne cb3eb30636 [libc++] Introduce _LIBCPP_HIDE_FROM_ABI to replace _LIBCPP_INLINE_VISIBILITY
Summary:
This commit introduces a new macro, _LIBCPP_HIDE_FROM_ABI, whose goal is to
mark functions that shouldn't be part of libc++'s ABI. It marks the functions
as being hidden for dylib visibility purposes, and as having internal linkage
using Clang's __attribute__((internal_linkage)) when available, and
__always_inline__ otherwise.

It replaces _LIBCPP_INLINE_VISIBILITY, which was always using __always_inline__
to achieve similar goals, but suffered from debuggability and code size problems.
The full proposal, along with more background information, can be found here:

    http://lists.llvm.org/pipermail/cfe-dev/2018-July/058419.html

This commit does not rename uses of _LIBCPP_INLINE_VISIBILITY to
_LIBCPP_HIDE_FROM_ABI: this wide reaching but mechanical change can
be done later when we've confirmed we're happy with the new macro.

In the future, it would be nice if we could optionally allow dropping
any internal_linkage or __always_inline__ attribute, which could result
in code size improvements. However, this is currently impossible for
reasons explained here: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058450.html

Reviewers: EricWF, dexonsmith, mclow.lists

Subscribers: christof, dexonsmith, llvm-commits, mclow.lists

Differential Revision: https://reviews.llvm.org/D49240

llvm-svn: 338122
2018-07-27 12:46:03 +00:00
Louis Dionne f636411a5e [NFC] Fix grammatical mistakes in libc++ FileTimeType design docs
llvm-svn: 337925
2018-07-25 13:40:49 +00:00
Eric Fiselier b54393e638 Fix another typo in the FileTimeType docs
llvm-svn: 337900
2018-07-25 10:22:07 +00:00
Eric Fiselier f0b379c959 Fix typos, spelling, and grammar in the FileTimeType design docs.
I'm sure I'll discover more mistakes as I go on...

llvm-svn: 337897
2018-07-25 10:17:04 +00:00
Eric Fiselier d981977d5a Add design docs for upcoming file_time_type change.
In upcoming changes to filesystem I plan to change file_time_type
to use __int128_t as its underlying representation, in order
to allow it to have a range and resolution at least that of
the timespec struct.

There was some pushback against this decision, so I drafted
a document explaining the problems, potential solutions, and
the rational for the decision.

However, it's probably easier to let people read the generated
HTML rather than the raw restructured text. For this reason
I'm commiting the design documents before hand, so they can
be available during any subsequent discussion or code review.

llvm-svn: 337880
2018-07-25 02:53:53 +00:00
Louis Dionne dc7200b486 [libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.

This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.

Note that this commit had originally been applied in r336369 and then
reverted in r336382 because of unforeseen problems. Both of these problems
have now been fixed.

Reviewers: EricWF, mclow.lists

Subscribers: christof, dexonsmith, erikvanderpoel

Differential Revision: https://reviews.llvm.org/D48892

llvm-svn: 336866
2018-07-11 23:14:33 +00:00
Louis Dionne 195a499d63 Revert "[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY"
This reverts commit r336369. The commit had two problems:
1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of
   _LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the
   dylib and the check-cxx-abilist failing.

2. The LLDB tests started failing because they undefine
   `_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and
   fix the tests before we can go forward with this change.

llvm-svn: 336382
2018-07-05 18:41:50 +00:00
Louis Dionne 4a8f3f9948 [libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.

This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.

Reviewers: EricWF

Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists

Differential Revision: https://reviews.llvm.org/D48892

llvm-svn: 336369
2018-07-05 16:49:38 +00:00
Bruce Mitchener f684c9c83c Fix typos.
Reviewers: mclow.lists, EricWF

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D43224

llvm-svn: 324989
2018-02-13 08:12:00 +00:00
Martin Storsjo bf02a09103 [cmake] Add a config option LIBCXX_HAS_WIN32_THREAD_API for enforcing win32 threads
This allows keeping libcxx using win32 threads even if a
version of pthread.h is installed.

This matches the existing cmake option LIBCXX_HAS_PTHREAD_API.

Also add missing documentation about the internal define
_LIBCPP_HAS_THREAD_API_WIN32.

Differential Revision: https://reviews.llvm.org/D41764

llvm-svn: 321896
2018-01-05 20:48:29 +00:00
Shoaib Meenai 24767a7c2f [libc++] class template -> template class. NFC
llvm-svn: 307972
2017-07-13 22:08:59 +00:00
Shoaib Meenai 5b67cd3567 [libc++] Mark string operator+ _LIBCPP_FUNC_VIS
It has an extern template instantiation declaration in the headers and a
corresponding instantiation definition in the library, so we must mark
it with _LIBCPP_FUNC_VIS to make it available outside the library.

This doesn't cause any ABI changes as-is since we don't build libc++
with hidden visibility (so the function is exported anyway). It's needed
for building libc++ with hidden visibility, however.

Clarify the Windows behavior for extern function templates while I'm
here, since this exercises that behavior.

llvm-svn: 307966
2017-07-13 21:35:52 +00:00
Shoaib Meenai 982060b0a4 [libc++] Use proper template terminology. NFC
It's supposed to be "class template" and "function template" instead of
"template class" and "template function".

llvm-svn: 307954
2017-07-13 20:47:24 +00:00
Mehdi Amini e9c66ad9fa Add markup for libc++ dylib availability
Libc++ is used as a system library on macOS and iOS (amongst others). In order
for users to be able to compile a binary that is intended to be deployed to an
older version of the platform, clang provides the
availability attribute <https://clang.llvm.org/docs/AttributeReference.html#availability>_
that can be placed on declarations to describe the lifecycle of a symbol in the
library.

See docs/DesignDocs/AvailabilityMarkup.rst for more information.

Differential Revision: https://reviews.llvm.org/D31739

llvm-svn: 302172
2017-05-04 17:08:54 +00:00
Shoaib Meenai bda3c7df78 [libc++] Make _LIBCPP_TYPE_VIS export members
Summary:
Most classes annotated with _LIBCPP_TYPE_VIS need to have at least some
of their members exported, otherwise we have a lot of link errors when
linking against a libc++ built with hidden visibility. This also makes
_LIBCPP_TYPE_VIS be consistent across platforms, since on Windows it
already exports members.

With this change made, any template methods of a class marked
_LIBCPP_TYPE_VIS will also get default visibility when instantiatied,
which is not desirable for clients of libc++ headers who wish to control
their visibility; this is the same issue as PR30642. Annotate all
problematic methods with an explicit visibility specifier to avoid this.

The problematic methods were found by running bad-visibility-finder [1]
against the libc++ headers after making the _LIBCPP_TYPE_VIS change. The
small methods were marked for inlining; the larger ones hidden.

[1] https://github.com/smeenai/bad-visibility-finder

Reviewers: mclow.lists, EricWF

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D25208

llvm-svn: 296732
2017-03-02 03:22:18 +00:00
Shoaib Meenai bad28c44eb [libc++] Make _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS export members
When building libc++ with hidden visibility, we want explicit template
instantiations to export members. This is consistent with existing
Windows behavior, and is necessary for clients to be able to link
against a hidden visibility built libc++ without running into lots of
missing symbols.

An unfortunate side effect, however, is that any template methods of a
class with an explicit instantiation will get default visibility when
instantiated, unless the methods are explicitly marked inline or hidden
visibility. This is not desirable for clients of libc++ headers who wish
to control their visibility, and led to PR30642.

Annotate all problematic methods with an explicit visibility specifier
to avoid this. The problematic methods were found by running
https://github.com/smeenai/bad-visibility-finder against the libc++
headers after making the _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS change. The
methods were marked with the new _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
macro, which was created for this purpose.

It should be noted that _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS was originally
intended to expand to default visibility, and was changed to expanding
to default type visibility to fix PR30642. The visibility macro
documentation was not updated accordingly, however, so this change makes
the macro consistent with its documentation again, while explicitly
fixing the methods which resulted in that PR.

Differential Revision: https://reviews.llvm.org/D29157

llvm-svn: 296731
2017-03-02 03:02:50 +00:00
Eric Fiselier cd1703b241 Fix typo in docs
llvm-svn: 294115
2017-02-05 01:16:25 +00:00
Eric Fiselier fc26379a84 [libc++] Introduce _LIBCPP_EXTERN_VIS to fix __libcpp_debug_function link errors
Summary: On Windows tests that use `_LIBCPP_ASSERT` fail to link because the assertion handler function isn't correctly exported from the libc++ dylib. This patch fixes the dll import/export issues by introducing a new visibility macro `_LIBCPP_EXTERN_VIS` for use on external variables.

Reviewers: compnerd, smeenai, EricWF

Reviewed By: EricWF

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D28728

llvm-svn: 292158
2017-01-16 21:01:00 +00:00
Asiri Rathnayake e3d832a3e8 [libcxx] Improve design documentation for the external-thread-library
configuration

NFC.

Differential revision: https://reviews.llvm.org/D28610

Reviewers: EricWF
llvm-svn: 292108
2017-01-16 12:44:08 +00:00
Shoaib Meenai 1b0bda3310 [libc++] Correct macro name in documenation
The macro is named `_LIBCPP_TEMPLATE_VIS`, not `_LIBCPP_TEMPLATE_ONLY`.
No functional change.

llvm-svn: 291330
2017-01-07 02:45:35 +00:00