let_value, _error, & _stopped: Check Invocation Noexceptness With Cor…#1712
Merged
ericniebler merged 1 commit intoNVIDIA:mainfrom Dec 15, 2025
Merged
Conversation
…rect Value Category After the delivery of a completion signal which ought to be intercepted let_value, let_error, and let_stopped perform a "bind" operation. The intercepted values (if any) are stored within the operation state and then the invocable used to parameterize the operation is invoked to obtain a new sender which is then connected and started. If it's the case that: - Decay-copying the intercepted values does not throw, - Invoking the invocable does not throw, and - Connecting the obtained sender does not throw Then the bind operation doesn't throw. In this case there's no need to wrap that operation in a try/catch and emit the emission of an error completion signal from the catch block. Prior to this commit when checking the second bullet above the implementations of let_value, let_error, and let_stopped checked for invocability with the value category by which the values were provided by the predecessor operation. The invocation actually takes place with the stored, decay-copied versions of these values. This meant that if the provided invocable had multiple overloads of its function call operator with different noexcept specifications the implementation could proceed as if no exception could be thrown when this was not the case leading to an exception propagating into noexcept and std::terminate being called. Reproduced in a unit test and fixed.
Collaborator
|
/ok to test ef03f7b |
Collaborator
|
nice find. thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…rect Value Category
After the delivery of a completion signal which ought to be intercepted let_value, let_error, and let_stopped perform a "bind" operation. The intercepted values (if any) are stored within the operation state and then the invocable used to parameterize the operation is invoked to obtain a new sender which is then connected and started. If it's the case that:
Then the bind operation doesn't throw. In this case there's no need to wrap that operation in a try/catch and emit the emission of an error completion signal from the catch block.
Prior to this commit when checking the second bullet above the implementations of let_value, let_error, and let_stopped checked for invocability with the value category by which the values were provided by the predecessor operation. The invocation actually takes place with the stored, decay-copied versions of these values. This meant that if the provided invocable had multiple overloads of its function call operator with different noexcept specifications the implementation could proceed as if no exception could be thrown when this was not the case leading to an exception propagating into noexcept and std::terminate being called.
Reproduced in a unit test and fixed.