On Windows, the underlying file descriptors for stdout/stdin/stderr
can be reconfigured to wide mode. In the default (narrow) mode, the
charset usually isn't utf8 (as libcxx assumes), but normally a locale
specific codepage (where each codepage only can represent a small
subset of unicode characters).
By configuring the stdout file descriptor to wide mode, the user can
output wchar_t based strings without convesion to the narrow charset.
Within libcxx, don't try to use codecvt to convert this to a narrow
character encoding, but output these strings as such with fputwc.
In wide mode, such strings could be output directly with fwrite too,
but if the file descriptor hasn't been configured in wide mode, that
breaks the output (which currently works reasonably). By always
outputting one character at a time with fputwc, it works regardless
of mode of the stdout file descriptor.
For the narrow output stream, std::cout, outputting (via fwrite)
does fail when the file descriptor is set to wide mode. This matches
how it behaves with both MS STL and GNU libstdc++ too, so this is
probably acceptable.
This fixes https://github.com/llvm/llvm-project/issues/46646, and
the downstream bugs https://github.com/mstorsjo/llvm-mingw/issues/145
and https://github.com/mstorsjo/llvm-mingw/issues/222.
Differential Revision: https://reviews.llvm.org/D146398
In addition to reducing the amount of boilerplate we need to generate
whenever a new header is added, this also improves the existing tests
by running them in separate Lit tests (so they can be parallelized).
This also creates separate translation units for most header tests,
which is what we really should have done from the start since it
isolates each header we're testing.
Differential Revision: https://reviews.llvm.org/D151654
This allows removing a bunch of boilerplate from the test suite and
reducing the amount of manual stuff contributors have to do when they
add a new public header.
Differential Revision: https://reviews.llvm.org/D151830
Otherwise, the various lists of headers have different content based
on whether they are run on Windows or other platforms, which makes it
really difficult to write .gen.py tests correctly.
Differential Revision: https://reviews.llvm.org/D151913
This replaces some uses of internal libc++ macros with the equivalent
macro from "test_macros.h".
Differential Revision: https://reviews.llvm.org/D151825
This removes the need for contributors to do some manual steps
when adding a new public header.
Differential Revision: https://reviews.llvm.org/D151831
This simplifies the code inside copy/move and makes it easier to apply the optimization to other algorithms.
Reviewed By: ldionne, Mordante, #libc
Spies: arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D151265
The CI can no longer run with clang-tidy 16 increment it to version 17.
Whether permanently moving to the latest development version is being
discussed on Discourse.
Depends on D149455
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D151628
Module require Clang 17, since Clang 16 requires the magic # __FILE__
line. Therefore, if available, use clang-tidy 17 too. This change should
be reverted after LLVM 17 is released.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D149455
The diagnostic is issued by clang-tidy 17.
This just suppressed the diagnostic. The move operations are non-standard extensions and the class itself is deprecated.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D151223
With D148542, we ran into the following libc++ build error when using musl libc.
```
.../musl/include/bits/alltypes.h:354:16:
error: definition of type '__mbstate_t' conflicts with typedef of the same name
typedef struct __mbstate_t { unsigned __opaque1, __opaque2; } mbstate_t;
^
.../sysroot/usr/include/bits/types/__mbstate_t.h:21:3: note: '__mbstate_t' declared here
} __mbstate_t;
^
1 error generated.
```
This is because the mbstate_t definition in musl libc conflicts with the one
from "bits/types/mbstate_t.h", and this patch attempts to fix this build issue
when musl libc is used.
Reviewed By: iana
Differential Revision: https://reviews.llvm.org/D151740
This is an attempt to reduce the time taken by the Bootstrapping
build job and the Clang CI job that builds the compiler from scratch.
Differential Revision: https://reviews.llvm.org/D150908
Windows' libc, like some other libc implementations do not work as
specified for %Y and %y. This uses the fixes used for other libc
implementations.
The work was part of D150593.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D151612
These have been deprecated since their initial version in libc++. It
seems they were never properly marked as deprecated.
Discovered while working on D151223.
Reviewed By: #libc, ldionne, philnik
Differential Revision: https://reviews.llvm.org/D151474
This reduces the amount of boilerplate that we need to generate
for each commit. It also resolves a problem where the modular CI
would run extremely slow on this test because we'd define a macro
before including the standard library, defeating the module cache.
Differential Revision: https://reviews.llvm.org/D151156
Implements parts of P1614R2
Implemented `operator<=>` for `multiset` and `set`
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D148416
Use ASSERT_WITH_OPERATOR_NEW_FALLBACKS where relevant to waive
the known cases where operator new isn't overridden as expected,
in MinGW DLL configurations.
Clarify the reason for why the fallback in
new.delete.array/new.size_align_nothrow.replace.indirect doesn't
work as expected, which can be considered a vcruntime bug.
Differential Revision: https://reviews.llvm.org/D151304
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
A recurring problem recently has been that libc++ has several generated
tests which all need to be re-generated before committing a change. This
creates noise during code reviews and friction for contributors.
Furthermore, the way we generated most of these tests resulted in
extremely bad compilation times when using modules, because we defined
a macro before compiling each file.
This commit introduces a new kind of test called a '.gen' test. These
tests are normal shell tests, however the Lit test format will run the
test to discover the actual Lit tests it should run. This basically
allows generating a Lit test suite on the fly using arbitrary code,
which can be used in the future to generate tests like our __verbose_abort
tests and several others.
Differential Revision: https://reviews.llvm.org/D151258
@Mordante noticed that this was missing while making `<format>` non-experimental.
Reviewed By: ldionne, Mordante, #libc
Spies: libcxx-commits, Mordante
Differential Revision: https://reviews.llvm.org/D151240
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: #libc, kwk, Mordante
Differential Revision: https://reviews.llvm.org/D150763
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 revision is a part of a series of patches extending AddressSanitizer C++ container overflow detection capabilities by adding annotations, similar to those existing in std::vector, to std::string and `std::deque` collections. These changes allow ASan to detect cases when the instrumented program accesses memory which is internally allocated by the collection but is still not in-use (accesses before or after the stored elements for `std::deque`, or between the size and capacity bounds for `std::string`).
The motivation for the research and those changes was a bug, found by Trail of Bits, in a real code where an out-of-bounds read could happen as two strings were compared via a std::equals function that took `iter1_begin`, `iter1_end`, `iter2_begin` iterators (with a custom comparison function). When object `iter1` was longer than `iter2`, read out-of-bounds on `iter2` could happen. Container sanitization would detect it.
This revision introduces annotations for `std::deque`. Each chunk of the container can now be annotated using the `__sanitizer_annotate_double_ended_contiguous_container` function, which was added in the rG1c5ad6d2c01294a0decde43a88e9c27d7437d157. Any attempt to access poisoned memory will trigger an ASan error. Although false negatives are rare, they are possible due to limitations in the ASan API, where a few (usually up to 7) bytes before the container may remain unpoisoned. There are no false positives in the same way as with `std::vector` annotations.
This patch only supports objects (deques) that use the standard allocator. However, it can be easily extended to support all allocators, as suggested in the D146815 revision.
Furthermore, the patch includes the addition of the `is_double_ended_contiguous_container_asan_correct` function to libcxx/test/support/asan_testing.h. This function can be used to verify whether a `std::deque` object has been correctly annotated.
Finally, the patch extends the unit tests to verify ASan annotations (added LIBCPP_ASSERTs).
If a program is compiled without ASan, all helper functions will be no-ops. In binaries with ASan, there is a negligible performance impact since the code from the change is only executed when the deque container changes in size and it’s proportional to the change. It is important to note that regardless of whether or not these changes are in use, every access to the container's memory is instrumented.
Reviewed By: #libc, philnik
Spies: vitalybuka, hans, mikhail.ramalho, Enna1, #sanitizers, philnik, libcxx-commits
Differential Revision: https://reviews.llvm.org/D132092
