Back in 2020 [1], we went very close to enabling Filesystem on MSVC
by disabling int128_t, but decided to wait because MSVC support
for int128_t was supposed to come shortly after. Since it's not
there yet, I propose turning off int128_t support by default on MSVC.
This will make <filesystem> available by default on MSVC, and most
importantly will open the possibility for changing
LIBCXX_ENABLE_FILESYSTEM to mean "the system doesn't have support
for a filesystem" instead of simply "don't build the std::filesystem
library", which is what I'm really after with this change.
In a way, this is a resurection of D91139.
[1]: https://reviews.llvm.org/D91139#2429595
Differential Revision: https://reviews.llvm.org/D134912
This reverts commit d763c6e5e2.
Adds the patch by @hans from
https://github.com/llvm/llvm-project/issues/62719
This patch fixes the Windows build.
d763c6e5e2 reverted the reviews
D144509 [CMake] Bumps minimum version to 3.20.0.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
D150532 [OpenMP] Compile assembly files as ASM, not C
Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent)
when compiling a file which has been set as having the language
C. This behaviour change only takes place if "cmake_minimum_required"
is set to 3.20 or newer, or if the policy CMP0119 is set to new.
Attempting to compile assembly files with "-x c" fails, however
this is workarounded in many cases, as OpenMP overrides this with
"-x assembler-with-cpp", however this is only added for non-Windows
targets.
Thus, after increasing cmake_minimum_required to 3.20, this breaks
compiling the GNU assembly for Windows targets; the GNU assembly is
used for ARM and AArch64 Windows targets when building with Clang.
This patch unbreaks that.
D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump
The build uses other mechanism to select the runtime.
Fixes#62719
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D151344
This is just to test that the PSTL works with parallelization. This is not supposed to be a production-ready backend.
Reviewed By: ldionne, #libc
Spies: EricWF, arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D150284
This reverts commit 65429b9af6.
Broke several projects, see https://reviews.llvm.org/D144509#4347562 onwards.
Also reverts follow-up commit "[OpenMP] Compile assembly files as ASM, not C"
This reverts commit 4072c8aee4.
Also reverts fix attempt "[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump"
This reverts commit 7d47dac5f8.
The source file is used to anchor the destructor of format_error. When
format is moved from experimental to stable this code would move to the
dylib. One issue with code in the dylib is that it can't be used in
constexpr context. There is a proposal to make format work during
constant evaluation
P2758 Emitting messages at compile time
This paper has initially been received favourable by EWG. Therefore move
the code to the header. This also avoids possible availability issues on
Mac back deployment targets.
Note it is expected that format will no longer be experimental with the
next LLVM release.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D150073
This removes the need for a custom libc++ build to have a basic set of PSTL algorithms.
Reviewed By: ldionne, #libc
Spies: miyuki, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D149624
We decided to go a different route. To make the switch easier, rip out the old integration first and build on a clean base.
Reviewed By: ldionne, #libc, #libc_abi
Spies: arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D148480
This mostly keeps the same warning flags. The most important exceptions are `-Wpedantic` and `-Wconversion`, which are now removed from libc++abi and libunwind.
Reviewed By: ldionne, #libunwind, #libc, #libc_abi
Spies: mikhail.ramalho, phosek, libcxx-commits
Differential Revision: https://reviews.llvm.org/D144252
Clang wants to enable this flag by default, but libc++ isn't working with it yet.
Reviewed By: Mordante, #libc, #libc_abi, EricWF
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D144667
Some build bots have not been updated to the new minimal CMake version.
Reverting for now and ping the buildbot owners.
This reverts commit 44c6b905f8.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
Reviewed By: mehdi_amini, MaskRay, ChuanqiXu, to268, thieta, tschuett, phosek, #libunwind, #libc_vendors, #libc, #libc_abi, sivachandra, philnik, zibi
Differential Revision: https://reviews.llvm.org/D144509
We've been shipping <coroutine> since LLVM 14, so LLVM 17 won't ship
the <experimental/coroutine> header per our policy for removing TSes.
Differential Revision: https://reviews.llvm.org/D108697
Support for these CMake variables has been a warning for a while now. The
comment indicates to just remove the warning message entirely as anyone impacted
had to have update to new mechanisms in order to use `libc++`. So, remove the
warning message.
Differential Revision: https://reviews.llvm.org/D141345
This reverts commit bec8a372fc.
This causes many of these errors to appear when rebuilding runtimes part
of fuchsia's toolchain:
ld.lld: error:
/usr/local/google/home/paulkirth/llvm-upstream/build/lib/x86_64-unknown-linux-gnu/libunwind.a(libunwind.cpp.o)
is incompatible with elf64-x86-64
This can be reproduced by making a complete toolchain, saving any source
file with no changes, then rerunning ninja distribution.
This variable is derived from LLVM_DEFAULT_TARGET_TRIPLE by default,
but using a separate variable allows additional normalization to be
performed if needed.
Differential Revision: https://reviews.llvm.org/D137451
This allows porting the library to platforms that are able to support
<iostream> but that do not have a notion of a filesystem, and where it
hence doesn't make sense to support std::fstream (and never will).
Also, remove reliance on <fstream> in various tests that didn't
actually need it.
Differential Revision: https://reviews.llvm.org/D138327
We already had the ability to do that for libc++.dylib, so this only adds
consistency for all the runtime libraries. This should allow working around
difficulties on AIX as described in https://llvm.org/D134221.
Differential Revision: https://reviews.llvm.org/D135669
This patch enables libc++ build as shared library in all combinations of ASCII/EBCDIC and 32-bit/64-bit variants. In particular it introduces:
# ASCII version of libc++ named as libc++_a.so
# Script to rename DLL name inside the generated side deck
# Various names for dataset members where DLL libraries and their side decks will reside
# Add the following options:
- LIBCXX_SHARED_OUTPUT_NAME
- LIBCXX_ADDITIONAL_COMPILE_FLAGS
- LIBCXX_ADDITIONAL_LIBRARIES
- LIBCXXABI_ADDITIONAL_COMPILE_FLAGS
- LIBCXXABI_ADDITIONAL_LIBRARIES
**Background and rational of this patch**
The linker on z/OS creates a list of exported symbols in a file called side deck. The list contains the symbol name as well as the name of the DLL which implements the symbol. The name of the DLL depends on what is specified in the -o command line option. If it points to a USS file, than the DLL name in the side deck will be the USS file name. If it points to a member of a dataset then the DLL name in the side deck is the member name.
If CMake could deal with z/OS datasets we could use -o that points to a dataset member name, but this does not seem to work so we have to produce a USS file as the DLL and then copy the content of the produced side deck to a dataset as well as rename the USS file name in the side deck to a dataset member name that corresponds to that DLL.
Reviewed By: muiez, SeanP, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D118503
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
This is a re-application of the original patch by Eric Fiselier in
fcd549a7d8 which had been reverted due to reasons lost at this point.
I also added the macro to a few more types. Reviving this patch was
prompted by the discussion on https://llvm.org/D133425.
Differential Revision: https://reviews.llvm.org/D133535
Currently if both LIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY (only
applies to static library) and LIBCXX_ENABLE_ABI_LINKER_SCRIPT (only
applies to shared library) are enabled, the former will be silently
ignored. The shared library will use a linker script, while the
static library fails to link libc++abi.a entirely.
This is caused by what appears to be an implementation bug: The
LIBCXX_STATICALLY_LINK_ABI_IN_*_LIBRARY options are declared as
dependent options of LIBCXX_ENABLE_STATIC_ABI_LIBRARY, rather than
simply using it as the default value.
Of course, the combination of
LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY and
LIBCXX_ENABLE_ABI_LINKER_SCRIPT still results in a cmake error,
because these would be conflicting requests for the shared library.
Differential Revision: https://reviews.llvm.org/D134644
This version is build without support for the experimental library but
the code still wants to link this function. Inlining the function solves
the issue.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D132667
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
Warns on potentially unintended use of C++17 Class Template Argument
Deduction. Use of this feature with types that aren't intended to
support it may may future refactorings of those types more difficult -
so this warning fires whenever the feature is used with a type that may
not have intended to be used with CTAD (the warning uses the existence
of at least one explicit deduction guide to indicate that a type
intentionally supports CTAD - absent that, it's assumed to not be
intended to support CTAD & produces a warning).
This is disabled in libcxx because lots of the standard library is
assumed to provide ctad-usable APIs and the false positive suppression
in the diagnostic is based on system header classification which doesn't
apply in the libcxx build itself.
Differential Revision: https://reviews.llvm.org/D131727
I went over the output of the following mess of a command:
`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Reviewed By: #libc, philnik
Spies: philnik, libcxx-commits, mgorny, arichardson
Differential Revision: https://reviews.llvm.org/D130905
Leave the escape hatch in place with a note, but don't include the
debug mode symbols by default since we don't support the debug mode
in the normal library anymore.
This is technically an ABI break for users who were depending on
those debug mode symbols in the dylib, however those users will
already be broken at compile-time because they must have been using
_LIBCPP_DEBUG=2, which is now an error.
Differential Revision: https://reviews.llvm.org/D127360
In particular remove the ability to expel incomplete features from the
library at configure-time, since this can now be done through the
_LIBCPP_ENABLE_EXPERIMENTAL macro.
Also, never provide symbols related to incomplete features inside the
dylib, instead provide them in c++experimental.a (this changes the
symbols list, but not for any configuration that should have shipped).
Differential Revision: https://reviews.llvm.org/D128928
This caused build failures when building Clang and libc++ together on Mac:
fatal error: 'experimental/memory_resource' file not found
See the code review for details. Reverting until the problem and how to
solve it is better understood.
(Updates to some test files were not reverted, since they seemed
unrelated and were later updated by 340b48b267b96.)
> This is the first part of a plan to ship experimental features
> by default while guarding them behind a compiler flag to avoid
> users accidentally depending on them. Subsequent patches will
> also encompass incomplete features (such as <format> and <ranges>)
> in that categorization. Basically, the idea is that we always
> build and ship the c++experimental library, however users can't
> use what's in it unless they pass the `-funstable` flag to Clang.
>
> Note that this patch intentionally does not start guarding
> existing <experimental/FOO> content behind the flag, because
> that would merely break users that might be relying on such
> content being in the headers unconditionally. Instead, we
> should start guarding new TSes behind the flag, and get rid
> of the existing TSes we have by shipping their Standard
> counterpart.
>
> Also, this patch must jump through a few hoops like defining
> _LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers
> that do not implement -funstable yet.
>
> Differential Revision: https://reviews.llvm.org/D128927
This reverts commit bb939931a1.
This is the first part of a plan to ship experimental features
by default while guarding them behind a compiler flag to avoid
users accidentally depending on them. Subsequent patches will
also encompass incomplete features (such as <format> and <ranges>)
in that categorization. Basically, the idea is that we always
build and ship the c++experimental library, however users can't
use what's in it unless they pass the `-funstable` flag to Clang.
Note that this patch intentionally does not start guarding
existing <experimental/FOO> content behind the flag, because
that would merely break users that might be relying on such
content being in the headers unconditionally. Instead, we
should start guarding new TSes behind the flag, and get rid
of the existing TSes we have by shipping their Standard
counterpart.
Also, this patch must jump through a few hoops like defining
_LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers
that do not implement -funstable yet.
Differential Revision: https://reviews.llvm.org/D128927
This commit re-applies 9ee97ce3b8, which was reverted by 61d417ce
because it broke the LLDB data formatter tests. It also re-applies
6148c79a (the manual GN change associated to it).
Differential Revision: https://reviews.llvm.org/D127444
Instead of marking private symbols with internal_linkage (which leads to
one copy per translation unit -- rather wasteful), use an ABI tag that
gets rev'd with each libc++ version. That way, we know that we can't have
name collisions between implementation-detail functions across libc++
versions, so we'll never violate the ODR. However, within a single program,
each symbol still has a proper name with external linkage, which means
that the linker is free to deduplicate symbols even across TUs.
This actually means that we can guarantee that versions of libc++ can
be mixed within the same program without ever having to take a code size
hit, and without having to manually opt-in -- it should just work out of
the box.
Differential Revision: https://reviews.llvm.org/D127444
This patch switches the build compiler for AIX from ibm-clang to clang. ibm-clang++_r has `-pthread` by default, but clang for AIX doesn't, so `-pthread` had to be added to the test config. A bunch of tests now pass, so the `XFAIL` was removed. This patch also switch the build to use the visibility support available in clang-15 to control symbols exported by the shared library (AIX traditionally uses explicit export lists for this purpose).
Reviewed By: #libc, #libc_abi, daltenty, #libunwind, ldionne
Differential Revision: https://reviews.llvm.org/D127470
include the invalid LIBCXX_ABI_NAMESPACE to ease debugging.
Reviewed By: #libc, jloser, ldionne
Differential Revision: https://reviews.llvm.org/D127257
