[libc++] Improve binary size when using __transaction

[philnik]

Summary

__exception_guard is a no-op in -fno-exceptions mode to produce better code-gen. This means that we don't provide the strong exception guarantees. However, Clang doesn't generate cleanup code with exceptions disabled, so even if we wanted to provide the strong exception guarantees we couldn't. This is also only relevant for constructs with a stack of -fexceptions > -fno-exceptions > -fexceptions code, since the exception can't be caught where exceptions are disabled. While -fexceptions > -fno-exceptions is quite common (e.g. libc++.dylib > -fno-exceptions), having another layer with exceptions enabled seems a lot less common, especially one that tries to catch an exception through -fno-exceptions code.

Fixes https://github.com/llvm/llvm-project/issues/56783

[philnik]

• Fix CI

[philnik]

@hans @alexfh @joanahalili Could you check whether this patch fixes the problems encountered in D128146 (i.e. applying this patch shouldn't increase the binary size much)? Compiling

#include <__utility/transaction.h>

void do_something();
void do_something_else();

void func() {
  std::__transaction __guard([] { do_something(); });
  do_something_else();
  __guard.__complete();
}

with clang++ -std=c++2b -fno-exceptions -O3 ./transaction.cpp -c -g shows a decrease of about 400bytes in binary size with this patch.

[huixie90]

libcxx/include/__utility/transaction.h

90–104

having this __transaction class as a noop class in _LIBCPP_NO_EXCEPTIONS mode might cause confusions, because the class name does not indicate anything to do with exceptions (and could be misused as a general purpose scope_guard).

what about having a function __make_exception_guard, which returns the __transaction class in the exception mode, and returns a __noop_transaction class in the noexception mode?

[Mordante]

I'm not fond of this approach, due to the different behaviour whether or not exceptions are enabled.

libcxx/include/__memory/uninitialized_algorithms.h

550–551

Can you please stop using auto everywhere? This has been requested several time by several reviewers. It really makes it unneeded hard to review code. The LLVM developer policy explains why this style isn't wanted
https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable.

(In library code there might be reasons to use auto a bit more often, but this isn't one of these places.)

libcxx/include/__utility/transaction.h

90–104

+1 for the confusion. What makes it more confusing is the usage of _NOEXCEPT in this class. Isn't that useless when exceptions are disabled? Please also some comment why this class it to be used as a no-op.

I'm not even sure whether we really want this class. I expect a transaction that is not committed when it goes out of scope to do a rollback.

void __foo() {
  __transaction __t;
  ... // do stuff
  if(!__happy())
    return;
  __t.__complete();
}

In that way this class behaves different depending on whether or not exceptions are enabled.

Based on the failure in the 'No exception' CI the behaviour above was intended to be working.

[hans]

In D133661#3782732, @philnik wrote:

@hans Could you check whether this patch fixes the problems encountered in D128146 (i.e. applying this patch shouldn't increase the binary size much)?

Apologies for the delayed reply.

Since D128146 we've switched to compressed debug info sections for that binary, so the numbers are slightly different, but with the current patch I measure an increase of 2.45 MB (0.16%).

[ldionne]

In D133661#3791177, @hans wrote:

Since D128146 we've switched to compressed debug info sections for that binary, so the numbers are slightly different, but with the current patch I measure an increase of 2.45 MB (0.16%).

Thanks for the numbers! I think this might be the best we can do from the library side, apart from adding some additional _LIBCPP_NODEBUG attributes (but that also kind of breaks the debugging experience). This must be caused by additional instantiations of the class template.

libcxx/include/__memory/uninitialized_algorithms.h

550–551

I fully agree that we shouldn't blindly use auto, I think it generally obscures the code. IMO these "almost always use auto" advice should never have been given, they were just too easy to mis-interpret and exaggerate on.

That being said, the alternative here is:

std::__transaction<_AllocatorDestroyRangeReverse<_Alloc, _Iter2> > __guard(_AllocatorDestroyRangeReverse<_Alloc, _Iter2>(__alloc, __destruct_first, __first2));

IMO, since we have a std::__make_transaction function, we don't gain much from repeating the type. This is just my .02, I don't really care about this specific instance. I think this one is reasonable, but I agree with @Mordante in the general case about not abusing auto (I personally don't remember seeing @philnik abuse it, though).

libcxx/include/__utility/transaction.h

90–104

I fully agree with the other reviewers, I think it would be wrong to make __transaction a no-op based on whether exceptions are enabled. However, I think it's only an issue because of the semantics associated to the name __transaction, which does not imply something related to exceptions.

I'd suggest:

template <class _Rollback>
struct __noop_transaction {
  __noop_transaction() = delete;
  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG __noop_transaction(_Rollback) {}
  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG __noop_transaction(__transaction&&)
      _NOEXCEPT_(is_nothrow_move_constructible<_Rollback>::value) {}
  __noop_transaction(const __transaction&) = delete;
  __noop_transaction& operator=(const __transaction&) = delete;
  __noop_transaction& operator=(__transaction&&) = delete;

  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG void __complete() _NOEXCEPT {}
  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG ~ __noop_transaction() {}
};


#ifndef _LIBCPP_NO_EXCEPTIONS
template <class _Rollback>
using __exception_guard = __transaction<_Rollback>;
#else
template <class _Rollback>
using __exception_guard = __noop_transaction<_Rollback>;
#endif

template <class _Rollback>
_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR __exception_guard<_Rollback> __make_exception_guard(_Rollback __rollback) {
  return __exception_guard <_Rollback>(std::move(__rollback));
}

Also, you should use __exception_guard instead of __transaction in most existing places where __transaction is used right now.

105

Let's also add some really simple tests for this new __exception_guard class.

111

Not attached: can you please link to https://github.com/llvm/llvm-project/issues/56783 somewhere?

[philnik]

• Address comments

__transaction is currently used exclusively for handling exception guarantees, so I decided to rename the class instead of introducing multiple classes. We can still re-add a __transaction class later if we have use cases for it.

[philnik]

libcxx/include/__utility/transaction.h

90–104

_NOEXCEPT makes a difference, even when exceptions are disabled. noexcept(expr) still isn't always true.

[ldionne]

libcxx/include/__utility/exception_guard.h

97–98

Just for consistency with the other branch of the #if.

[Mordante]

libcxx/include/__memory/uninitialized_algorithms.h

550–551

I've seen several places where auto was used which resulted in me to spending extra time to figure out the exact type used. I've seen @EricWF asking about less auto in the past too. (I don't have concrete examples, and I don't really want to spend time looking at when I asked it.)

Since __make_transaction is not a standard function I need to check whether it really creates a __transation. Using __transaction instead of auto would have saved me that verification.

Another issue I have with auto that it's not always clear what the intended type is. Especially when relying on C++ rules; where I'm not sure whether the writer had the same view of these rules as I have.

[philnik]

• Generate files

[philnik]

• Rebased
• Generate files

[philnik]

• Fix CI

[philnik]

• Try to fix CI

[Mordante]

I'm not fond of the current state; it still has most of the semantics of the transaction instead of being a exception guard. I think with my suggestion we turn the class in a real exception guard and we never have the risk of "forgetting" to complete.

libcxx/include/__memory/uninitialized_algorithms.h

550–552

This really makes it a lot easier to review and maintain.

libcxx/include/__utility/exception_guard.h

78

When this class is intended to be an exception guard it doesn't need this function nor the __completed_ member. Instead we can do something along the lines of:

#ifndef _LIBCPP_NO_EXCEPTIONS
#if _LIBCPP_STD_VER > 14
  _LIBCPP_HIDE_FROM_ABI bool __need_rollback() { return uncaught_exceptions(); } 
#else
  _LIBCPP_HIDE_FROM_ABI bool __need_rollback() { return uncaught_exception(); } 
#endif


 _LIBCPP_CONSTEXPR_SINCE_CXX20 ~__exception_guard() {
    if(__need_rollback())
      __rollback_();
  }
#endif

With some extra boilerplate to add _LIBCPP_CONSTEXPR_SINCE_CXX20.

Then we can even use most of this class when _LIBCPP_NO_EXCEPTIONS is defined. Then it just does an extra store of the never used __rollback_ member.

[philnik]

libcxx/include/__memory/uninitialized_algorithms.h

550–552

This still doesn't work, since it uses CTAD.

libcxx/include/__utility/exception_guard.h

78

This would break when running in a destructor though, right? Then uncaught_exception() might return true even if we don't actually want to roll back a transaction. That's the whole reason uncaught_exceptions() was added.

[ldionne]

libcxx/include/__memory/uninitialized_algorithms.h

550–552

Shouldn't this work since we have _LIBCPP_CTAD_SUPPORTED_FOR_TYPE?

libcxx/include/__utility/exception_guard.h

78

IMO we should strive to keep the scope that the __exception_guard is guarding explicit. If you use uncaught_exceptions (or other) to detect whether an exception was thrown, then you'd have to use the class as

{ // begin new scope
  __exception_guard guard = ...;
  // actions...
} // end scope explicitly here

This may not always be convenient. Instead, being able to explicitly say "okay, here the thing I was guarding for exceptions is done" makes the code clearer.

libcxx/test/libcxx/utilities/exception_guard.pass.cpp

26

Might want to rename t to g in the tests here.

[philnik]

Address comments

libcxx/include/__memory/uninitialized_algorithms.h

550–552

The problem is that this has to work pre-C++17, not that there aren't deduction guides.

[ldionne]

libcxx/include/__utility/exception_guard.h

78

I just had a discussion with Mark where he explained why he wasn't a big fan of the current behavior, where exception_guard will behave differently whether exceptions are enabled or not. I think we should change the no-exceptions version to

template <class _Rollback>
struct __exception_guard {
  __exception_guard() = delete;
  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG __exception_guard(_Rollback) {}
  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG __exception_guard(__exception_guard&&)
      _NOEXCEPT_(is_nothrow_move_constructible<_Rollback>::value) {}
  __exception_guard(__exception_guard const&) = delete;
  __exception_guard& operator=(__exception_guard const&) = delete;
  __exception_guard& operator=(__exception_guard&&) = delete;

  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG void __complete() _NOEXCEPT { __completed_ = true; }
  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG ~__exception_guard() { _LIBCPP_ASSERT(__completed_); }

private:
  bool __completed_;
};

This way, we enforce the intended usage of the class -- when exceptions are disabled, __complete() should always get called. And concretely this will get optimized away.

The reason I'm not a fan of depending on uncaught_exceptions() is that the function is defined in libc++abi.dylib. I am concerned about adding a call to a function hidden behind an ABI boundary that the optimizer doesn't know anything about, when instead we could just be setting and checking a bool visible to the optimizer in this very scope.

[philnik]

• Rebased
• Address comments

[ldionne]

libcxx/include/__utility/exception_guard.h

106

libcxx/test/libcxx/utilities/exception_guard.pass.cpp

28

This doesn't make sense to me. I think this whole test case doesn't make sense when exceptions are disabled. For example, this would fail when exceptions are disabled and assertions are enabled.

54

Same here, this test case doesn't make sense when exceptions are disabled.

[philnik]

Address comments

[philnik]

Try to fix CI

[philnik]

Fix includes

[philnik]

Fix modules build

[ldionne]

An interesting thought occurred to me last night. Let's say we have the following sandwich of code:

A // -fexceptions
B // -fno-exceptions
C // -fexceptions

Now assume that C throws an exception. The current behavior is that the exception will propagate through B (where it can't be caught) and then potentially be caught inside A. I don't know how common the full sandwich is, however a very common example of B and C are B = any-code-compiled-without-exceptions and C = libc++.dylib on most platforms. I would presume that this situation does arise in the wild.

We looked at the code generation in -fno-exceptions and the B slice of the sandwich simply does not contain any cleanup code (and hence no call to __transaction's destructor). If it did, the fact that we have a _LIBCPP_ASSERT inside the destructor would be a behavioral change where instead of letting the exception propagate freely through B (and potentially being caught higher up), we would now instead turn it into a hard error via __libcpp_verbose_abort.

We also discussed the possibility of not making this change at all so that the destructor can be called to clean things up if needed. However, since Clang already does not generate any cleanup code when -fno-exceptions is used, it looks like the choice not to provide the usual exception safety guarantees in -fno-exceptions code has already been made, and we're just following suite.

@philnik Can you please summarize this in a comment somewhere in __transaction? I think this is useful for posterity since it's not exactly obvious.

[philnik]

• Address comments
• Try to fix CI

[Mordante]

In general quite happy with the current form! But I think I spotted a bug, and found some minor nits.

Can you also update the title of the patch.

libcxx/include/__utility/exception_guard.h

30

replace transaction with exception guard/__exception_guard in this paragraph.

41

Nit: I prefer comments to stay in the 80 column limit. These long lines are less easy to read. For a single line it's not too bad, but this is quite a bit of text.

41

Maybe copy this paragraph in the commit message.

59

Nice comment!

68

Since this is a new file can you s/_VSTD/std/ in this file?

106

I think there is a bug here. The normal move sets __other.__completed_ this one doesn't.
I think there should be a test for this case too.

[philnik]

Address comments

[philnik]

Try to fix CI

[philnik]

Try to fix CI

[Mordante]

LGTM!

[bgraur]

We're seeing a lot of fallout from this patch and they all look related to the ODR violations that seem to be intentionally added here: both the patch description and the comment for the __exception_guard mention explicitly that combinations of code compiled with exceptions and without exceptions are common.

Am I missing something here?

[philnik]

In D133661#4093298, @bgraur wrote:

We're seeing a lot of fallout from this patch and they all look related to the ODR violations that seem to be intentionally added here: both the patch description and the comment for the __exception_guard mention explicitly that combinations of code compiled with exceptions and without exceptions are common.

Am I missing something here?

Do you have a specific example? We have similar ODR violations all over the code base related to exception handling.

[alexfh]

In D133661#4093307, @philnik wrote:

In D133661#4093298, @bgraur wrote:

We're seeing a lot of fallout from this patch and they all look related to the ODR violations that seem to be intentionally added here: both the patch description and the comment for the __exception_guard mention explicitly that combinations of code compiled with exceptions and without exceptions are common.

Am I missing something here?

Do you have a specific example?

Well, we have tons of different examples, but most of them are difficult to isolate and reduce. Some of them manifest in linker complaining about invalid debug information in thinlto mode. Some manifest as runtime crashes and/or sanitizer errors. We'll try to provide something specific, but it may take days to come up with something.

We have similar ODR violations all over the code base related to exception handling.

Well, I don't know how bad these were, but we definitely didn't see any related issues previously. Maybe this commit was the straw that broke the camel's back or it introduced a novel kind of an ODR violation when using mixed exception modes, e.g. that previously the differences were limited to exception handling within function bodies and now the definition of the __exception_guard class being different is somehow more problematic.

[dblaikie]

the definition of the __exception_guard class being different is somehow more problematic.

That's correct - Clang/LLVM debug info under LTO does require structures with linkage to have consistent size at least.
The sort of errors are:

fragment is larger than or outside of variable
  call void @llvm.dbg.declare(metadata ptr undef, metadata !4274, metadata !DIExpression(DW_OP_LLVM_fragment, 200, 56)), !dbg !4288
!4274 = !DILocalVariable(name: "__guard", scope: !4275, file: !2826, line: 550, type: !2906)

Because LLVM LTO is validating that the debug info describing a variable makes sense given the type - but the type is deduplicated based on the linkage name of the type - so some debug info was emitted in some +exceptions code that is larger than the type definition taken from some -exceptions code.

I think some possible fixes would include

• make the structure the same size regardless of +/-exceptions
• use a macro to choose between two differently-linkage-named types (yeah, this is still an ODR violaiton for the function definitions that use these different entities - but within the realms of things we do for +/-exception compatibility, and nothing validates that ODR function definitions are identical)

I'll see if I can repro this with godbolt, but I think this ^ should be enough to justify a timely revert and/or fix. This patch is broken for mixed exceptions LTO builds.

[philnik]

In D133661#4094917, @dblaikie wrote:

the definition of the __exception_guard class being different is somehow more problematic.

That's correct - Clang/LLVM debug info under LTO does require structures with linkage to have consistent size at least.
The sort of errors are:

fragment is larger than or outside of variable
  call void @llvm.dbg.declare(metadata ptr undef, metadata !4274, metadata !DIExpression(DW_OP_LLVM_fragment, 200, 56)), !dbg !4288
!4274 = !DILocalVariable(name: "__guard", scope: !4275, file: !2826, line: 550, type: !2906)

Because LLVM LTO is validating that the debug info describing a variable makes sense given the type - but the type is deduplicated based on the linkage name of the type - so some debug info was emitted in some +exceptions code that is larger than the type definition taken from some -exceptions code.

I think some possible fixes would include

• make the structure the same size regardless of +/-exceptions
• use a macro to choose between two differently-linkage-named types (yeah, this is still an ODR violaiton for the function definitions that use these different entities - but within the realms of things we do for +/-exception compatibility, and nothing validates that ODR function definitions are identical)

I'll see if I can repro this with godbolt, but I think this ^ should be enough to justify a timely revert and/or fix. This patch is broken for mixed exceptions LTO builds.

Please don't revert. Other patches depend on this and it should be a trivial fix. We can just add an ABI tag to the noexcept version of the class IIUC. Could you confirm that? If that is the case I can make a patch.

[dblaikie]

In D133661#4094932, @philnik wrote:

In D133661#4094917, @dblaikie wrote:

the definition of the __exception_guard class being different is somehow more problematic.

That's correct - Clang/LLVM debug info under LTO does require structures with linkage to have consistent size at least.
The sort of errors are:

fragment is larger than or outside of variable
  call void @llvm.dbg.declare(metadata ptr undef, metadata !4274, metadata !DIExpression(DW_OP_LLVM_fragment, 200, 56)), !dbg !4288
!4274 = !DILocalVariable(name: "__guard", scope: !4275, file: !2826, line: 550, type: !2906)

Because LLVM LTO is validating that the debug info describing a variable makes sense given the type - but the type is deduplicated based on the linkage name of the type - so some debug info was emitted in some +exceptions code that is larger than the type definition taken from some -exceptions code.

I think some possible fixes would include

• make the structure the same size regardless of +/-exceptions
• use a macro to choose between two differently-linkage-named types (yeah, this is still an ODR violaiton for the function definitions that use these different entities - but within the realms of things we do for +/-exception compatibility, and nothing validates that ODR function definitions are identical)

I'll see if I can repro this with godbolt, but I think this ^ should be enough to justify a timely revert and/or fix. This patch is broken for mixed exceptions LTO builds.

Please don't revert. Other patches depend on this and it should be a trivial fix. We can just add an ABI tag to the noexcept version of the class IIUC. Could you confirm that? If that is the case I can make a patch.

Not quite sure what you mean - got a rough example of what an ABI tag would look like in this case? (looking through the libc++ sources notihng immediately stands out) - an extra template parameter (I see "Abi" template parameters in some places, for instance) or some other technique?

[philnik]

In D133661#4095014, @dblaikie wrote:

In D133661#4094932, @philnik wrote:

In D133661#4094917, @dblaikie wrote:

the definition of the __exception_guard class being different is somehow more problematic.

That's correct - Clang/LLVM debug info under LTO does require structures with linkage to have consistent size at least.
The sort of errors are:

fragment is larger than or outside of variable
  call void @llvm.dbg.declare(metadata ptr undef, metadata !4274, metadata !DIExpression(DW_OP_LLVM_fragment, 200, 56)), !dbg !4288
!4274 = !DILocalVariable(name: "__guard", scope: !4275, file: !2826, line: 550, type: !2906)

Because LLVM LTO is validating that the debug info describing a variable makes sense given the type - but the type is deduplicated based on the linkage name of the type - so some debug info was emitted in some +exceptions code that is larger than the type definition taken from some -exceptions code.

I think some possible fixes would include

• make the structure the same size regardless of +/-exceptions
• use a macro to choose between two differently-linkage-named types (yeah, this is still an ODR violaiton for the function definitions that use these different entities - but within the realms of things we do for +/-exception compatibility, and nothing validates that ODR function definitions are identical)

I'll see if I can repro this with godbolt, but I think this ^ should be enough to justify a timely revert and/or fix. This patch is broken for mixed exceptions LTO builds.

Please don't revert. Other patches depend on this and it should be a trivial fix. We can just add an ABI tag to the noexcept version of the class IIUC. Could you confirm that? If that is the case I can make a patch.

Not quite sure what you mean - got a rough example of what an ABI tag would look like in this case? (looking through the libc++ sources notihng immediately stands out) - an extra template parameter (I see "Abi" template parameters in some places, for instance) or some other technique?

I mean [[gnu::abi_tag("-fno-exceptions")]].

[rupprecht]

The ABI tag approach fixes the ODR issue I was looking at

@@ -60,7 +60,7 @@

 #ifndef _LIBCPP_NO_EXCEPTIONS
 template <class _Rollback>
-struct __exception_guard {
+struct __attribute__((__abi_tag__(("fexceptions")))) __exception_guard {
   __exception_guard() = delete;

   _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 explicit __exception_guard(_Rollback __rollback)
@@ -89,7 +89,7 @@
 };
 #else  // _LIBCPP_NO_EXCEPTIONS
 template <class _Rollback>
-struct __exception_guard {
+struct __attribute__((__abi_tag__(("fnoexceptions")))) __exception_guard  {
   __exception_guard() = delete;
   _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG explicit __exception_guard(_Rollback) {}

[alexfh]

In D133661#4095119, @rupprecht wrote:

The ABI tag approach fixes the ODR issue I was looking at

@@ -60,7 +60,7 @@

 #ifndef _LIBCPP_NO_EXCEPTIONS
 template <class _Rollback>
-struct __exception_guard {
+struct __attribute__((__abi_tag__(("fexceptions")))) __exception_guard {
   __exception_guard() = delete;

   _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 explicit __exception_guard(_Rollback __rollback)
@@ -89,7 +89,7 @@
 };
 #else  // _LIBCPP_NO_EXCEPTIONS
 template <class _Rollback>
-struct __exception_guard {
+struct __attribute__((__abi_tag__(("fnoexceptions")))) __exception_guard  {
   __exception_guard() = delete;
   _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG explicit __exception_guard(_Rollback) {}

Same patch fixes a large fraction of other issues we've been looking at.

[alexfh]

@philnik could you commit one of the proposed abi_tag fixes?

[alexfh]

In D133661#4096263, @alexfh wrote:

@philnik could you commit one of the proposed abi_tag fixes?

Actually, I went ahead and committed it as 561105fb9d3a16f7fb8c718cc5da71b11f17a144 to unblock us. Hopefully, that's small and obvious enough to not violate the code review policies.

[rupprecht]

In D133661#4096429, @alexfh wrote:

In D133661#4096263, @alexfh wrote:

@philnik could you commit one of the proposed abi_tag fixes?

Actually, I went ahead and committed it as 561105fb9d3a16f7fb8c718cc5da71b11f17a144 to unblock us. Hopefully, that's small and obvious enough to not violate the code review policies.

libc++ has a pretty good precommit test infra that gets triggered when a review is created, so in the future it would be better to create a review and wait for CI before landing w/o review.

Although gnu::abi_tag was suggested, I took that to mean __attribute__((__abi_tag__(...))) when I tested the suggestion locally, as elsewhere libc++ uses ABI tags like so:

#    define _LIBCPP_HIDE_FROM_ABI                                                                                      \
      _LIBCPP_HIDDEN _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION                                                       \
          __attribute__((__abi_tag__(_LIBCPP_TOSTRING(_LIBCPP_VERSIONED_IDENTIFIER))))

[philnik]

In D133661#4096544, @rupprecht wrote:

In D133661#4096429, @alexfh wrote:

In D133661#4096263, @alexfh wrote:

@philnik could you commit one of the proposed abi_tag fixes?

Actually, I went ahead and committed it as 561105fb9d3a16f7fb8c718cc5da71b11f17a144 to unblock us. Hopefully, that's small and obvious enough to not violate the code review policies.

libc++ has a pretty good precommit test infra that gets triggered when a review is created, so in the future it would be better to create a review and wait for CI before landing w/o review.

Although gnu::abi_tag was suggested, I took that to mean __attribute__((__abi_tag__(...))) when I tested the suggestion locally, as elsewhere libc++ uses ABI tags like so:

#    define _LIBCPP_HIDE_FROM_ABI                                                                                      \
      _LIBCPP_HIDDEN _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION                                                       \
          __attribute__((__abi_tag__(_LIBCPP_TOSTRING(_LIBCPP_VERSIONED_IDENTIFIER))))

I reverted, since that breaks C++03. I'll commit a proper fix probably by the end of the day.

[philnik]

I've uploaded D143071 to fix the problem. I talk to Louis later today, so a fix should be commited within the next 6 hours or so.

[alexfh]

In D133661#4096636, @philnik wrote:

I've uploaded D143071 to fix the problem. I talk to Louis later today, so a fix should be commited within the next 6 hours or so.

Thanks and apologies for doing this myself in hurry - this issue has been blocking our release testing for quite some time and I needed at least a temporary solution in the tree. I'll try to follow the review process next time.

libcxx/include/CMakeLists.txt

set(files
   __type_traits/underlying_type.h
   __type_traits/void_t.h
   __undef_macros
   __utility/as_const.h
   __utility/auto_cast.h
   __utility/cmp.h
   __utility/convert_to_integral.h
   __utility/declval.h
+  __utility/exception_guard.h
   __utility/exchange.h
   __utility/forward.h
   __utility/forward_like.h
   __utility/in_place.h
   __utility/integer_sequence.h
   __utility/move.h
   __utility/pair.h
   __utility/piecewise_construct.h
   __utility/priority_tag.h
   __utility/rel_ops.h
   __utility/swap.h
   __utility/to_underlying.h
-  __utility/transaction.h
   __utility/unreachable.h
   __variant/monostate.h
   __verbose_abort
   algorithm
   any
   array
   atomic
   barrier

libcxx/include/__expected/expected.h

 #include <__type_traits/is_trivially_copy_constructible.h>
 #include <__type_traits/is_trivially_destructible.h>
 #include <__type_traits/is_trivially_move_constructible.h>
 #include <__type_traits/is_void.h>
 #include <__type_traits/lazy.h>
 #include <__type_traits/negation.h>
 #include <__type_traits/remove_cv.h>
 #include <__type_traits/remove_cvref.h>
+#include <__utility/exception_guard.h>
 #include <__utility/forward.h>
 #include <__utility/in_place.h>
 #include <__utility/move.h>
 #include <__utility/swap.h>
-#include <__utility/transaction.h>
 #include <cstdlib> // for std::abort
 #include <initializer_list>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 #if _LIBCPP_STD_VER >= 23
if constexpr (is_nothrow_constructible_v<_T1, _Args...>) {
       std::construct_at(std::addressof(__newval), std::move(__tmp));
     } else {
       static_assert(
           is_nothrow_move_constructible_v<_T2>,
           "To provide strong exception guarantee, T2 has to satisfy `is_nothrow_move_constructible_v` so that it can "
           "be reverted to the previous state in case an exception is thrown during the assignment.");
       _T2 __tmp(std::move(__oldval));
       std::destroy_at(std::addressof(__oldval));
-      __transaction __trans([&] { std::construct_at(std::addressof(__oldval), std::move(__tmp)); });
+      __exception_guard __trans([&] { std::construct_at(std::addressof(__oldval), std::move(__tmp)); });
       std::construct_at(std::addressof(__newval), std::forward<_Args>(__args)...);
       __trans.__complete();
     }
   }
 
 public:
   // [expected.object.assign], assignment
   _LIBCPP_HIDE_FROM_ABI constexpr expected& operator=(const expected&) = delete;
requires(is_swappable_v<_Tp> &&
              is_move_constructible_v<_Err> &&
              (is_nothrow_move_constructible_v<_Tp> ||
               is_nothrow_move_constructible_v<_Err>))
   {
     auto __swap_val_unex_impl = [&](expected& __with_val, expected& __with_err) {
       if constexpr (is_nothrow_move_constructible_v<_Err>) {
         _Err __tmp(std::move(__with_err.__union_.__unex_));
         std::destroy_at(std::addressof(__with_err.__union_.__unex_));
-        __transaction __trans([&] {
+        __exception_guard __trans([&] {
           std::construct_at(std::addressof(__with_err.__union_.__unex_), std::move(__tmp));
         });
         std::construct_at(std::addressof(__with_err.__union_.__val_), std::move(__with_val.__union_.__val_));
         __trans.__complete();
         std::destroy_at(std::addressof(__with_val.__union_.__val_));
         std::construct_at(std::addressof(__with_val.__union_.__unex_), std::move(__tmp));
       } else {
         static_assert(is_nothrow_move_constructible_v<_Tp>,
                       "To provide strong exception guarantee, Tp has to satisfy `is_nothrow_move_constructible_v` so "
                       "that it can be reverted to the previous state in case an exception is thrown during swap.");
         _Tp __tmp(std::move(__with_val.__union_.__val_));
         std::destroy_at(std::addressof(__with_val.__union_.__val_));
-        __transaction __trans([&] { std::construct_at(std::addressof(__with_val.__union_.__val_), std::move(__tmp)); });
+        __exception_guard __trans([&] {
+          std::construct_at(std::addressof(__with_val.__union_.__val_), std::move(__tmp));
+        });
         std::construct_at(std::addressof(__with_val.__union_.__unex_), std::move(__with_err.__union_.__unex_));
         __trans.__complete();
         std::destroy_at(std::addressof(__with_err.__union_.__unex_));
         std::construct_at(std::addressof(__with_err.__union_.__val_), std::move(__tmp));
       }
       __with_val.__has_val_ = false;
       __with_err.__has_val_ = true;
     };

libcxx/include/__memory/uninitialized_algorithms.h

 #include <__type_traits/is_trivially_copy_assignable.h>
 #include <__type_traits/is_trivially_copy_constructible.h>
 #include <__type_traits/is_trivially_move_assignable.h>
 #include <__type_traits/is_trivially_move_constructible.h>
 #include <__type_traits/is_unbounded_array.h>
 #include <__type_traits/negation.h>
 #include <__type_traits/remove_const.h>
 #include <__type_traits/remove_extent.h>
+#include <__utility/exception_guard.h>
 #include <__utility/move.h>
 #include <__utility/pair.h>
-#include <__utility/transaction.h>
 #include <new>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
constexpr void __allocator_construct_at(_Alloc& __alloc, _Tp* __loc) {
 
     if constexpr (is_array_v<_Tp>) {
         using _Element = remove_extent_t<_Tp>;
         __allocator_traits_rebind_t<_Alloc, _Element> __elem_alloc(__alloc);
         size_t __i = 0;
         _Tp& __array = *__loc;
 
         // If an exception is thrown, destroy what we have constructed so far in reverse order.
-        __transaction __guard([&]() { std::__allocator_destroy_multidimensional(__elem_alloc, __array, __array + __i); });
+        __exception_guard __guard([&]() {
+          std::__allocator_destroy_multidimensional(__elem_alloc, __array, __array + __i);
+        });
+
         for (; __i != extent_v<_Tp>; ++__i) {
             std::__allocator_construct_at(__elem_alloc, std::addressof(__array[__i]));
         }
         __guard.__complete();
     } else {
         allocator_traits<_Alloc>::construct(__alloc, __loc);
     }
 }
if constexpr (is_array_v<_Tp>) {
             "trying to construct an array.");
 
         using _Element = remove_extent_t<_Tp>;
         __allocator_traits_rebind_t<_Alloc, _Element> __elem_alloc(__alloc);
         size_t __i = 0;
         _Tp& __array = *__loc;
 
         // If an exception is thrown, destroy what we have constructed so far in reverse order.
-        __transaction __guard([&]() { std::__allocator_destroy_multidimensional(__elem_alloc, __array, __array + __i); });
+        __exception_guard __guard([&]() {
+          std::__allocator_destroy_multidimensional(__elem_alloc, __array, __array + __i);
+        });
         for (; __i != extent_v<_Tp>; ++__i) {
             std::__allocator_construct_at(__elem_alloc, std::addressof(__array[__i]), __arg[__i]);
         }
         __guard.__complete();
     } else {
         allocator_traits<_Alloc>::construct(__alloc, __loc, __arg);
     }
 }
 
 // Given a range starting at it and containing n elements, initializes each element in the
 // range from left to right using the construct method of the allocator (rebound to the
 // correct type).
 //
 // If an exception is thrown, the initialized elements are destroyed in reverse order of
 // initialization using allocator_traits destruction. If the elements in the range are C-style
 // arrays, they are initialized element-wise using allocator construction, and recursively so.
 template<class _Alloc, class _BidirIter, class _Tp, class _Size = typename iterator_traits<_BidirIter>::difference_type>
 _LIBCPP_HIDE_FROM_ABI
 constexpr void __uninitialized_allocator_fill_n(_Alloc& __alloc, _BidirIter __it, _Size __n, _Tp const& __value) {
     using _ValueType = typename iterator_traits<_BidirIter>::value_type;
     __allocator_traits_rebind_t<_Alloc, _ValueType> __value_alloc(__alloc);
     _BidirIter __begin = __it;
 
     // If an exception is thrown, destroy what we have constructed so far in reverse order.
-    __transaction __guard([&]() { std::__allocator_destroy_multidimensional(__value_alloc, __begin, __it); });
+    __exception_guard __guard([&]() { std::__allocator_destroy_multidimensional(__value_alloc, __begin, __it); });
     for (; __n != 0; --__n, ++__it) {
         std::__allocator_construct_at(__value_alloc, std::addressof(*__it), __value);
     }
     __guard.__complete();
 }
 
 // Same as __uninitialized_allocator_fill_n, but doesn't pass any initialization argument
 // to the allocator's construct method, which results in value initialization.
 template<class _Alloc, class _BidirIter, class _Size = typename iterator_traits<_BidirIter>::difference_type>
 _LIBCPP_HIDE_FROM_ABI
 constexpr void __uninitialized_allocator_value_construct_n(_Alloc& __alloc, _BidirIter __it, _Size __n) {
     using _ValueType = typename iterator_traits<_BidirIter>::value_type;
     __allocator_traits_rebind_t<_Alloc, _ValueType> __value_alloc(__alloc);
     _BidirIter __begin = __it;
 
     // If an exception is thrown, destroy what we have constructed so far in reverse order.
-    __transaction __guard([&]() { std::__allocator_destroy_multidimensional(__value_alloc, __begin, __it); });
+    __exception_guard __guard([&]() { std::__allocator_destroy_multidimensional(__value_alloc, __begin, __it); });
     for (; __n != 0; --__n, ++__it) {
         std::__allocator_construct_at(__value_alloc, std::addressof(*__it));
     }
     __guard.__complete();
 }
 
 #endif // _LIBCPP_STD_VER > 14
 

 
 // Copy-construct [__first1, __last1) in [__first2, __first2 + N), where N is distance(__first1, __last1).
 //
 // The caller has to ensure that __first2 can hold at least N uninitialized elements. If an exception is thrown the
 // already copied elements are destroyed in reverse order of their construction.
 template <class _Alloc, class _Iter1, class _Sent1, class _Iter2>
 _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _Iter2
 __uninitialized_allocator_copy(_Alloc& __alloc, _Iter1 __first1, _Sent1 __last1, _Iter2 __first2) {
-#ifndef _LIBCPP_NO_EXCEPTIONS
   auto __destruct_first = __first2;
-  try {
-#endif
+  auto __guard =
+      std::__make_exception_guard(_AllocatorDestroyRangeReverse<_Alloc, _Iter2>(__alloc, __destruct_first, __first2));
   while (__first1 != __last1) {
     allocator_traits<_Alloc>::construct(__alloc, std::__to_address(__first2), *__first1);
     ++__first1;
     ++__first2;
   }
-#ifndef _LIBCPP_NO_EXCEPTIONS
-  } catch (...) {
-    _AllocatorDestroyRangeReverse<_Alloc, _Iter2>(__alloc, __destruct_first, __first2)();
-    throw;
-  }
-#endif
+  __guard.__complete();
   return __first2;
 }
 
 template <class _Alloc, class _Type>
 struct __allocator_has_trivial_copy_construct : _Not<__has_construct<_Alloc, _Type*, const _Type&> > {};
 
 template <class _Type>
 struct __allocator_has_trivial_copy_construct<allocator<_Type>, _Type> : true_type {};

 //
 // Otherwise try to copy all elements. If an exception is thrown the already copied
 // elements are destroyed in reverse order of their construction.
 template <class _Alloc, class _Iter1, class _Sent1, class _Iter2>
 _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _Iter2 __uninitialized_allocator_move_if_noexcept(
     _Alloc& __alloc, _Iter1 __first1, _Sent1 __last1, _Iter2 __first2) {
   static_assert(__is_cpp17_move_insertable<_Alloc>::value,
                 "The specified type does not meet the requirements of Cpp17MoveInsertable");
-#ifndef _LIBCPP_NO_EXCEPTIONS
   auto __destruct_first = __first2;
-  try {
-#endif
+  auto __guard =
+      std::__make_exception_guard(_AllocatorDestroyRangeReverse<_Alloc, _Iter2>(__alloc, __destruct_first, __first2));
   while (__first1 != __last1) {
 #ifndef _LIBCPP_NO_EXCEPTIONS
     allocator_traits<_Alloc>::construct(__alloc, std::__to_address(__first2), std::move_if_noexcept(*__first1));
 #else
     allocator_traits<_Alloc>::construct(__alloc, std::__to_address(__first2), std::move(*__first1));
 #endif
     ++__first1;
     ++__first2;
   }
-#ifndef _LIBCPP_NO_EXCEPTIONS
-  } catch (...) {
-    _AllocatorDestroyRangeReverse<_Alloc, _Iter2>(__alloc, __destruct_first, __first2)();
-    throw;
-  }
-#endif
+  __guard.__complete();
   return __first2;
 }
 
 template <class _Alloc, class _Type>
 struct __allocator_has_trivial_move_construct : _Not<__has_construct<_Alloc, _Type*, _Type&&> > {};
 
 template <class _Type>
 struct __allocator_has_trivial_move_construct<allocator<_Type>, _Type> : true_type {};

libcxx/include/__memory_resource/polymorphic_allocator.h

 //===----------------------------------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef _LIBCPP___MEMORY_RESOURCE_POLYMORPHIC_ALLOCATOR_H
 #define _LIBCPP___MEMORY_RESOURCE_POLYMORPHIC_ALLOCATOR_H
 
 #include <__assert>
 #include <__config>
 #include <__memory_resource/memory_resource.h>
-#include <__utility/transaction.h>
+#include <__utility/exception_guard.h>
 #include <cstddef>
 #include <limits>
 #include <new>
 #include <stdexcept>
 #include <tuple>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
#  if _LIBCPP_STD_VER >= 20
   template <class _Type>
   void deallocate_object(_Type* __ptr, size_t __n = 1) {
     deallocate_bytes(__ptr, __n * sizeof(_Type), alignof(_Type));
   }
 
   template <class _Type, class... _CtorArgs>
   [[nodiscard]] _Type* new_object(_CtorArgs&&... __ctor_args) {
     _Type* __ptr = allocate_object<_Type>();
-    __transaction __guard([&] { deallocate_object(__ptr); });
+    __exception_guard __guard([&] { deallocate_object(__ptr); });
     construct(__ptr, std::forward<_CtorArgs>(__ctor_args)...);
     __guard.__complete();
     return __ptr;
   }
 
   template <class _Type>
   void delete_object(_Type* __ptr) {
     destroy(__ptr);

libcxx/include/__utility/exception_guard.h

+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef _LIBCPP___UTILITY_TRANSACTION_H
+#define _LIBCPP___UTILITY_TRANSACTION_H
+
+#include <__assert>
+#include <__config>
+#include <__type_traits/is_nothrow_move_constructible.h>
+#include <__utility/exchange.h>
+#include <__utility/move.h>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+// __exception_guard is a helper class for writing code with the strong exception guarantee.
+//
+// When writing code that can throw an exception, one can store rollback instructions in an
+// exception guard so that if an exception is thrown at any point during the lifetime of the
+// exception guard, it will be rolled back automatically. When the exception guard is done, one
+// must mark it as being complete so it isn't rolled back when the exception guard is destroyed.
+//
+// Exception guards are not default constructible, they can't be copied or assigned to, but
+// they can be moved around for convenience.
+//
+// __exception_guard is a no-op in -fno-exceptions mode to produce better code-gen. This means
+// that we don't provide the strong exception guarantees. However, Clang doesn't generate cleanup
+// code with exceptions disabled, so even if we wanted to provide the strong exception guarantees
+// we couldn't. This is also only relevant for constructs with a stack of
+// -fexceptions > -fno-exceptions > -fexceptions code, since the exception can't be caught where
+// exceptions are disabled. While -fexceptions > -fno-exceptions is quite common
+// (e.g. libc++.dylib > -fno-exceptions), having another layer with exceptions enabled seems a lot
+// less common, especially one that tries to catch an exception through -fno-exceptions code.
+//
+// __exception_guard can help greatly simplify code that would normally be cluttered by
+// `#if _LIBCPP_NO_EXCEPTIONS`. For example:
+//
+//    template <class Iterator, class Size, class OutputIterator>
+//    Iterator uninitialized_copy_n(Iterator iter, Size n, OutputIterator out) {
+//        typedef typename iterator_traits<Iterator>::value_type value_type;
+//        __exception_guard guard([start=out, &out] {
+//            std::destroy(start, out);
+//        });
+//
+//        for (; n > 0; ++iter, ++out, --n) {
+//            ::new ((void*)std::addressof(*out)) value_type(*iter);
+//        }
+//        guard.__complete();
+//        return out;
+//    }
+//
+
+#ifndef _LIBCPP_NO_EXCEPTIONS
+template <class _Rollback>
+struct __exception_guard {
+  __exception_guard() = delete;
+
+  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 explicit __exception_guard(_Rollback __rollback)
+      : __rollback_(std::move(__rollback)), __completed_(false) {}
+
+  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 __exception_guard(__exception_guard&& __other)
+      _NOEXCEPT_(is_nothrow_move_constructible<_Rollback>::value)
+      : __rollback_(std::move(__other.__rollback_)), __completed_(__other.__completed_) {
+    __other.__completed_ = true;
+  }
+
+  __exception_guard(__exception_guard const&)            = delete;
+  __exception_guard& operator=(__exception_guard const&) = delete;
+  __exception_guard& operator=(__exception_guard&&)      = delete;
+
+  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 void __complete() _NOEXCEPT { __completed_ = true; }
+
+  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 ~__exception_guard() {
+    if (!__completed_)
+      __rollback_();
+  }
+
+private:
+  _Rollback __rollback_;
+  bool __completed_;
+};
+#else  // _LIBCPP_NO_EXCEPTIONS
+template <class _Rollback>
+struct __exception_guard {
+  __exception_guard() = delete;
+  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG explicit __exception_guard(_Rollback) {}
+
+  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG __exception_guard(__exception_guard&& __other)
+      _NOEXCEPT_(is_nothrow_move_constructible<_Rollback>::value)
+      : __completed_(__other.__completed_) {
+    __other.__completed_ = true;
+  }
+
+  __exception_guard(__exception_guard const&)            = delete;
+  __exception_guard& operator=(__exception_guard const&) = delete;
+  __exception_guard& operator=(__exception_guard&&)      = delete;
+
+  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG void __complete() _NOEXCEPT {
+    __completed_ = true;
+  }
+
+  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_NODEBUG ~__exception_guard() {
+    _LIBCPP_ASSERT(__completed_, "__exception_guard not completed with exceptions disabled");
+  }
+
+private:
+  bool __completed_ = false;
+};
+#endif // _LIBCPP_NO_EXCEPTIONS
+
+_LIBCPP_CTAD_SUPPORTED_FOR_TYPE(__exception_guard);
+
+template <class _Rollback>
+_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR __exception_guard<_Rollback> __make_exception_guard(_Rollback __rollback) {
+  return __exception_guard<_Rollback>(std::move(__rollback));
+}
+
+_LIBCPP_END_NAMESPACE_STD
+
+#endif // _LIBCPP___UTILITY_TRANSACTION_H

libcxx/include/__utility/transaction.h

-//===----------------------------------------------------------------------===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===----------------------------------------------------------------------===//
-
-#ifndef _LIBCPP___UTILITY_TRANSACTION_H
-#define _LIBCPP___UTILITY_TRANSACTION_H
-
-#include <__config>
-#include <__type_traits/is_nothrow_move_constructible.h>
-#include <__utility/exchange.h>
-#include <__utility/move.h>
-
-#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
-#  pragma GCC system_header
-#endif
-
-_LIBCPP_BEGIN_NAMESPACE_STD
-
-// __transaction is a helper class for writing code with the strong exception guarantee.
-//
-// When writing code that can throw an exception, one can store rollback instructions in a
-// transaction so that if an exception is thrown at any point during the lifetime of the
-// transaction, it will be rolled back automatically. When the transaction is done, one
-// must mark it as being complete so it isn't rolled back when the transaction is destroyed.
-//
-// Transactions are not default constructible, they can't be copied or assigned to, but
-// they can be moved around for convenience.
-//
-// __transaction can help greatly simplify code that would normally be cluttered by
-// `#if _LIBCPP_NO_EXCEPTIONS`. For example:
-//
-//    template <class Iterator, class Size, class OutputIterator>
-//    Iterator uninitialized_copy_n(Iterator iter, Size n, OutputIterator out) {
-//        typedef typename iterator_traits<Iterator>::value_type value_type;
-//        __transaction transaction([start=out, &out] {
-//            std::destroy(start, out);
-//        });
-//
-//        for (; n > 0; ++iter, ++out, --n) {
-//            ::new ((void*)std::addressof(*out)) value_type(*iter);
-//        }
-//        transaction.__complete();
-//        return out;
-//    }
-//
-template <class _Rollback>
-struct __transaction {
-    __transaction() = delete;
-
-    _LIBCPP_HIDE_FROM_ABI
-    _LIBCPP_CONSTEXPR_SINCE_CXX20 explicit __transaction(_Rollback __rollback)
-        : __rollback_(_VSTD::move(__rollback))
-        , __completed_(false)
-    { }
-
-    _LIBCPP_HIDE_FROM_ABI
-    _LIBCPP_CONSTEXPR_SINCE_CXX20 __transaction(__transaction&& __other)
-        _NOEXCEPT_(is_nothrow_move_constructible<_Rollback>::value)
-        : __rollback_(_VSTD::move(__other.__rollback_))
-        , __completed_(__other.__completed_)
-    {
-        __other.__completed_ = true;
-    }
-
-    __transaction(__transaction const&) = delete;
-    __transaction& operator=(__transaction const&) = delete;
-    __transaction& operator=(__transaction&&) = delete;
-
-    _LIBCPP_HIDE_FROM_ABI
-    _LIBCPP_CONSTEXPR_SINCE_CXX20 void __complete() _NOEXCEPT {
-        __completed_ = true;
-    }
-
-    _LIBCPP_HIDE_FROM_ABI
-    _LIBCPP_CONSTEXPR_SINCE_CXX20 ~__transaction() {
-        if (!__completed_)
-            __rollback_();
-    }
-
-private:
-    _Rollback __rollback_;
-    bool __completed_;
-};
-_LIBCPP_CTAD_SUPPORTED_FOR_TYPE(__transaction);
-
-template <class _Rollback>
-_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR __transaction<_Rollback> __make_transaction(_Rollback __rollback) {
-  return __transaction<_Rollback>(std::move(__rollback));
-}
-
-_LIBCPP_END_NAMESPACE_STD
-
-#endif // _LIBCPP___UTILITY_TRANSACTION_H

libcxx/include/module.modulemap.in

module utility {
     export *
 
     module __utility {
       module as_const            { private header "__utility/as_const.h" }
       module auto_cast           { private header "__utility/auto_cast.h" }
       module cmp                 { private header "__utility/cmp.h" }
       module convert_to_integral { private header "__utility/convert_to_integral.h" }
       module declval             { private header "__utility/declval.h" }
+      module exception_guard     { private header "__utility/exception_guard.h" }
       module exchange            { private header "__utility/exchange.h" }
       module forward             { private header "__utility/forward.h" }
       module forward_like        { private header "__utility/forward_like.h" }
       module in_place            { private header "__utility/in_place.h" }
       module integer_sequence    { private header "__utility/integer_sequence.h" }
       module move                { private header "__utility/move.h" }
       module pair                { private header "__utility/pair.h" }
       module pair_fwd            { private header "__fwd/pair.h" }
       module piecewise_construct { private header "__utility/piecewise_construct.h" }
       module priority_tag        { private header "__utility/priority_tag.h" }
       module rel_ops             { private header "__utility/rel_ops.h" }
       module swap                { private header "__utility/swap.h" }
       module to_underlying       { private header "__utility/to_underlying.h" }
-      module transaction         { private header "__utility/transaction.h" }
       module unreachable         { private header "__utility/unreachable.h" }
     }
   }
   module valarray {
     header "valarray"
     export initializer_list
     export *
   }

libcxx/include/utility

 */
 
 #include <__assert> // all public C++ headers provide the assertion handler
 #include <__config>
 #include <__utility/as_const.h>
 #include <__utility/auto_cast.h>
 #include <__utility/cmp.h>
 #include <__utility/declval.h>
+#include <__utility/exception_guard.h>
 #include <__utility/exchange.h>
 #include <__utility/forward.h>
 #include <__utility/forward_like.h>
 #include <__utility/in_place.h>
 #include <__utility/integer_sequence.h>
 #include <__utility/move.h>
 #include <__utility/pair.h>
 #include <__utility/piecewise_construct.h>
 #include <__utility/priority_tag.h>
 #include <__utility/rel_ops.h>
 #include <__utility/swap.h>
 #include <__utility/to_underlying.h>
-#include <__utility/transaction.h>
 #include <__utility/unreachable.h>
 #include <version>
 
 // standard-mandated includes
 
 // [utility.syn]
 #include <compare>
 #include <initializer_list>

libcxx/include/vector

 #include <__memory/pointer_traits.h>
 #include <__memory/swap_allocator.h>
 #include <__memory/temp_value.h>
 #include <__memory/uninitialized_algorithms.h>
 #include <__memory_resource/polymorphic_allocator.h>
 #include <__split_buffer>
 #include <__type_traits/is_allocator.h>
 #include <__type_traits/noexcept_move_assign_container.h>
+#include <__utility/exception_guard.h>
 #include <__utility/forward.h>
 #include <__utility/move.h>
 #include <__utility/swap.h>
-#include <__utility/transaction.h>
 #include <climits>
 #include <cstdlib>
 #include <cstring>
 #include <iosfwd> // for forward declaration of vector
 #include <limits>
 #include <stdexcept>
 #include <type_traits>
 #include <version>
else
         __swap_out_circular_buffer(__v);
     }
 }
 
 template <class _Tp, class _Allocator>
 _LIBCPP_CONSTEXPR_SINCE_CXX20
 vector<_Tp, _Allocator>::vector(size_type __n)
 {
-    auto __guard = std::__make_transaction(__destroy_vector(*this));
+    auto __guard = std::__make_exception_guard(__destroy_vector(*this));
     std::__debug_db_insert_c(this);
     if (__n > 0)
     {
         __vallocate(__n);
         __construct_at_end(__n);
     }
     __guard.__complete();
 }
 
 #if _LIBCPP_STD_VER > 11
 template <class _Tp, class _Allocator>
 _LIBCPP_CONSTEXPR_SINCE_CXX20
 vector<_Tp, _Allocator>::vector(size_type __n, const allocator_type& __a)
     : __end_cap_(nullptr, __a)
 {
-    auto __guard = std::__make_transaction(__destroy_vector(*this));
+    auto __guard = std::__make_exception_guard(__destroy_vector(*this));
     std::__debug_db_insert_c(this);
     if (__n > 0)
     {
         __vallocate(__n);
         __construct_at_end(__n);
     }
     __guard.__complete();
 }
 #endif
 
 template <class _Tp, class _Allocator>
 _LIBCPP_CONSTEXPR_SINCE_CXX20
 vector<_Tp, _Allocator>::vector(size_type __n, const value_type& __x)
 {
-    auto __guard = std::__make_transaction(__destroy_vector(*this));
+    auto __guard = std::__make_exception_guard(__destroy_vector(*this));
     std::__debug_db_insert_c(this);
     if (__n > 0)
     {
         __vallocate(__n);
         __construct_at_end(__n, __x);
     }
     __guard.__complete();
 }
 
 template <class _Tp, class _Allocator>
 template <class _InputIterator, __enable_if_t<__is_exactly_cpp17_input_iterator<_InputIterator>::value &&
                               is_constructible<_Tp, typename iterator_traits<_InputIterator>::reference>::value,
                           int> >
 _LIBCPP_CONSTEXPR_SINCE_CXX20
 vector<_Tp, _Allocator>::vector(_InputIterator __first, _InputIterator __last)
 {
-    auto __guard = std::__make_transaction(__destroy_vector(*this));
+    auto __guard = std::__make_exception_guard(__destroy_vector(*this));
     std::__debug_db_insert_c(this);
     for (; __first != __last; ++__first)
         emplace_back(*__first);
     __guard.__complete();
 }
 
 template <class _Tp, class _Allocator>
 template <class _InputIterator, __enable_if_t<__is_exactly_cpp17_input_iterator<_InputIterator>::value &&
                               is_constructible<_Tp, typename iterator_traits<_InputIterator>::reference>::value,
                           int> >
 _LIBCPP_CONSTEXPR_SINCE_CXX20
 vector<_Tp, _Allocator>::vector(_InputIterator __first, _InputIterator __last, const allocator_type& __a)
     : __end_cap_(nullptr, __a)
 {
-    auto __guard = std::__make_transaction(__destroy_vector(*this));
+    auto __guard = std::__make_exception_guard(__destroy_vector(*this));
     std::__debug_db_insert_c(this);
     for (; __first != __last; ++__first)
         emplace_back(*__first);
     __guard.__complete();
 }
 
 template <class _Tp, class _Allocator>
 template <class _ForwardIterator, __enable_if_t<__is_cpp17_forward_iterator<_ForwardIterator>::value &&
                         is_constructible<_Tp, typename iterator_traits<_ForwardIterator>::reference>::value,
                     int> >
 _LIBCPP_CONSTEXPR_SINCE_CXX20
 vector<_Tp, _Allocator>::vector(_ForwardIterator __first, _ForwardIterator __last)
 {
-    auto __guard = std::__make_transaction(__destroy_vector(*this));
+    auto __guard = std::__make_exception_guard(__destroy_vector(*this));
     std::__debug_db_insert_c(this);
     size_type __n = static_cast<size_type>(std::distance(__first, __last));
     if (__n > 0)
     {
         __vallocate(__n);
         __construct_at_end(__first, __last, __n);
     }
     __guard.__complete();
 }
 
 template <class _Tp, class _Allocator>
 template <class _ForwardIterator, __enable_if_t<__is_cpp17_forward_iterator<_ForwardIterator>::value &&
                         is_constructible<_Tp, typename iterator_traits<_ForwardIterator>::reference>::value,
                     int> >
 _LIBCPP_CONSTEXPR_SINCE_CXX20
 vector<_Tp, _Allocator>::vector(_ForwardIterator __first, _ForwardIterator __last, const allocator_type& __a)
     : __end_cap_(nullptr, __a)
 {
-    auto __guard = std::__make_transaction(__destroy_vector(*this));
+    auto __guard = std::__make_exception_guard(__destroy_vector(*this));
     std::__debug_db_insert_c(this);
     size_type __n = static_cast<size_type>(std::distance(__first, __last));
     if (__n > 0)
     {
         __vallocate(__n);
         __construct_at_end(__first, __last, __n);
     }
     __guard.__complete();
 }
 
 template <class _Tp, class _Allocator>
 _LIBCPP_CONSTEXPR_SINCE_CXX20
 vector<_Tp, _Allocator>::vector(const vector& __x)
     : __end_cap_(nullptr, __alloc_traits::select_on_container_copy_construction(__x.__alloc()))
 {
-    auto __guard = std::__make_transaction(__destroy_vector(*this));
+    auto __guard = std::__make_exception_guard(__destroy_vector(*this));
     std::__debug_db_insert_c(this);
     size_type __n = __x.size();
     if (__n > 0)
     {
         __vallocate(__n);
         __construct_at_end(__x.__begin_, __x.__end_, __n);
     }
     __guard.__complete();
 }
 
 template <class _Tp, class _Allocator>
 _LIBCPP_CONSTEXPR_SINCE_CXX20
 vector<_Tp, _Allocator>::vector(const vector& __x, const __type_identity_t<allocator_type>& __a)
     : __end_cap_(nullptr, __a)
 {
-    auto __guard = std::__make_transaction(__destroy_vector(*this));
+    auto __guard = std::__make_exception_guard(__destroy_vector(*this));
     std::__debug_db_insert_c(this);
     size_type __n = __x.size();
     if (__n > 0)
     {
         __vallocate(__n);
         __construct_at_end(__x.__begin_, __x.__end_, __n);
     }
     __guard.__complete();
if (__a == __x.__alloc())
         this->__end_ = __x.__end_;
         this->__end_cap() = __x.__end_cap();
         __x.__begin_ = __x.__end_ = __x.__end_cap() = nullptr;
         std::__debug_db_swap(this, std::addressof(__x));
     }
     else
     {
         typedef move_iterator<iterator> _Ip;
-        auto __guard = std::__make_transaction(__destroy_vector(*this));
+        auto __guard = std::__make_exception_guard(__destroy_vector(*this));
         assign(_Ip(__x.begin()), _Ip(__x.end()));
         __guard.__complete();
     }
 }
 
 #ifndef _LIBCPP_CXX03_LANG
 
 template <class _Tp, class _Allocator>
 _LIBCPP_CONSTEXPR_SINCE_CXX20
 inline _LIBCPP_HIDE_FROM_ABI
 vector<_Tp, _Allocator>::vector(initializer_list<value_type> __il)
 {
-    auto __guard = std::__make_transaction(__destroy_vector(*this));
+    auto __guard = std::__make_exception_guard(__destroy_vector(*this));
     std::__debug_db_insert_c(this);
     if (__il.size() > 0)
     {
         __vallocate(__il.size());
         __construct_at_end(__il.begin(), __il.end(), __il.size());
     }
     __guard.__complete();
 }
 
 template <class _Tp, class _Allocator>
 _LIBCPP_CONSTEXPR_SINCE_CXX20
 inline _LIBCPP_HIDE_FROM_ABI
 vector<_Tp, _Allocator>::vector(initializer_list<value_type> __il, const allocator_type& __a)
     : __end_cap_(nullptr, __a)
 {
-    auto __guard = std::__make_transaction(__destroy_vector(*this));
+    auto __guard = std::__make_exception_guard(__destroy_vector(*this));
     std::__debug_db_insert_c(this);
     if (__il.size() > 0)
     {
         __vallocate(__il.size());
         __construct_at_end(__il.begin(), __il.end(), __il.size());
     }
     __guard.__complete();
 }

 template <class _ForwardIterator>
 _LIBCPP_CONSTEXPR_SINCE_CXX20
 vector<bool, _Allocator>::vector(_ForwardIterator __first, _ForwardIterator __last,
                                 typename enable_if<__is_cpp17_forward_iterator<_ForwardIterator>::value>::type*)
     : __begin_(nullptr),
       __size_(0),
       __cap_alloc_(0, __default_init_tag())
 {
-    auto __guard = std::__make_transaction(__destroy_vector(*this));
+    auto __guard = std::__make_exception_guard(__destroy_vector(*this));
     size_type __n = static_cast<size_type>(std::distance(__first, __last));
     if (__n > 0)
     {
         __vallocate(__n);
         __construct_at_end(__first, __last);
     }
     __guard.__complete();
 }
 
 template <class _Allocator>
 template <class _ForwardIterator>
 _LIBCPP_CONSTEXPR_SINCE_CXX20
 vector<bool, _Allocator>::vector(_ForwardIterator __first, _ForwardIterator __last, const allocator_type& __a,
                                 typename enable_if<__is_cpp17_forward_iterator<_ForwardIterator>::value>::type*)
     : __begin_(nullptr),
       __size_(0),
       __cap_alloc_(0, static_cast<__storage_allocator>(__a))
 {
-    auto __guard = std::__make_transaction(__destroy_vector(*this));
+    auto __guard = std::__make_exception_guard(__destroy_vector(*this));
     size_type __n = static_cast<size_type>(std::distance(__first, __last));
     if (__n > 0)
     {
         __vallocate(__n);
         __construct_at_end(__first, __last);
     }
     __guard.__complete();
 }

libcxx/test/libcxx/private_headers.verify.cpp

 #include <__type_traits/type_list.h> // expected-error@*:* {{use of private header from outside its module: '__type_traits/type_list.h'}}
 #include <__type_traits/underlying_type.h> // expected-error@*:* {{use of private header from outside its module: '__type_traits/underlying_type.h'}}
 #include <__type_traits/void_t.h> // expected-error@*:* {{use of private header from outside its module: '__type_traits/void_t.h'}}
 #include <__utility/as_const.h> // expected-error@*:* {{use of private header from outside its module: '__utility/as_const.h'}}
 #include <__utility/auto_cast.h> // expected-error@*:* {{use of private header from outside its module: '__utility/auto_cast.h'}}
 #include <__utility/cmp.h> // expected-error@*:* {{use of private header from outside its module: '__utility/cmp.h'}}
 #include <__utility/convert_to_integral.h> // expected-error@*:* {{use of private header from outside its module: '__utility/convert_to_integral.h'}}
 #include <__utility/declval.h> // expected-error@*:* {{use of private header from outside its module: '__utility/declval.h'}}
+#include <__utility/exception_guard.h> // expected-error@*:* {{use of private header from outside its module: '__utility/exception_guard.h'}}
 #include <__utility/exchange.h> // expected-error@*:* {{use of private header from outside its module: '__utility/exchange.h'}}
 #include <__utility/forward.h> // expected-error@*:* {{use of private header from outside its module: '__utility/forward.h'}}
 #include <__utility/forward_like.h> // expected-error@*:* {{use of private header from outside its module: '__utility/forward_like.h'}}
 #include <__utility/in_place.h> // expected-error@*:* {{use of private header from outside its module: '__utility/in_place.h'}}
 #include <__utility/integer_sequence.h> // expected-error@*:* {{use of private header from outside its module: '__utility/integer_sequence.h'}}
 #include <__utility/move.h> // expected-error@*:* {{use of private header from outside its module: '__utility/move.h'}}
 #include <__utility/pair.h> // expected-error@*:* {{use of private header from outside its module: '__utility/pair.h'}}
 #include <__utility/piecewise_construct.h> // expected-error@*:* {{use of private header from outside its module: '__utility/piecewise_construct.h'}}
 #include <__utility/priority_tag.h> // expected-error@*:* {{use of private header from outside its module: '__utility/priority_tag.h'}}
 #include <__utility/rel_ops.h> // expected-error@*:* {{use of private header from outside its module: '__utility/rel_ops.h'}}
 #include <__utility/swap.h> // expected-error@*:* {{use of private header from outside its module: '__utility/swap.h'}}
 #include <__utility/to_underlying.h> // expected-error@*:* {{use of private header from outside its module: '__utility/to_underlying.h'}}
-#include <__utility/transaction.h> // expected-error@*:* {{use of private header from outside its module: '__utility/transaction.h'}}
 #include <__utility/unreachable.h> // expected-error@*:* {{use of private header from outside its module: '__utility/unreachable.h'}}
 #include <__variant/monostate.h> // expected-error@*:* {{use of private header from outside its module: '__variant/monostate.h'}}
 // GENERATED-MARKER

libcxx/test/libcxx/utilities/assert.exception_guard.no_exceptions.pass.cpp

+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// UNSUPPORTED: c++03
+
+// REQUIRES: has-unix-headers
+// XFAIL: use_system_cxx_lib && target={{.+}}-apple-macosx{{10.9|10.10|10.11|10.12|10.13|10.14|10.15|11.0|12.0}}
+// ADDITIONAL_COMPILE_FLAGS: -fno-exceptions -D_LIBCPP_ENABLE_ASSERTIONS
+
+// ADDITIONAL_COMPILE_FLAGS: -Wno-private-header
+
+#include <__utility/exception_guard.h>
+
+#include "check_assertion.h"
+
+int main(int, char**) {
+  TEST_LIBCPP_ASSERT_FAILURE(
+      std::__make_exception_guard([] {}), "__exception_guard not completed with exceptions disabled");
+}

libcxx/test/libcxx/utilities/exception_guard.no_exceptions.pass.cpp

+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// UNSUPPORTED: c++03
+
+// ADDITIONAL_COMPILE_FLAGS: -fno-exceptions -D_LIBCPP_ENABLE_ASSERTIONS
+
+#include <utility>
+
+int main(int, char**) {
+  auto guard = std::__make_exception_guard([] {});
+  auto guard2 = std::move(guard);
+  guard2.__complete();
+}

libcxx/test/libcxx/utilities/exception_guard.pass.cpp

 //===----------------------------------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 // UNSUPPORTED: c++03
 
-#include <utility> // for __transaction
+// UNSUPPORTED: no-exceptions
+
 #include <cassert>
 #include <type_traits>
 #include <utility>
 
 #include "test_macros.h"
 
 TEST_CONSTEXPR_CXX20 bool test() {
     // Make sure the transaction is rolled back if it is not marked as complete when
     // it goes out of scope.
     {
         bool rolled_back = false;
         {
             auto rollback = [&] { rolled_back = true; };
-            std::__transaction<decltype(rollback)> t(rollback);
+            std::__exception_guard<decltype(rollback)> g(rollback);
         }
         assert(rolled_back);
     }
 
     // Make sure the transaction is not rolled back if it is marked as complete when
     // it goes out of scope.
     {
         bool rolled_back = false;
         {
             auto rollback = [&] { rolled_back = true; };
-            std::__transaction<decltype(rollback)> t(rollback);
-            t.__complete();
+            std::__exception_guard<decltype(rollback)> g(rollback);
+            g.__complete();
         }
         assert(!rolled_back);
     }
 
     // Make sure that we will perform the right number of rollbacks when a transaction has
     // been moved around
     {
         // When we don't complete it (exactly 1 rollback should happen)
         {
             int rollbacks = 0;
             {
                 auto rollback = [&] { ++rollbacks; };
-                std::__transaction<decltype(rollback)> t(rollback);
-                auto other = std::move(t);
+                std::__exception_guard<decltype(rollback)> g(rollback);
+                auto other = std::move(g);
             }
             assert(rollbacks == 1);
         }
 
         // When we do complete it (no rollbacks should happen)
         {
             int rollbacks = 0;
             {
                 auto rollback = [&] { ++rollbacks; };
-                std::__transaction<decltype(rollback)> t(rollback);
-                auto other = std::move(t);
+                std::__exception_guard<decltype(rollback)> g(rollback);
+                auto other = std::move(g);
                 other.__complete();
             }
             assert(rollbacks == 0);
         }
     }
 
     // Basic properties of the type
     {
         struct Rollback { void operator()() const { } };
-        using Transaction = std::__transaction<Rollback>;
+        using Transaction = std::__exception_guard<Rollback>;
 
         static_assert(!std::is_default_constructible<Transaction>::value, "");
 
         static_assert(!std::is_copy_constructible<Transaction>::value, "");
         static_assert( std::is_move_constructible<Transaction>::value, "");
 
         static_assert(!std::is_copy_assignable<Transaction>::value, "");
         static_assert(!std::is_move_assignable<Transaction>::value, "");
 
         // Check noexcept-ness of a few operations
         {
             struct ThrowOnMove {
                 ThrowOnMove(ThrowOnMove&&) noexcept(false) { }
                 void operator()() const { }
             };
-            using ThrowOnMoveTransaction = std::__transaction<ThrowOnMove>;
+            using ThrowOnMoveTransaction = std::__exception_guard<ThrowOnMove>;
 
             ASSERT_NOEXCEPT(std::declval<Transaction>().__complete());
             static_assert( std::is_nothrow_move_constructible<Transaction>::value, "");
             static_assert(!std::is_nothrow_move_constructible<ThrowOnMoveTransaction>::value, "");
         }
     }
 
     return true;
 }
 
 void test_exceptions() {
 #ifndef TEST_HAS_NO_EXCEPTIONS
     // Make sure the rollback is performed when an exception is thrown during the
     // lifetime of the transaction.
     {
         bool rolled_back = false;
         auto rollback = [&] { rolled_back = true; };
         try {
-            std::__transaction<decltype(rollback)> t(rollback);
+            std::__exception_guard<decltype(rollback)> g(rollback);
             throw 0;
         } catch (...) { }
         assert(rolled_back);
     }
 
     // Make sure we don't roll back if an exception is thrown but the transaction
     // has been marked as complete when that happens.
     {
         bool rolled_back = false;
         auto rollback = [&] { rolled_back = true; };
         try {
-            std::__transaction<decltype(rollback)> t(rollback);
-            t.__complete();
+            std::__exception_guard<decltype(rollback)> g(rollback);
+            g.__complete();
             throw 0;
         } catch (...) { }
         assert(!rolled_back);
     }
 
-    // Make sure __transaction does not rollback if the transaction is marked as
+    // Make sure __exception_guard does not rollback if the transaction is marked as
     // completed within a destructor.
     {
         struct S {
             explicit S(bool& x) : x_(x) { }
 
             ~S() {
                 auto rollback = [this]{ x_ = true; };
-                std::__transaction<decltype(rollback)> t(rollback);
-                t.__complete();
+                std::__exception_guard<decltype(rollback)> g(rollback);
+                g.__complete();
             }
 
             bool& x_;
         };
 
         bool rolled_back = false;
         try {
             S s(rolled_back);