Commit Graph

10 Commits

Author SHA1 Message Date
Louis Dionne
615e6dd1c5
[🍒][libc++] Fix missing and incorrect push/pop macros (#79204) (#79497)
We recently noticed that the unwrap_iter.h file was pushing macros, but
it was pushing them again instead of popping them at the end of the
file. This led to libc++ basically swallowing any custom definition of
these macros in user code:

    #define min HELLO
    #include <algorithm>
    // min is not HELLO anymore, it's not defined

While investigating this issue, I noticed that our push/pop pragmas were
actually entirely wrong too. Indeed, instead of pushing macros like
`move`, we'd push `move(int, int)` in the pragma, which is not a valid
macro name. As a result, we would not actually push macros like `move`
-- instead we'd simply undefine them. This led to the following code not
working:

    #define move HELLO
    #include <algorithm>
    // move is not HELLO anymore

Fixing the pragma push/pop incantations led to a cascade of issues
because we use identifiers like `move` in a large number of places, and
all of these headers would now need to do the push/pop dance.

This patch fixes all these issues. First, it adds a check that we don't
swallow important names like min, max, move or refresh as explained
above. This is done by augmenting the existing
system_reserved_names.gen.py test to also check that the macros are what
we expect after including each header.

Second, it fixes the push/pop pragmas to work properly and adds missing
pragmas to all the files I could detect a failure in via the newly added
test.

rdar://121365472
(cherry picked from commit 7b4622514d232ce5f7110dd8b20d90e81127c467)
2024-02-01 17:51:34 -08:00
Louis Dionne
77a00c0d54
[libc++] Replace uses of _VSTD:: by std:: (#74331)
As part of the upcoming clang-formatting of libc++, this patch performs
the long desired removal of the _VSTD macro.

See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.
2023-12-05 11:19:15 -05:00
Louis Dionne
fdf91c768e
[libc++][NFC] Introduce named states in std::call_once (#66289)
This idea is extracted from https://reviews.llvm.org/D112319. It makes
the code easier to read but doesn't otherwise change any functionality.
2023-09-15 10:14:13 -04:00
Louis Dionne
c01794e7ae [libc++] Move once_flag outside of <mutex>
This allows including once_flag directly from <__locale> instead of
depending on all of <mutex>, which requires threading. In turn, this
makes it easier to support locales on platforms without threading.

Drive-by change: clang-format once_flag.h and use _LIBCPP_HIDE_FROM_ABI

Differential Revision: https://reviews.llvm.org/D155487
2023-08-31 14:56:42 -04:00
Nikolas Klauser
f1ea0b11ca [libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI
These macros are always defined identically, so we can simplify the code a bit by merging them.

Reviewed By: ldionne, #libc

Spies: libcxx-commits, krytarowski, smeenai

Differential Revision: https://reviews.llvm.org/D152652
2023-06-15 08:56:45 -07:00
Louis Dionne
8643bdd016 [libc++] Make std::allocator_arg and friends conforming in C++17
This patch makes global tag variables like std::allocator_arg
conform to C++17 by defining them as inline constexpr variables.
This is possible without creating an ODR violation now that we don't
define strong definitions of those variables in the shared library
anymore.

Differential Revision: https://reviews.llvm.org/D145589
2023-04-21 17:47:17 -04:00
Louis Dionne
87cec86597 [libc++] Remove symbols for a std::allocator_arg & friends from the dylib
This patch removes the symbols defined in the library for std::allocator_arg,
std::defer_lock, std::try_to_lock, std::adopt_lock, and std::piecewise_construct.
Those were defined in the library because we provided them in C++03 as an
extension, and in C++03 it was impossible to define them as `constexpr`
variables, like in the spec.

This is technically an ABI break since we are removing symbols from the
library. However, in practice, only programs compiled in C++03 mode who
take the address of those objects (or pass them as a reference) will have
an undefined ref to those symbols. In practice, this is expected to be
rare. First, those are C++11 features that we happen to provide in C++03,
and only the C++03 definition can potentially lead to code referencing
the dylib definition. So any code that is using these objects but compiling
in C++11 mode (as they should) is not at risk. Second, all uses of these
types in the library is done by passing those types by value to a function
that can get inlined. Since they are empty types, the compiler won't
generate an undefined reference if passed by value, since there's nothing
to pass anyway.

Long story short, the risk for code actually containing an undefined
reference to one of these types is rather small (but non-zero). I also
couldn't find any app on the App Store that referenced these symbols,
which supports my impression that this won't be an issue in practice.

Differential Revision: https://reviews.llvm.org/D145587
2023-04-19 17:27:14 -04:00
Nikolas Klauser
83ce139721 [libc++] Add hide_from_abi check for classes
We already have a clang-tidy check for making sure that `_LIBCPP_HIDE_FROM_ABI` is on free functions. This patch extends this to class members. The places where we don't check for `_LIBCPP_HIDE_FROM_ABI` are classes for which we have an instantiation in the library.

Reviewed By: ldionne, Mordante, #libc

Spies: jplehr, mikhail.ramalho, sstefan1, libcxx-commits, krytarowski, miyuki, smeenai

Differential Revision: https://reviews.llvm.org/D142332
2023-04-16 15:23:23 +02:00
Mark de Wever
e8cfbfd05a [libc++] Granularize system_error.
Reviewed By: #libc, philnik

Differential Revision: https://reviews.llvm.org/D147853
2023-04-09 17:57:14 +02:00
Nikolas Klauser
e655d8a548 [libc++] Granularize __mutex_base
This also updates the moved code to the current style. (i.e. `_VSTD` -> `std`, `_LIBCPP_INLINE_VISIBILITY` -> `_LIBCPP_HIDE_FROM_ABI`, clang-format).

Reviewed By: Mordante, #libc, EricWF

Spies: arichardson, libcxx-commits, mikhail.ramalho

Differential Revision: https://reviews.llvm.org/D146228
2023-03-22 20:17:26 +01:00