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

Fix bugprone-move-forwarding-reference violations #551

Merged
merged 3 commits into from
Jul 6, 2023

Conversation

ccotter
Copy link
Contributor

@ccotter ccotter commented Jul 5, 2023

No description provided.

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jul 5, 2023
}
});
}

template <typename E>
void set_error(E e) noexcept {
complete([&](auto&& receiver) noexcept {
unifex::set_error(std::move(receiver), std::move(e));
unifex::set_error(std::forward<decltype(receiver)>(receiver), std::move(e));
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is semi debatable. In the letter of the law (the law being CppCoreGuidelines F.19 checked by bugprone-move-forwarding-reference, this should use a forward. I think receivers usually or always are passed by rvalue reference within the set_error CPO, but if someone somehow ends up trying to pass an lvalue ref to a receiver that does or doesn't accept by lvalue ref on the receiver, this code is not taking an opinion on way or the other - the bug would be elsewhere.

Copy link
Contributor

Choose a reason for hiding this comment

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

complete is defined below, on line 285, and it always passes the operation's Receiver by rvalue reference. This auto&& is just saving characters. Perhaps a better way to silence the linter here is to spend the characters and type out Receiver&&.

@ccotter
Copy link
Contributor Author

ccotter commented Jul 5, 2023

Note, I chose to use forward instead of static_cast<T&&> since one of the places I changed already used forward. Since #548 notes that newer version of clang address the downsides to using move and forward, perhaps we would want to go ahead and use forward throughout to take advantage of clang-tidy's checks on the semantics of moving and forwarding? Happy to stick with static_cast<T&&> - just let me know.

Copy link
Contributor

@ispeters ispeters left a comment

Choose a reason for hiding this comment

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

Comparing the build times on this PR's CI to those on #552, it looks like switching to std::forward<>() isn't very expensive; comparable runs vary by about +/- 30 seconds in both directions. We may as well switch—std::forward<>() conveys intent better than some arbitrary static_cast.

Please just update the lambdas passed to complete not to take auto&& so we can stick with std::move() instead of silencing the linter with an over-general std::forward<>().

}
});
}

template <typename E>
void set_error(E e) noexcept {
complete([&](auto&& receiver) noexcept {
unifex::set_error(std::move(receiver), std::move(e));
unifex::set_error(std::forward<decltype(receiver)>(receiver), std::move(e));
Copy link
Contributor

Choose a reason for hiding this comment

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

complete is defined below, on line 285, and it always passes the operation's Receiver by rvalue reference. This auto&& is just saving characters. Perhaps a better way to silence the linter here is to spend the characters and type out Receiver&&.

@ispeters
Copy link
Contributor

ispeters commented Jul 6, 2023

I can't figure out how to squash this nicely from my phone. I'll merge it once the kids are in bed.

@ispeters ispeters merged commit 2d1ba75 into facebookexperimental:main Jul 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants