[libcxx] Updated test and seemingly incorrect comment from it.

[oontvoo]

Summary

Background: https://reviews.llvm.org/D82490#inline-1007741

[mstorsjo]

Thanks! Looks great to me, assuming that it passes CI.

[ldionne]

CI never lies :-)

Let's figure out what's going on here.

[mstorsjo]

libcxx/test/libcxx/memory/trivial_abi/unique_ptr_destruction_order.pass.cpp

60

There's two trivial typos here, the second one is shared[1] when it should be shared_buf[1], and the third index should be [2], not [1] again.

[oontvoo]

fixed typos

[ldionne]

The arm64 job failed due to a fluke. I restarted it, please ship it once it passes (check again in 15 minutes or so).

[oontvoo]

In D106092#2883805, @ldionne wrote:

The arm64 job failed due to a fluke. I restarted it, please ship it once it passes (check again in 15 minutes or so).

Hmm, this[0] showed that libcxx CI is PASSED, but the build status above still showed that`libcxx CI (MacOS arm64)` is red.
Safe to assume it's fine to commit?

[0] https://buildkite.com/llvm-project/libcxx-ci/builds/4326

[mstorsjo]

In D106092#2884999, @oontvoo wrote:

In D106092#2883805, @ldionne wrote:

The arm64 job failed due to a fluke. I restarted it, please ship it once it passes (check again in 15 minutes or so).

Hmm, this[0] showed that libcxx CI is PASSED, but the build status above still showed that`libcxx CI (MacOS arm64)` is red.
Safe to assume it's fine to commit?

[0] https://buildkite.com/llvm-project/libcxx-ci/builds/4326

Yes, that should be fine now - thanks!

[oontvoo]

rebase

[oontvoo]

Thanks!

libcxx/test/libcxx/memory/trivial_abi/unique_ptr_destruction_order.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
 //
 //===----------------------------------------------------------------------===//
 
 // <memory>
 
 // Test arguments destruction order involving unique_ptr<T> with trivial_abi.
-// Note: Unlike other tests in this directory, this is the only test that
-// exhibits a difference between the two modes in Microsft ABI.
 
 // ADDITIONAL_COMPILE_FLAGS: -D_LIBCPP_ABI_ENABLE_UNIQUE_PTR_TRIVIAL_ABI
 
 // There were assertion failures in both parse and codegen, which are fixed in clang 11.
 // UNSUPPORTED: gcc, clang-4, clang-5, clang-6, clang-7, clang-8, clang-9, clang-10
 
-// XFAIL: LIBCXX-WINDOWS-FIXME
 
 #include <memory>
 #include <cassert>
 
 __attribute__((noinline)) void call_something() { asm volatile(""); }
 
 struct Base {
   char* shared_buff;

 
 int main(int, char**) {
   char shared_buf[3] = {'0', '0', '0'};
   int cur_idx = 0;
 
   func(A(shared_buf, &cur_idx), std::unique_ptr<B>(new B(shared_buf, &cur_idx)),
        C(shared_buf, &cur_idx));
 
+#if defined(_LIBCPP_ABI_MICROSOFT)
+  // On Microsoft ABI, the dtor order is always A,B,C (because callee-destroyed)
+  assert(shared_buf[0] == 'A' && shared_buf[1] == 'B' && shared_buf[2] == 'C');
+#else
   // With trivial_abi, the std::unique_ptr<B> arg is always destructed first.
   assert(shared_buf[0] == 'B');
+#endif
   return 0;
 }