[libc++] Add default copy ctor to "__chrono/exception.h"

[zeroomega]

After PR#90394, "__chrono/exception.h" will trigger "deprecated-copy-with-user-provided-dtor" warning on Windows x64 runtime testing with ToT Clang. This patch addresses this issue by explicitly adding those default copy ctors.

It is a bit weird that the same warning will not happen when testing on Linux x64 under the same condition, despite the warning flag was enabled (with -Wdeprecated-copy -Wdeprecated-copy-dtor). It might be a bug.

[llvmbot]

@llvm/pr-subscribers-libcxx

Author: Haowei (zeroomega)

Changes

After PR#90394, "__chrono/exception.h" will trigger "deprecated-copy-with-user-provided-dtor" warning on Windows x64 runtime testing with ToT Clang. This patch addresses this issue by explicitly adding those default copy ctors.

It is a bit weird that the same warning will not happen when testing on Linux x64 under the same condition, despite the warning flag was enabled (with -Wdeprecated-copy -Wdeprecated-copy-dtor). It might be a bug.

---

Full diff: https://github.com/llvm/llvm-project/pull/95338.diff

1 Files Affected:

• (modified) libcxx/include/__chrono/exception.h (+6)

diff --git a/libcxx/include/__chrono/exception.h b/libcxx/include/__chrono/exception.h
index 75fd0615b7e08..28ed9ac6ba3b9 100644
--- a/libcxx/include/__chrono/exception.h
+++ b/libcxx/include/__chrono/exception.h
@@ -48,6 +48,9 @@ class nonexistent_local_time : public runtime_error {
                             "creating an nonexistent_local_time from a local_info that is not non-existent");
   }
 
+  nonexistent_local_time(const nonexistent_local_time&) = default;
+  nonexistent_local_time& operator=(const nonexistent_local_time&) = default;
+
   _LIBCPP_AVAILABILITY_TZDB _LIBCPP_EXPORTED_FROM_ABI ~nonexistent_local_time() override; // exported as key function
 
 private:
@@ -89,6 +92,9 @@ class ambiguous_local_time : public runtime_error {
                             "creating an ambiguous_local_time from a local_info that is not ambiguous");
   }
 
+  ambiguous_local_time(const ambiguous_local_time&) = default;
+  ambiguous_local_time& operator=(const ambiguous_local_time&) = default;
+
   _LIBCPP_AVAILABILITY_TZDB _LIBCPP_EXPORTED_FROM_ABI ~ambiguous_local_time() override; // exported as key function
 
 private:

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[ldionne]

I would tend to say this LGTM.

I think this is safe to land once CI is green, and if @mordante thinks this change isn't good we can always revert. I'd normally say "wait for Mark's approval" but I guess this is breaking your roll and in Mark's timezone it may take some time for him to see this, so I'd say go ahead once CI is green.

[zeroomega]

I would tend to say this LGTM.

I think this is safe to land once CI is green, and if @mordante thinks this change isn't good we can always revert. I'd normally say "wait for Mark's approval" but I guess this is breaking your roll and in Mark's timezone it may take some time for him to see this, so I'd say go ahead once CI is green.

Thanks for the code review.

I am looking at the pre-submit checks. There are 2 failures. One is

  llvm-libc++-shared.cfg.in :: /home/runner/_work/llvm-project/llvm-project/build/generic-cxx20/test/libcxx/module_std.gen.py/module_std.sh.cpp
  llvm-libc++-shared.cfg.in :: /home/runner/_work/llvm-project/llvm-project/build/generic-cxx20/test/libcxx/module_std_compat.gen.py/module_std_compat.sh.cpp

This one appeared on other PR as well, e.g. https://github.com/llvm/llvm-project/actions/runs/9504393714/job/26202667672 so I think it is probably unrelated to my change.

The other one:

readelf: Warning: Further warnings about bogus end-of-sibling markers suppressed
readelf: Warning: Unrecognized form: 0x23
readelf: Warning: Unrecognized form: 0x22
readelf: Warning: Unrecognized form: 0x22
readelf: Warning: Unrecognized form: 0x23
readelf: Warning: DIE at offset 0x17d3 refers to abbreviation number 1497 which does not exist
+ false
Error: Process completed with exit code 1.

I am not sure. But I feel my change would be unlikely to cause issues like this.
Is there any ongoing libcxx CI issue that is happening? Do I need to rebase my change against ToT to pick up some potential CI related fixes?

[ldionne]

I am not aware of any ongoing issues with the CI, but I agree this looks really unrelated. Can you try rebasing onto main and giving it another go?

[zeroomega]

I am not aware of any ongoing issues with the CI, but I agree this looks really unrelated. Can you try rebasing onto main and giving it another go?

OK. I just rebased the branch to the ToT. I will see how it goes.

[ldionne]

I think this is good. It passed the relevant C++26 tests. It turns out that there are ongoing CI issues.

I don't think this needs to be blocked until such issues are resolved.