Skip to content

NFC: make headers compatible with C++20 #67619

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Aug 11, 2023

Conversation

redsun82
Copy link
Contributor

@redsun82 redsun82 commented Jul 31, 2023

In a downstream project we are using the Swift code as a library and compiling with C++20. This mostly works except for two backward incompatibilities introduced by C++20:

  • P1008 disallows aggregate initialization when defaulted or deleted constructors are specified. This lead to a compilation error for aggregate initialization of swift::Compilation::Result. The backward and forward compatible fix for that is to provide a constructor turning aggregate initializations into a normal constructor call.
    • EDIT: this was fixed recently by [Code Health] Improve eventual C++20 support. #67683, so this part of the PR became obsolete, though it was updated to introduce a small optimization of that change using move semantics instead of copy for the pass-by-value depGraph parameter (that ultimately holds two std::unordered_maps) of swift::Compilation::Result's constructor.
  • P1185 introduces more candidates for overload resolution of comparison operator calls. As explained in P1630, this leads in some cases to ambiguity compilation errors in C++20, which is exactly the case with swift::ValueOwnershipKind. The fix in this case is to remove some redundant operator definitions conditionally on the __cpp_impl_three_way_comparison feature test macro, which includes the papers mentioned above.

In a downstream project we are using the Swift code as a library and
compiling with C++20. This mostly works except for two backward
incompatibilities introduced by C++20:

* [P1008] disallows aggregate initialization when defaulted or deleted
  constructors are specified. This lead to a compilation error for
  aggregate initialization of `swift::Compilation::Result`. The backward
  and forward compatible fix for that is to provide a constructor
  turning aggregate initializations into a normal constructor call.
* [P1185] introduces more candidates for overload resolution of
  comparison operator calls. As explained in [P1630], this leads in some
  cases to ambiguity compilation errors in C++20, which is exactly the
  case with `swift::ValueOwnershipKind`. The fix in this case is to
  remove some redundant operator calls conditionally on the
  `__cpp_impl_three_way_comparison` feature test macro, which [includes
  the papers mentioned above][feature_test].

[P1008]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1008r1.pdf
[P1185]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1185r2.html
[P1630]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1630r1.html
[feature_test]: https://en.cppreference.com/w/cpp/feature_test
@redsun82 redsun82 requested a review from artemcm as a code owner July 31, 2023 15:36
@redsun82
Copy link
Contributor Author

@allevato this PR ties to C++20 compatibility that I've seen you have been working on recently, so I think you might be interested in having a look 🙂

@allevato
Copy link
Member

@swift-ci please test

@@ -102,8 +102,7 @@ class Compilation {

/// Construct a \c Compilation::Result from just an exit code.
static Result code(int code) {
return Compilation::Result{false, code,
fine_grained_dependencies::ModuleDepGraph()};
return Compilation::Result{false, code};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the removal of the ModuleDepGraph argument here is causing a compilation failure: https://ci.swift.org/job/swift-PR-macos/10494/console

Does that behave differently under C++20?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, no, this is me not testing the git merge I did 😅 I had default arguments set in the constructor before

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you retest now?

@allevato
Copy link
Member

@swift-ci please test

Copy link
Member

@allevato allevato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix!

@allevato allevato merged commit 9d53f54 into swiftlang:main Aug 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants