Thanks for fixing the issue.

Hi Martin,

In D123511#3442895, @ldionne wrote:

Just to confirm my understanding, basically this only triggers when malloc(...) returns nullptr, i.e. when memory is exhausted, right?

In D115906#3308435, @DanielMcIntosh-IBM wrote:

Ping, since as per my previous comment, I'm pretty sure this change will have broken _LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL.

OK, thanks.

Is it expected that ::nullptr_t gets defined in headers other than <cstddef>
(e.g. <cmath>)? And also is it expected that ::nullptr_t gets defined even in C++03 mode?

@ldionne, could you please have a look at this patch?

Renamed steady -> monotonic.

@ldionne, the reason for using __libcpp_timespec_t is the _LIBCPP_HAS_THREAD_API_EXTERNAL configuration. In that case __libcpp_timespec_t is defined in the __external_threading header.

Added missing "_LIBCPP_HIDE_FROM_ABI inline"

OK, in this case, it makes sense to be conservative and disable shrink-wrapping for all functions that use PAC. LGTM.

LGTM, but please update the commit message. The part saying

Added missing #include-s

The CI failure looks unrelated.

Addressed comments.

Added missing constexpr

Guess I failed to nerdsnipe you into adding the constraints to the other six relational operators, huh?

I'll submit a separate patch

Updated the test.

Added std::partial_ordering test

Rebased and addressed Arthur's comment.

The AIX failures seem to be unrelated.

Updated tests

1. Updated std::reverse_iterator tests
2. Added a test for std::move_iterator

1. Addressed reviewers' comments.
2. Added a prerequisite patch.

Rebased

1. Rebased
2. Fixed grammar in ReleaseNotes

Updated Linux ABI list

Rebased

Addressed Louis' comments.

Addressed Arthur's comments.

In D104328#2821342, @mstorsjo wrote:

Furthermore, there is apparently basically no downside to building the libraries with position independent code, since modern toolchains are sufficiently clever.

FWIW it's not necessarily so much about modern toolchains, as it is about modern architectures. AFAIK position independent code is measurably less efficient on e.g. i386, while the overhead on e.g. x86_64 and arm64 is much much smaller (possibly also on 32 bit arm). Therefore I think the other patch (D104327) makes more sense out of these two, as the choice of PIC is more of a choice for how one configures and distributes it, than an intrinsic property of the project itself.

In D102727#2881860, @mvels wrote:

[...] which would make me caution on the side of DTRT instead of does the minimum memory thing. The latter is more a faang thing. I would imagine that a 'stable' user might be surprised with sudden regressions without maybe being too concerned with (temporary) allocations being +/- 20%.

This change is not part of my original D97204 patch (in D97204, I replaced void *AsmLoc with uint64_t AsmLoc), so I think I am eligible to review the change.

This change is pretty obvious. LGTM.

Ping^2

This looks sensible, given that libcxxabi/test/libcxxabi/test/config.py does the same thing:

74         triple = self.get_lit_conf('target_triple', None)
75         if triple is not None:

Hi. It looks like this change broke the following code:

In D97204#2586111, @rsmith wrote:

Thanks for doing this!

The 8-9% memory hit is better than I'd feared, but still seems uncomfortably large. I've left comments on a couple of places where I think we could substantially reduce this.

Thanks, I'll try that.

Fixed python bindings and formatting.

In D97204#2580490, @akyrtzi wrote:

Hi @miyuki,

A major thing worth noting is that 64-bit source locations will
require an ABI breakage in libclang. This patch changes the bit width
in libclang unconditionally, rather than making it configurable.

Is it possible to make the libclang change configurable as well? A libclang ABI breakage would be problematic for us at Apple. We support dynamically loading and using multiple libclang dylibs from different toolchains, which can be different clang versions.

ping

Added static_asserts that check that SourceRange and SourceLocation are trivially destructible.

I will wait until the end of this week to see if anyone has objections.

This revision was landed with ongoing or failed builds.

Refactored SLocEntry in a similar way.

Abandoning in favor of D94237 and D94596.

In D94237#2493844, @dblaikie wrote:

Do you need to run the destructor before placement new in these situations?