[libc++][test] Fix more MSVC and Clang warnings (#74965)

Found while running libc++'s tests with MSVC's STL.

*
`libcxx/test/std/algorithms/alg.sorting/alg.heap.operations/sort.heap/ranges_sort_h

[libc++][test] Fix more MSVC and Clang warnings (#74965)

Found while running libc++'s tests with MSVC's STL.

*
`libcxx/test/std/algorithms/alg.sorting/alg.heap.operations/sort.heap/ranges_sort_heap.pass.cpp`
+ Fix Clang `-Wunused-variable`, because `LIBCPP_ASSERT` expands to
nothing for MSVC's STL.
+ This is the same "always void-cast" change that #73437 applied to the
neighboring `complexity.pass.cpp`. I missed that
`ranges_sort_heap.pass.cpp` was also affected because we had disabled
this test.
*
`libcxx/test/std/input.output/file.streams/fstreams/ifstream.members/buffered_reads.pass.cpp`
*
`libcxx/test/std/input.output/file.streams/fstreams/ofstream.members/buffered_writes.pass.cpp`
+ Fix MSVC "warning C4244: '`=`': conversion from '`__int64`' to
'`_Ty`', possible loss of data".
+ This is a valid warning, possibly the best one that MSVC found in this
entire saga. We're accumulating a `std::vector<std::streamsize>` and
storing the result in `std::streamsize total_size` but we actually have
to start with `std::streamsize{0}` or we'll truncate.
*
`libcxx/test/std/input.output/filesystems/fs.enum/enum.path.format.pass.cpp`
+ Fix Clang `-Wunused-local-typedef` because the following usage is
libc++-only.
+ I'm just expanding it at the point of use, and using the dedicated
`LIBCPP_STATIC_ASSERT` to keep the line length down.
*
`libcxx/test/std/input.output/syncstream/syncbuf/syncstream.syncbuf.assign/swap.pass.cpp`
+ Fix MSVC "warning C4242: 'argument': conversion from '`int`' to
'`const _Elem`', possible loss of data".
+ This is a valid warning (possibly the second-best) as `sputc()`
returns `int_type`. If `sputc()` returns something unexpected, we want
to know, so we should separately say `expected.push_back(CharT('B'))`.
*
`libcxx/test/std/language.support/support.dynamic/new.delete/new.delete.single/new.size_align_nothrow.pass.cpp`
*
`libcxx/test/std/language.support/support.dynamic/new.delete/new.delete.single/new.size_nothrow.pass.cpp`
+ Fix MSVC "warning C6001: Using uninitialized memory '`x`'."
+ [N4964](https://wg21.link/N4964) \[new.delete.single\]/12:
> *Effects:* The deallocation functions
(\[basic.stc.dynamic.deallocation\]) called by a *delete-expression*
(\[expr.delete\]) to render the value of `ptr` invalid.
+ \[basic.stc.general\]/4:
> When the end of the duration of a region of storage is reached, the
values of all pointers representing the address of any part of that
region of storage become invalid pointer values (\[basic.compound\]).
Indirection through an invalid pointer value and passing an invalid
pointer value to a deallocation function have undefined behavior. Any
other use of an invalid pointer value has implementation-defined
behavior.
+ In certain configurations, after `delete x;` MSVC will consider `x` to
be radioactive (and in other configurations, it'll physically null out
`x` as a safety measure). We can copy it into `old_x` before deletion,
which the implementation finds acceptable.
*
`libcxx/test/std/ranges/range.adaptors/range.elements/general.pass.cpp`
*
`libcxx/test/std/ranges/range.adaptors/range.elements/iterator/deref.pass.cpp`
+ Fix MSVC "warning C4242: 'initializing': conversion from '`_Ty`' to
'`_Ty`', possible loss of data".
+ This was being emitted in `pair` and `tuple`'s perfect forwarding
constructors. Passing `short{1}` allows MSVC to see that no truncation
is happening.
*
`libcxx/test/std/ranges/range.adaptors/range.elements/iterator/member_types.compile.pass.cpp`
+ Fix MSVC "warning C4242: 'initializing': conversion from '`_Ty`' to
'`_Ty2`', possible loss of data".
+ Similarly, this was being emitted in `pair`'s perfect forwarding
constructor. After passing `short{1}`, I reduced repetition by relying
on CTAD. (I can undo that cleanup if it's stylistically undesirable.)
*
`libcxx/test/std/utilities/function.objects/refwrap/refwrap.const/type_conv_ctor.pass.cpp`
+ Fix MSVC "warning C4930: '`std::reference_wrapper<int> purr(void)`':
prototyped function not called (was a variable definition intended?)".
+ There's no reason for `purr()` to be locally declared (aside from
isolating it to a narrow scope, which has minimal benefits); it can be
declared like `meow()` above. :smile_cat:
*
`libcxx/test/std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.create/make_shared_for_overwrite.pass.cpp`
*
`libcxx/test/std/utilities/smartptr/unique.ptr/unique.ptr.create/make_unique_for_overwrite.default_init.pass.cpp`
+ Fix MSVC static analysis warnings when replacing `operator new`:
```
warning C28196: The requirement that '(_Param_(1)>0)?(return!=0):(1)' is
not satisfied. (The expression does not evaluate to true.)
warning C6387: 'return' could be '0': this does not adhere to the
specification for the function 'new'.
warning C6011: Dereferencing NULL pointer 'reinterpret_cast<char
*>ptr+i'.
```
+ All we need is a null check, which appears in other `operator new`
replacements:
https://github.com/llvm/llvm-project/blob/b85f1f9b182234ba366d78ae2174a149e44d08c1/libcxx/test/std/language.support/support.dynamic/new.delete/new.delete.single/new.size.replace.pass.cpp#L27-L28

show more ...

[runtimes] Rename various libcpp-has-no-XYZ Lit features to just no-XYZ

Since those features are general properties of the environment, it makes
sense to use them from libc++abi too, and so the name

[runtimes] Rename various libcpp-has-no-XYZ Lit features to just no-XYZ

Since those features are general properties of the environment, it makes
sense to use them from libc++abi too, and so the name libcpp-has-no-xxx
doesn't make sense.

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

show more ...

[libcxx] [test] Remove UNSUPPORTED markings for mingw issues that no longer are present in CI

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

[libc++] [test] ASSERT_WITH_LIBRARY_INTERNAL_ALLOCATIONS is not supported on AIX.

I believe all four of these failures are directly due to the pattern where
allocations in the dylib are unobserved b

[libc++] [test] ASSERT_WITH_LIBRARY_INTERNAL_ALLOCATIONS is not supported on AIX.

I believe all four of these failures are directly due to the pattern where
allocations in the dylib are unobserved by the client program. If AIX32 and AIX64
don't support that, we should just disable the ASSERT_WITH_LIBRARY_INTERNAL_ALLOCATIONS
macro on AIX, and then we don't need to XFAIL these tests.

This also means I won't need to XFAIL a dozen other tests in D89057,
which rely heavily on ASSERT_WITH_LIBRARY_INTERNAL_ALLOCATIONS and
also currently fail on AIX.
See https://buildkite.com/llvm-project/libcxx-ci/builds/7669

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

show more ...

[libc++][NFC] Fix placement of some XFAILs

[libc++] [ranges] Introduce _LIBCPP_AUTO_CAST(x) for auto(x).

Clang is gaining `auto(x)` support in D113393; sadly there
seems to be no feature-test macro for it. Zhihao is opening
a core issue for

[libc++] [ranges] Introduce _LIBCPP_AUTO_CAST(x) for auto(x).

Clang is gaining `auto(x)` support in D113393; sadly there
seems to be no feature-test macro for it. Zhihao is opening
a core issue for that macro.

Use `_LIBCPP_AUTO_CAST` where C++20 specifies we should use `auto(x)`;
stop using `__decay_copy(x)` in those places.
In fact, remove `__decay_copy` entirely. As of C++20, it's purely
a paper specification tool signifying "Return just `x`, but it was
perfect-forwarded, so we understand you're going to have to call
its move-constructor sometimes." I believe there's no reason we'd
ever need to do its operation explicitly in code.

This heisenbugs away a test failure on MinGW; see D112214.

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

show more ...

[libc++][CI] Add AIX pipeline config

This changes adds the pipeline config for both 32-bit and 64-bit AIX targets. As well, we add a lit feature `LIBCXX-AIX-FIXME` which is used to mark the failing

[libc++][CI] Add AIX pipeline config

This changes adds the pipeline config for both 32-bit and 64-bit AIX targets. As well, we add a lit feature `LIBCXX-AIX-FIXME` which is used to mark the failing tests which remain to be investigated on AIX, so that the CI produces a clean build.

Reviewed By: #libc, ldionne

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

show more ...

[libcxx] [test] Add a specific XFAIL for a MinGW env failure that is fixed in Clang 14

This issue only occurs when linked statically in MinGW configurations,
and has been fixed for Clang 14 by https

[libcxx] [test] Add a specific XFAIL for a MinGW env failure that is fixed in Clang 14

This issue only occurs when linked statically in MinGW configurations,
and has been fixed for Clang 14 by https://reviews.llvm.org/D109651.

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

show more ...

[libcxx] [test] Generalize defines for skipping allocation checks

This allows waiving the right amount of asserts on Windows and zOS.
This should supersede D107124 and D105910.

Differential Revisio

[libcxx] [test] Generalize defines for skipping allocation checks

This allows waiving the right amount of asserts on Windows and zOS.
This should supersede D107124 and D105910.

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

show more ...

[libcxx] [test] Skip alloc counter checks for operations within the libc++ DLL

If libc++ is built as a DLL, calls to operator new within the DLL aren't
overridden if a user provides their own operat

[libcxx] [test] Skip alloc counter checks for operations within the libc++ DLL

If libc++ is built as a DLL, calls to operator new within the DLL aren't
overridden if a user provides their own operator in calling code.
Therefore, the alloc counter doesn't pick up on allocations done within
std::string, so skip that check if running on windows. (Technically,
we could keep the checks if running on windows when not built as a DLL,
but trying to keep the conditionals simple.)

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

show more ...

[libc++] [test] Detect an improperly noexcept'ed __decay_copy.

`__decay_copy` is used by `std::thread`'s constructor to copy its arguments
into the new thread. If `__decay_copy` claims to be noexcep

[libc++] [test] Detect an improperly noexcept'ed __decay_copy.

`__decay_copy` is used by `std::thread`'s constructor to copy its arguments
into the new thread. If `__decay_copy` claims to be noexcept, but then
copying the argument does actually throw, we'd call std::terminate instead
of passing this test. (And I've verified that adding an unconditional `noexcept`
to `__decay_copy` does indeed fail this test.)

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

show more ...

[libcxx] [test] Add XFAIL LIBCXX-WINDOWS-FIXME in 124 tests that fail in the future CI configuration

This makes no attempt yet to look into the why/what for each of them,
but makes the CI configurat

[libcxx] [test] Add XFAIL LIBCXX-WINDOWS-FIXME in 124 tests that fail in the future CI configuration

This makes no attempt yet to look into the why/what for each of them,
but makes the CI configuration useful for tracking further regressions.
After looking into each case, they can either be fixed, or converted
into UNSUPPORTED: windows or XFAIL: windows, once the cause is known
and explained.

A number of the filesystem cases can be fixed by patches that are
currently in review.

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

show more ...

[libc++][test] Remove non-portable assumption that thread's constructor allocates with ::new

Drive-by:
* Fix potential race between check and update of `throw_one` in `operator new`
* Fix latent bug

[libc++][test] Remove non-portable assumption that thread's constructor allocates with ::new

Drive-by:
* Fix potential race between check and update of `throw_one` in `operator new`
* Fix latent bug in `operator delete`, which shouldn't decrement `outstanding_new` when passed a null pointer
* Specifically catch the expected `bad_alloc` in `main` instead of `...`

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

llvm-svn: 359827

show more ...

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

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

show more ...

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351648

show more ...

Repair thread-unsafe modifications of n_alive in F.pass.cpp

In this example, the ctor of G runs in the main thread in the expression G(), and also in the copy ctor of G() in the DECAY_COPY inside st

Repair thread-unsafe modifications of n_alive in F.pass.cpp

In this example, the ctor of G runs in the main thread in the expression G(), and also in the copy ctor of G() in the DECAY_COPY inside std::thread. The main thread destroys the G() instance at the semicolon, and the started thread destroys the G() after it returns. Thus there is a race between the threads on the n_alive variable.

The fix is to join with the background thread before attempting to destroy the G in the main thread.

llvm-svn: 344820

show more ...

[libcxx] [test] Fix comment typos, strip trailing whitespace.

No functional change, no code review.

llvm-svn: 292434

Fix yet another dynamic exception spec

llvm-svn: 289357

[libcxx] Recover no-exceptions XFAILs - I

First batch of changes to get some of these XFAILs working in the
no-exceptions libc++ variant.

Changed some XFAILs to UNSUPPORTED where the test is all ab

[libcxx] Recover no-exceptions XFAILs - I

First batch of changes to get some of these XFAILs working in the
no-exceptions libc++ variant.

Changed some XFAILs to UNSUPPORTED where the test is all about exception
handling. In other cases, used the test macros TEST_THROW and
TEST_HAS_NO_EXCEPTIONS to conditionally exclude those parts of the test
that concerns exception handling behaviour.

Reviewers: EricWF, mclow.lists

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

llvm-svn: 283441

show more ...

Placate MSVC's unchecked malloc warning in thread tests.

llvm-svn: 273385

[libcxx] Fix PR15638 - Only allocate in parent when starting a thread to prevent calling terminate.

Summary:
Hi,

When creating a new thread libc++ performs at least 2 allocations. The first allocat

[libcxx] Fix PR15638 - Only allocate in parent when starting a thread to prevent calling terminate.

Summary:
Hi,

When creating a new thread libc++ performs at least 2 allocations. The first allocates a tuple of args and the functor that will be passed to the new thread. The second allocation is for the thread local storage needed internally by libc++. Currently the second allocation happens in the child thread, meaning that if it throws the program will terminate with an uncaught bad alloc.

The solution to this is to allocate ALL memory in the parent thread and then pass it to the child.

See https://llvm.org/bugs/show_bug.cgi?id=15638

Reviewers: mclow.lists, danalbert, jroelofs, EricWF

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D13748

llvm-svn: 266851

show more ...

Make it possible to build a no-exceptions variant of libcxx.

Fixes a small omission in libcxx that prevents libcxx being built when
-DLIBCXX_ENABLE_EXCEPTIONS=0 is specified.

This patch adds XFAILS

Make it possible to build a no-exceptions variant of libcxx.

Fixes a small omission in libcxx that prevents libcxx being built when
-DLIBCXX_ENABLE_EXCEPTIONS=0 is specified.

This patch adds XFAILS to all those tests that are currently failing
on the new -fno-exceptions library variant. Follow-up patches will
update the tests (progressively) to cope with the new library variant.

Change-Id: I4b801bd8d8e4fe7193df9e55f39f1f393a8ba81a
llvm-svn: 252598

show more ...

[libcxx] Add Atomic test helper and fix TSAN failures.

Summary:
This patch attempts to fix the last 3 TSAN failures on the libc++ bot (http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux

[libcxx] Add Atomic test helper and fix TSAN failures.

Summary:
This patch attempts to fix the last 3 TSAN failures on the libc++ bot (http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-tsan/builds/143). This patch also adds a `Atomic` test type that can be used where `<atomic>` cannot.

`wait.exception.pass.cpp` and `wait_for.exception.pass.cpp` were failing because the test replaced `std::terminate` with `std::exit`. `std::exit` would asynchronously run the TLS and static destructors and this would cause a race condition. See PR22606 and D8802 for more details.

This is fixed by using `_Exit` to prevent cleanup.

`notify_all_at_thread_exit.pass.cpp` exercises the same race condition but for different reasons. I fixed this test by manually joining the thread before beginning program termination.

Reviewers: EricWF, mclow.lists

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D11046

llvm-svn: 245389

show more ...

Use generic feature name for sanitizers that replace new and delete

llvm-svn: 231841

Move test into test/std subdirectory.

llvm-svn: 224658