[libc++] Remove non-atomic "platform" semaphore implementations.

These can't be made constexpr-constructible (constinit'able),
so they aren't C++20-conforming. Also, the platform versions are
going

[libc++] Remove non-atomic "platform" semaphore implementations.

These can't be made constexpr-constructible (constinit'able),
so they aren't C++20-conforming. Also, the platform versions are
going to be bigger than the atomic/futex version, so we'd have
the awkward situation that `semaphore<42>` could be bigger than
`semaphore<43>`, and that's just silly.

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

show more ...

[libc++] Remove "// -*- C++ -*-" comments from all .cpp files. NFCI.

Even if these comments have a benefit in .h files (for editors that
care about language but can't be configured to treat .h as C+

[libc++] Remove "// -*- C++ -*-" comments from all .cpp files. NFCI.

Even if these comments have a benefit in .h files (for editors that
care about language but can't be configured to treat .h as C++ code),
they certainly have no benefit for files with the .cpp extension.

Discussed in D110794.

show more ...

[libcxx] Simplify rounding of durations in win32 __libcpp_thread_sleep_for

Also fix a comment typo, and remove a superfluous "std::" qualififcation
in __libcpp_semaphore_wait_timed for consistency.

[libcxx] Simplify rounding of durations in win32 __libcpp_thread_sleep_for

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

show more ...

[libcxx] Implement semaphores for windows

Also add WIN32_LEAN_AND_MEAN before including windows.h, for consistency
with other sources.

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

[libc++] Rename include/support to include/__support

We do ship those headers, so the directory name should not be something
that can potentially conflict with user-defined directories.

Differentia

[libc++] Rename include/support to include/__support

We do ship those headers, so the directory name should not be something
that can potentially conflict with user-defined directories.

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

show more ...

[libc++] Avoid using timespec when it might not be available

Summary:
The type timespec is unconditionally used in __threading_support.
Since the C library is only required to provide it in C11, thi

[libc++] Avoid using timespec when it might not be available

Summary:
The type timespec is unconditionally used in __threading_support.
Since the C library is only required to provide it in C11, this might
cause problems for platforms with external thread porting layer (i.e.
when _LIBCPP_HAS_THREAD_API_EXTERNAL is defined) with pre-C11
C libraries.

In our downstream port of libc++ we used to provide a definition of
timespec in __external_threading, but this solution is not ideal
because timespec is not a reserved name.

This patch renames timespec into __libcpp_timespec_t in the
thread-related parts of libc++. For all cases except external
threading this type is an alias for ::timespec (and no functional
changes are intended).

In case of external threading it is expected that the
__external_threading header will either provide a similar typedef (if
timespec is available in the vendor's C library) or provide a
definition of __libcpp_timespec_t compatible with POSIX timespec.

Reviewers: ldionne, mclow.lists, EricWF

Reviewed By: ldionne

Subscribers: dexonsmith, libcxx-commits, christof, carwil

Tags: #libc

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

llvm-svn: 364012

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 ...

[windows] Fix warning about comparing ints of different signs

This fixes a warning like this:

warning: comparison of integers of different signs:
'std::__1::__libcpp_tls_key' (aka 'long') and

[windows] Fix warning about comparing ints of different signs

This fixes a warning like this:

warning: comparison of integers of different signs:
'std::__1::__libcpp_tls_key' (aka 'long') and 'DWORD'
(aka 'unsigned long') [-Wsign-compare]
if (*__key == FLS_OUT_OF_INDEXES)
~~~~~~ ^ ~~~~~~~~~~~~~~~~~~

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

llvm-svn: 337946

show more ...

[libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY

Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually

[libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY

Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.

This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.

Note that this commit had originally been applied in r336369 and then
reverted in r336382 because of unforeseen problems. Both of these problems
have now been fixed.

Reviewers: EricWF, mclow.lists

Subscribers: christof, dexonsmith, erikvanderpoel

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

llvm-svn: 336866

show more ...

Revert "[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY"

This reverts commit r336369. The commit had two problems:
1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE

Revert "[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY"

This reverts commit r336369. The commit had two problems:
1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of
_LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the
dylib and the check-cxx-abilist failing.

2. The LLDB tests started failing because they undefine
`_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and
fix the tests before we can go forward with this change.

llvm-svn: 336382

show more ...

[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY

Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempt

[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITY

Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.

This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.

Reviewers: EricWF

Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists

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

llvm-svn: 336369

show more ...

libcxx: Move Windows threading support into a .cpp file.

This allows us to avoid polluting the namespace of users of <thread>
with the definitions in windows.h.

Differential Revision: https://revie

libcxx: Move Windows threading support into a .cpp file.

This allows us to avoid polluting the namespace of users of <thread>
with the definitions in windows.h.

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

llvm-svn: 323169

show more ...