This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Remove _LIBCPP_ABI_UNSTABLE
ClosedPublic

Authored by ldionne on Feb 7 2022, 11:58 AM.

Details

Reviewers
philnik
Quuxplusone
Group Reviewers
Restricted Project
Commits
rG817d897b57c7: [libc++] Remove _LIBCPP_ABI_UNSTABLE
Summary

Previously, _LIBCPP_ABI_UNSTABLE would be used interchangeably with
_LIBCPP_ABI_VERSION >= 2. This was confusing and creating unnecessary
complexity.

This patch removes _LIBCPP_ABI_UNSTABLE -- instead, the LIBCXX_ABI_UNSTABLE
CMake option will result in the LIBCXX_ABI_VERSION being set to '2', the
current unstable ABI. As a result, in the code, we only have _LIBCPP_ABI_VERSION
to check in order to query the current ABI version.

As a fly-by, this also defines the ABI namespace during CMake configuration
to reduce complexity in config. I believe it was previously done this
way because we used to try to use
config_site as seldom as possible.
Now that we always ship a config_site, it doesn't really matter and
I think being explicit about how the library is configured in the
config_site
is actually a feature.

Diff Detail

Event Timeline

ldionne created this revision.Feb 7 2022, 11:58 AM
ldionne requested review of this revision.Feb 7 2022, 11:58 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 7 2022, 11:58 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
philnik accepted this revision as: philnik.Feb 7 2022, 12:05 PM
Quuxplusone added a subscriber: Quuxplusone.

LGTM mod nits.

libcxx/CMakeLists.txt
188

Here we fail to actually say what the ABI version is set to when LIBCXX_ABI_UNSTABLE is specified. (The answer, after last week's D118989, is "2".)

libcxx/docs/BuildingLibcxx.rst
446
libcxx/test/libcxx/utilities/utility/pairs/pairs.pair/non_trivial_copy_move_ABI.pass.cpp
18

Here and below, I suggest XFAIL: freebsd.

libcxx/utils/gdb/libcxx/printers.py
10

These should work for objects compiled with either the stable ABI or the unstable ABI. (Or both? Is "both" a physical possibility?)

ldionne updated this revision to Diff 406573.Feb 7 2022, 12:33 PM
ldionne marked 4 inline comments as done.

Address comments and hopefully fix CI.

libcxx/utils/gdb/libcxx/printers.py
10

Good suggestion. I think the intent of the comment is to say that the pretty printers are ABI independent. I think it would be physically possible to compile a single object file with two libc++s on different ABI versions, but IDK how the pretty printers would handle it.

ldionne accepted this revision as: Restricted Project.Feb 8 2022, 12:15 PM
This revision is now accepted and ready to land.Feb 8 2022, 12:15 PM
ldionne added a subscriber: thakis.Feb 8 2022, 12:20 PM

I'm also adding a release note, in case some users were setting the macro manually (even though they were not supposed to).

@thakis You might also want to tweak your BUILD.gn

This revision was automatically updated to reflect the committed changes.

Hi,

We're seeing breakage in Fuchsia's Clang canary builders for Linux (aarch64 & X86_64) that seem related to this patch, (though it may be related to D119036 ? I can't tell).

Sorry for the late notification. This was hidden by a breakage in an different LLVM component, so we missed this for a bit.

We're seeing errors of this nature:

In file included from /b/s/w/ir/x/w/llvm-llvm-project/libcxx/test/libcxx/containers/sequences/deque/incomplete.pass.cpp:16:
In file included from /b/s/w/ir/x/w/staging/llvm_build/include/c++/v1/deque:163:
/b/s/w/ir/x/w/staging/llvm_build/include/c++/v1/__config:64:11: error: '_LIBCPP_ABI_INCOMPLETE_TYPES_IN_DEQUE' macro redefined [-Werror,-Wmacro-redefined]
#  define _LIBCPP_ABI_INCOMPLETE_TYPES_IN_DEQUE
          ^
<command line>:6:9: note: previous definition is here
#define _LIBCPP_ABI_INCOMPLETE_TYPES_IN_DEQUE 1

You can find the builders here: https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-arm64/b8822761889490955361/overview
the failing test in Clang :: CodeGen/aarch64-mops.c has already been addressed and is unrelated.

and newer ones here: https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8822749181186387249/overview

lebedev.ri added inline comments.
libcxx/CMakeLists.txt
190–192

This requires build dir purge and cmake rerun,
because LIBCXX_ABI_NAMESPACE would be "" (empty) before,
and you don't force-recover it to "__${LIBCXX_ABI_VERSION}".

Hi,

We're seeing breakage in Fuchsia's Clang canary builders for Linux (aarch64 & X86_64) that seem related to this patch, (though it may be related to D119036 ? I can't tell).

Sorry for the late notification. This was hidden by a breakage in an different LLVM component, so we missed this for a bit.
[...]

Thanks for the heads up. It was indeed caused by D119036, and should be fixed by eceb40183cbb9442c7f42e7a4b8324abb50c32ab.

Can you folks move the Fuchsia bots to our pre-commit CI infrastructure?

Hi
Looks like hip buildbot breaks from this
https://lab.llvm.org/buildbot/#/builders/165/builds/15363

Indeed, you need to nuke your CMakeCache.txt. Generally speaking, a build bot that reuses an existing cache is brittle and you should be re-performing the CMake configure step each time. If you are trying to increase caching, IMO you're better off with something like ccache.

libcxx/CMakeLists.txt
190–192

Technically you only need to clear your CMakeCache.txt.

Hi,

We're seeing breakage in Fuchsia's Clang canary builders for Linux (aarch64 & X86_64) that seem related to this patch, (though it may be related to D119036 ? I can't tell).

Sorry for the late notification. This was hidden by a breakage in an different LLVM component, so we missed this for a bit.
[...]

Thanks for the heads up. It was indeed caused by D119036, and should be fixed by eceb40183cbb9442c7f42e7a4b8324abb50c32ab.

Can you folks move the Fuchsia bots to our pre-commit CI infrastructure?

@ldionne let me loop @phosek in, since he will be better able to answer you about that.

phosek added a comment.Feb 9 2022, 9:41 AM

Hi,

We're seeing breakage in Fuchsia's Clang canary builders for Linux (aarch64 & X86_64) that seem related to this patch, (though it may be related to D119036 ? I can't tell).

Sorry for the late notification. This was hidden by a breakage in an different LLVM component, so we missed this for a bit.
[...]

Thanks for the heads up. It was indeed caused by D119036, and should be fixed by eceb40183cbb9442c7f42e7a4b8324abb50c32ab.

Can you folks move the Fuchsia bots to our pre-commit CI infrastructure?

@ldionne let me loop @phosek in, since he will be better able to answer you about that.

We cannot move existing bots over since we would loose integration into the rest of Fuchsia's CI infrastructure which lets us test every toolchain against the rest of the platform. We have been thinking about setting up additional upstream builders for libc++ though.

We cannot move existing bots over since we would loose integration into the rest of Fuchsia's CI infrastructure which lets us test every toolchain against the rest of the platform. We have been thinking about setting up additional upstream builders for libc++ though.

Right -- I am not requesting that you "move" your bots, simply that you provide one additional bot that we can use in our pre-commit CI. I am very serious about this -- I know everyone is busy but this is simple to set up and will make our lives much easier. These unforeseen breakages are a waste of libc++ developers' time in the long run since they can be avoided with proper pre-commit CI.