Skip to content
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

constexpr INVOKE and related utilities #703

Merged
merged 33 commits into from
Jul 3, 2020

Conversation

AdamBucior
Copy link
Contributor

@AdamBucior AdamBucior commented Apr 10, 2020

Resolves #51.

BTW without the checklist PRs feel so empty.

@AdamBucior AdamBucior requested a review from a team as a code owner April 10, 2020 15:50
@StephanTLavavej StephanTLavavej added the cxx20 C++20 feature label Apr 10, 2020
stl/inc/yvals_core.h Outdated Show resolved Hide resolved
stl/inc/yvals_core.h Show resolved Hide resolved
stl/inc/yvals_core.h Show resolved Hide resolved
tests/std/tests/Dev11_0535636_functional_overhaul/test.cpp Outdated Show resolved Hide resolved
stl/inc/functional Outdated Show resolved Hide resolved
stl/inc/functional Outdated Show resolved Hide resolved
stl/inc/functional Outdated Show resolved Hide resolved
stl/inc/functional Outdated Show resolved Hide resolved
stl/inc/type_traits Outdated Show resolved Hide resolved
stl/inc/type_traits Outdated Show resolved Hide resolved
@StephanTLavavej
Copy link
Member

Thanks for the feature! I've exhaustively reviewed the product code but haven't really looked at the test coverage yet; I'll take a look at the tests during the next iteration.

@AdamBucior
Copy link
Contributor Author

BTW shouldn't _Invoker_ret and _Unforced be moved to <functional> if they're used only by std::function and bind()?

@AdamBucior
Copy link
Contributor Author

I don't understand why some of the x86 tests are failing.

@cbezault
Copy link
Contributor

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@StephanTLavavej StephanTLavavej removed their assignment May 30, 2020
@AdamBucior
Copy link
Contributor Author

I think it's ready for initial review

Copy link
Member

@StephanTLavavej StephanTLavavej left a comment

Choose a reason for hiding this comment

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

This looks good! My apologies for taking a month to get back to this. I found a couple of quiet hours to think hard about the changes, and everything appears to be in order. (Not easy to achieve, given the complexity of bind's machinery - I really appreciate your work here.) I'll push changes for some pre-existing/superficial syntactic things I noticed, and a bit more testing for conditionally noexcept bind(), and then I think this will be ready for final review and merge (to ship in VS 2019 16.8 Preview 1 if we can merge this week, otherwise Preview 2).

stl/inc/functional Outdated Show resolved Hide resolved
stl/inc/functional Outdated Show resolved Hide resolved
stl/inc/functional Outdated Show resolved Hide resolved
stl/inc/functional Outdated Show resolved Hide resolved
stl/inc/functional Outdated Show resolved Hide resolved
tests/std/tests/P0356R5_bind_front/test.cpp Show resolved Hide resolved
tests/std/tests/Dev11_0535636_functional_overhaul/test.cpp Outdated Show resolved Hide resolved
tests/std/tests/Dev11_0535636_functional_overhaul/test.cpp Outdated Show resolved Hide resolved
AdamBucior and others added 3 commits July 2, 2020 11:38
Co-authored-by: Stephan T. Lavavej <[email protected]>
* Unwrapping a reference_wrapper is noexcept, but passing
     the unwrapped reference to the callable object
     might involve a possibly throwing conversion.
* Forwarding through a placeholder is noexcept, but passing
     the unbound argument to the callable object
     might involve a possibly throwing conversion.
* Nested bind() needs to sense whether the nested call might throw.

Mark PossiblyThrowingInt(int) as constexpr so we can construct
possibly_throwing_int during constant evaluation;
ref(possibly_throwing_int) is simpler than
declval<reference_wrapper<PossiblyThrowingInt>>().
@StephanTLavavej
Copy link
Member

Mini-changelog for more tests for conditionally noexcept bind():

  • Unwrapping a reference_wrapper is noexcept, but passing the unwrapped reference to the callable object might involve a possibly throwing conversion.
  • Forwarding through a placeholder is noexcept, but passing the unbound argument to the callable object might involve a possibly throwing conversion.
  • Nested bind() needs to sense whether the nested call might throw.

Mark PossiblyThrowingInt(int) as constexpr so we can construct possibly_throwing_int during constant evaluation; ref(possibly_throwing_int) is simpler than declval<reference_wrapper<PossiblyThrowingInt>>().

Copy link
Member

@StephanTLavavej StephanTLavavej left a comment

Choose a reason for hiding this comment

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

There seems to be a totally unrelated infrastructure issue with the arm/arm64 CI builds that we'll need to investigate, but I believe this PR is crystalline perfection. If a second reviewer can be equally convinced, I'll try to port this for Preview 1. 😺

Copy link
Member

@CaseyCarter CaseyCarter left a comment

Choose a reason for hiding this comment

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

One style comment, but I'm happy to merge this either way.

stl/inc/functional Show resolved Hide resolved
@StephanTLavavej StephanTLavavej merged commit 98a10bf into microsoft:master Jul 3, 2020
@StephanTLavavej
Copy link
Member

Thanks again for implementing this C++20 feature (over 3% of the remaining features, by paper count!). This will ship in VS 2019 16.8 Preview 1. 😺 😸 🎆

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cxx20 C++20 feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

P1065R2 constexpr INVOKE
5 participants