There is a lot more we can do, in particular in <type_traits>, but this
removes some workarounds that were gated on checking a specific compiler
version.
Differential Revision: https://reviews.llvm.org/D108923
We will try to use GetSystemTimePreciseAsFileTime if possible.
Reference: 59195b2d7f/.
Reviewed By: compnerd, #libc, mstorsjo, ldionne
Differential Revision: https://reviews.llvm.org/D104987
Based on https://github.com/NuxiNL/cloudlibc, it appears that the CloudABI
project has been abandoned. This patch removes a bunch of CloudABI specific
logic that had been added to support that platform.
Note that some knobs like LIBCXX_ENABLE_STDIN and LIBCXX_ENABLE_STDOUT
coud be useful in their own right, however those are currently broken.
If we want to re-add such knobs in the future, we can do it like we've
done it for localization & friends so that we can officially support
that configuration.
Differential Revision: https://reviews.llvm.org/D108637
That's not necessary anymore, since we always build the dylib with
C++11 capabilities nowadays.
Differential Revision: https://reviews.llvm.org/D107772
Adds a new CMake option to disable the usage of incomplete headers.
These incomplete headers are not guaranteed to be ABI stable. This
option is intended to be used by vendors so they can avoid their users
from code that's not ready for production usage.
The option is enabled by default.
Differential Revision: https://reviews.llvm.org/D106763
Building the libraries with -fPIC ensures that we can link an executable
against the static libraries with -fPIE. Furthermore, there is apparently
basically no downside to building the libraries with position independent
code, since modern toolchains are sufficiently clever.
This commit enforces that we always build the runtime libraries with -fPIC.
This is another take on D104327, which instead makes the decision of whether
to build with -fPIC or not to the build script that drives the runtimes'
build.
Fixes http://llvm.org/PR43604.
Differential Revision: https://reviews.llvm.org/D104328
While we can debate on the value of passing by const value, there is no
arguing that it's confusing to do so in some circumstances, such as when
marking a pointer parameter as being const (did you mean a pointer-to-const?).
This commit fixes a few issues along those lines.
If building code like this:
unsigned long val = 1000;
snprintf(buf, sizeof(buf), "%+lu", val);
with clang, clang warns
warning: flag '+' results in undefined behavior with 'u' conversion specifier [-Wformat]
Therefore, don't construct such undefined format strings. (There's
no compiler warnings here, as the compiler can't inspect dynamically
assembled format strings.)
This fixes number formatting in mingw-w64 if built with
`__USE_MINGW_ANSI_STDIO` defined (there, the '+' flag causes a
leading plus to be printed when formatting unsigned numbers too,
while the '+' flag doesn't cause any extra leading plus in other
stdio implementations).
Differential Revision: https://reviews.llvm.org/D103444
If the nested create_directory call fails, we'd still want to
re-report the errors with the create_directories function name,
which is what the caller called.
This fixes one aspect from MS STL's tests for std::filesystem.
Differential Revision: https://reviews.llvm.org/D102365
The aim is to define _LIBCPP_ELAST for AIX since strerror/strerror_r
can't handle out-of-range errno values.
Differential Revision: https://reviews.llvm.org/D100986
This allocator is not intended for libc++'s users to use;
it's strictly an implementation detail of `src/locale.cpp`.
So, move it to the `src/include/` directory.
Drive-by const-qualify its comparison operators.
For consistency with `__hidden_allocator` (defined in `src/thread.cpp`),
do *not* remove it from "libcxx/lib/libc++unexp.exp",
"libcxx/utils/symcheck-blacklists/linux_blacklist.txt", etc.
Differential Revision: https://reviews.llvm.org/D101293
This patch gets rid of technical debt around std::pointer_safety which,
I claim, is entirely unnecessary. I don't think anybody has used
std::pointer_safety in actual code because we do not implement the
underlying garbage collection support. In fact, P2186 even proposes
removing these facilities entirely from a future C++ version. As such,
I think it's entirely fine to get rid of complex workarounds whose goals
were to avoid breaking the ABI back in 2017.
I'm putting this up both to get reviews and to discuss this proposal for
a breaking change. I think we should be comfortable with making these
tiny breaks if we are confident they won't hurt anyone, which I'm fairly
confident is the case here.
Differential Revision: https://reviews.llvm.org/D100410
This functionality is tested in std/containers/sequences/vector/iterators.pass.cpp
(and similarly for all containers, but vector is the only one to be tested that
uses debug iterators).
Differential Revision: https://reviews.llvm.org/D100881
These variables were introduced during early work on the runtimes build
but were obsoleted by {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_LIBRARY_DIR.
Differential Revision: https://reviews.llvm.org/D99697
This path would unblock the build of libc++ library on AIX:
1. Add _AIX guard for _LIBCPP_HAS_THREAD_API_PTHREAD
2. Use uselocale to actually take the locale setting
into account.
3. extract_mtime and extract_atime mod needed for AIX. As stat
structure on AIX uses internal structure st_timespec to store
time for binary compatibility reason. So we need to convert it
back to timespec here.
4. Do not build cxa_thread_atexit.cpp for libcxxabi on AIX.
Differential Revision: https://reviews.llvm.org/D97558
CMAKE_STATIC_LIBRARY_PREFIX affects the naming of all static libs (in
MSVC configurations), including c++experimental, which only is produced
as static regardless of LIBCXX_ENABLE_STATIC.
Differential Revision: https://reviews.llvm.org/D99176
This reverts commit febbf68b423b14d55a14980d2ba3ec37ef1e31dc because it
added files that were not under the LLVM license.
See https://reviews.llvm.org/D98207 for details.
The aim is to use the correct vasprintf implementation for z/OS libc++, where a copy of va_list ap is needed. In particular, it avoids the potential that the initial internal call to vsnprintf will modify ap and the subsequent call to vsnprintf will use that modified ap.
Differential Revision: https://reviews.llvm.org/D97473
Both libc++ and libc++abi have options of merging with another archive. In the case of libc++abi, libunwind can be merged into it and in the case of libc++, libc++abi can be merged into it.
This is realized using add_custom_command with POST_BUILD and the usage of the CMake generator expression TARGET_LINKER_FILE in the arguments. For such generator expressions CMake doc states: "This target-level dependency does NOT add a file-level dependency that would cause the custom command to re-run whenever the executable is recompiled" [1]
This patch adds a DEPENDS argument to both add_custom_command invocations so that the archives also have a file-level dependency on the target they are merging with. That way, changes in say, libunwind source code, will be updated in the libc++abi and/or libc++ static libraries as well.
[1] https://cmake.org/cmake/help/v3.20/command/add_custom_command.html
Differential Revision: https://reviews.llvm.org/D98129
Also fix a comment typo, and remove a superfluous "std::" qualififcation
in __libcpp_semaphore_wait_timed for consistency.
This mirrors what was suggested in review of
1773eec6928f4e37b377e23b84d7a2a07d0d1d0d.
Differential Revision: https://reviews.llvm.org/D98015
This is my attempt to merge D98077 (bugfix the format strings for
Windows paths, which use wchar_t not char)
and D96986 (replace C++ variadic templates with C-style varargs so that
`__attribute__((format(printf)))` can be applied, for better safety)
and D98065 (remove an unused function overload).
The one intentional functional change here is in `__create_what`.
It now prints path1 and path2 in square-brackets _and_ double-quotes,
rather than just square-brackets. Prior to this patch, it would
print either path double-quoted if-and-only-if it was the empty
string. Now the double-quotes are always present. I doubt anybody's
code is relying on the current format, right?
Differential Revision: https://reviews.llvm.org/D98097
The aim is to define _LIBCPP_ELAST for z/OS libc++ since strerror/strerror_r can't handle out-of-range errno values.
Differential Revision: https://reviews.llvm.org/D98541
The aim is to add the missing z/OS specific implementations for mbsnrtowcs and wcsnrtombs, as part of libc++.
Differential Revision: https://reviews.llvm.org/D98207
Fix handling of skip_permission_denied on windows; after converting
the return value of GetLastError() to a standard error_code, ec.value()
is in the standard errc range, not a native windows error code. This
was missed in 156180727d6c347eda3ba749730707acb8a48093.
The directory "C:\System Volume Information" does seem to exist and
have these properties on most relevant contempory setups.
Differential Revision: https://reviews.llvm.org/D98166
The aim is to add the missing z/OS specific locale functions for libc++ (newlocale, freelocale and uselocale).
Reviewed By: ldionne, #libc, curdeius
Differential Revision: https://reviews.llvm.org/D98044
Opening a path like \\server (without a trailing share name and
path) produces this error, while opening e.g. \\server\share
(for a nonexistent server/share) produces ERROR_BAD_NETPATH (which
already is mapped).
This happens in some testcases (in fs.op.proximate); as proximate()
calls weakly_canonical() on the inputs, weakly_canonical() checks
whether the path exists or not. When the error code wasn't recognized
(it mapped to errc::invalid_argument), the stat operation wasn't
conclusive and weakly_canonical() errored out. With the proper error
code mapping, this isn't considered an error, just a nonexistent
path, and weakly_canonical() can proceed.
This roughly matches what MS STL does - it doesn't have
ERROR_BAD_PATHNAME in its error code mapping table, but it
checks for this error code specifically in the return of their
correspondence of the stat function.
Differential Revision: https://reviews.llvm.org/D97619
A comment was left for when we would require CMake >= 3, which we do now.
I expect this should be a NFC.
Differential Revision: https://reviews.llvm.org/D97341
We always build the libraries in a Standard mode that supports noexcept,
so there's no need to use the _NOEXCEPT macro.
Differential Revision: https://reviews.llvm.org/D97700
On windows, going ahead and actually trying to create the directory
doesn't return an error code that maps to
std::errc::not_a_directory in this case.
This fixes two cases of
TEST_CHECK(ErrorIs(ec, std::errc::not_a_directory))
in filesystems/fs.op.funcs/fs.op.create_directories/create_directories.pass.cpp
for windows (in testcases added in 59c72a70121567f7aee347e96b4ac8f3cfe9f4b2).
Differential Revision: https://reviews.llvm.org/D97090
This avoids having to query pathconf for a max size for
preallocating a buffer for the return value.
This is an extension to the POSIX getcwd() spec.
Differential Revision: https://reviews.llvm.org/D97460
The use of fchmodat() is beeing guarded but its using declaration is not. Let's use the same guard in both places to avoid compiler errors on platforms where `fchmodat` does not exist.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D96303
This allows building libc++ against winpthreads from mingw-w64 to support
operating systems older than Windows 7. The remaining libc++ code already
supports `WIN32` with `LIBCXX_HAS_PTHREAD_API`.
Note that there is also the older "pthreads-win32". However, that support
library implements `pthread_t` as a struct, which violates the libc++
assumption that `pthread_t` is always a scalar and can be compared,
ordered, and set to zero.
Differential Revision: https://reviews.llvm.org/D96339
We need CLOCK_MONOTONIC equivalent implementation for z/OS within libc++. The default implementation is asserting.
On z/OS the lack of 'clock_gettime()' and 'time_point()' force us to look for alternatives.
The current proposal is to use `gettimeofday()` for CLOCK_MONOTONIC which is also used in CLOCK_REALTIME. This will allow us to skip the assertion with compromised CLOCK_MONOTONIC implementation which will not guarantee to never go back in time because it will use `gettimeofday()` but only when it's set.
Is this a good compromise for platforms which does not support monotonic clock?
Hopefully this will spark the discussion and agreement how to proceed in this situation.
Reviewed By: #libc, ldionne, hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D93542
Building libcxx requires at least C++17 so remove the old work-arounds.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D96200
This does roughly the same as the manual implementation, but checks
a slightly different set of environment variables and has a more
appropriate fallback if no environment variables are available
(/tmp isn't a very useful fallback on windows).
Differential Revision: https://reviews.llvm.org/D91175
This works just fine for windows, as all the functions it calls
are implemented and wrapped for windows.
Differential Revision: https://reviews.llvm.org/D91173
