I don't understand why we don't always do that. We do it for normal `if`s
in the code, but not for preprocessor `if`s? It's a lot more readable when
indented properly.
llvm-svn: 356693
This documentation was removed when we added <filesystem> to the dylib
in r356518, but it really should have been updated to reflect the new
state of things. Keeping documentation around doesn't hurt and users
will have an easier time migrating.
llvm-svn: 356681
Summary:
Add relational benchmark against a string constant.
These can potentially trigger inlining of the operations. We want to
benchmark that.
Reviewers: EricWF
Subscribers: christof, jdoerfert, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D59512
llvm-svn: 356680
_LIBCPP_TYPE_VIS is only really needed on types with a vtable.
And on Windows it doesn't work with types that have only inline methods.
This patch removes the unneeded attributes.
llvm-svn: 356637
Summary: Filesystem doesn't work on Windows, so we need a mechanism to turn it off for the time being.
Reviewers: ldionne, serge-sans-paille, EricWF
Reviewed By: EricWF
Subscribers: mstorsjo, mgorny, christof, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59619
llvm-svn: 356633
`unsigned long` is 32-bit on 32-bit systems and 64-bit on 64-bit systems
on LP64 systems -- which most Unix systems are, but Windows isn't.
Windows is LLP64, which means unsigned long is 32-bit even on 64-bit
systems.
pplwin.h contains
static_assert(alignof(void *) == alignof(::std::once_flag), ...)
which fails due to this problem.
Instead of unsigned long, use uintptr_t, which consistently is 32-bit
on 32-bit systems and 64-bit on 64-bit systems.
No functional change except on 64-bit Windows.
Differential Revision: https://reviews.llvm.org/D59607
llvm-svn: 356624
Summary:
Also add the corresponding XFAILs to tests that require filesystem.
The approach taken to mark <filesystem> as unavailable in this patch
is to mark all the header as unavailable using #pragma clang attribute.
Marking each declaration using the attribute is more intrusive and
does not provide a lot of value right now because pretty much everything
in <filesystem> requires dylib support, often transitively.
This is an alternative to https://reviews.llvm.org/D59093.
A similar (but partial) patch was already applied in r356558.
Reviewers: mclow.lists, EricWF, serge-sans-paille
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59224
llvm-svn: 356616
Summary:
This change allows specifying the version of libc++abi's ABI to re-export
when configuring CMake. It also clearly identifies which ABI version of
libc++abi each export file contains.
Finally, it removes hardcoded knowledge about the 10.9 SDK for MacOS,
since that knowledge is not relevant anymore. Indeed, libc++ can't be
built with the toolchain that came with the 10.9 SDK anyway because
the version of Clang it includes is too old (for example if you want
to build a working libc++.dylib, you need bugfixes to visibility
attributes that are only in recent Clangs).
Reviewers: dexonsmith, EricWF
Subscribers: mgorny, christof, jkorous, arphaman, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59489
llvm-svn: 356587
This fixes CI for back-deployment testers on platforms that don't have
<filesystem> support in the dylib.
This is effectively half of https://reviews.llvm.org/D59224. The other
half requires fixes in Clang.
llvm-svn: 356558
This silences a known issue, as can be seen by looking at similar
tests for other clocks, like time.clock.steady/consistency.pass.cpp.
llvm-svn: 356528
Summary:
This patch treats <filesystem> as a first-class citizen of the dylib,
like all other sub-libraries (e.g. <chrono>). As such, it also removes
all special handling for installing the filesystem library separately
or disabling part of the test suite from the lit command line.
Unlike the previous attempt (r356500), this doesn't remove all the
filesystem tests.
Reviewers: mclow.lists, EricWF, serge-sans-paille
Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59152
llvm-svn: 356518
When I applied r356500 (https://reviews.llvm.org/D59152), I somehow
deleted all of filesystem's tests. I will revert r356500 and re-apply
it properly.
llvm-svn: 356505
Summary:
This patch treats <filesystem> as a first-class citizen of the dylib,
like all other sub-libraries (e.g. <chrono>). As such, it also removes
all special handling for installing the filesystem library separately
or disabling part of the test suite from the lit command line.
Reviewers: mclow.lists, EricWF, serge-sans-paille
Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59152
llvm-svn: 356500
Summary:
Otherwise, implicit instantiations of templates with these types can
cause the dylib to start exporting the vtable/RTTI of the instantiation.
Giving hidden visibility to those types causes the compiler to understand
that they are not used outside the dylib, and as a result implicitly
instantiated vtables/RTTI of templates with those internal types will
get hidden visibility.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59550
llvm-svn: 356488
Summary:
The reason libc++ implemented a throwing debug mode handler was for ease of testing. Specifically,
I thought that if a debug violation aborted, we could only test one violation per file. This made
it impossible to test debug mode. Which throwing behavior we could test more!
However, the throwing approach didn't work either, since there are debug violations underneath noexcept
functions. This lead to the introduction of `_NOEXCEPT_DEBUG`, which was only noexcept when debug
mode was off.
Having thought more and having grown wiser, `_NOEXCEPT_DEBUG` was a horrible decision. It was
viral, it didn't cover all the cases it needed to, and it was observable to the user -- at worst
changing the behavior of their program.
This patch removes the throwing debug handler, and rewrites the debug tests using 'fork-ing' style
death tests.
Reviewers: mclow.lists, ldionne, thomasanderson
Reviewed By: ldionne
Subscribers: christof, arphaman, libcxx-commits, #libc
Differential Revision: https://reviews.llvm.org/D59166
llvm-svn: 356417
Even though the header makes the exact same check since https://llvm.org/D59063,
the headers could conceivably change in the future and introduce a bug.
llvm-svn: 356376
CMake will define -Dcxx_shared_EXPORTS when building the shared library
by default. In theory, this is used to signal to the library that we're
building a shared library and that dllimport/dllexport should be used.
However, we already have our own way of doing that, so I'm removing this
define to avoid meaningless command line arguments in the build.
llvm-svn: 356167
Summary:
In r355746, we stopped forcing to build with -fPIC because that should
be specified by the CMAKE_POSITION_INDEPENDENT_CODE option at CMake
configure time (and by default -fPIC is used for shared libraries anyways).
However, r355746 had to be reverted in r355756 because we were not
actually building the shared library with -fPIC. The reason is that
we were sharing an object library between the static and the shared
library, which caused flags for static libraries to be used when
building object files that were going to be used for a shared library.
Since this was resolved by r356150, we can stop forcing -fPIC again.
Reviewers: EricWF, smeenai
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59250
llvm-svn: 356153
Summary:
The problem with using an object library for doing this is that it prevents
the shared library and the static library from being built with the right
default flags. For example, CMake will build shared libraries with -fPIC
by default, but not static libraries. Using an object library to create
the shared library will prevent the right default flags for shared
libraries from being used.
As a side effect, this patch also localizes the logic related to building
a hermetic static library to the static library case, making clear that
this has no effect on the shared library.
Reviewers: phosek, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59248
llvm-svn: 356150
Marshall Clow