See the bugfix #816. After that change, we'll have 8 occurrences of the exact same pattern:
|
if (_Results._Complete()) {
|
|
return _Cancellation_status::_Canceled;
|
|
}
|
|
|
|
const auto _Key = _Team._Get_next_key();
|
|
if (!_Key) {
|
|
return _Cancellation_status::_Canceled;
|
|
}
|
(
_Static_partitioned_mismatch2::_Process_chunk() is very slightly different, testing
_Results._Storage._Complete().)
Trying to centralize this pattern into a helper function ended up degrading codegen, so it remains repeated. We should consider adding a comment to each occurrence, mentioning the surprisingly subtle control flow here. I don't immediately know what it should say - perhaps a high-level explanation that we have to check _Complete() before calling _Get_next_key() because if we successfully obtain a _Key, we're responsible for reporting its result and can't simply drop that work on the floor.
See the bugfix #816. After that change, we'll have 8 occurrences of the exact same pattern:
STL/stl/inc/execution
Lines 1291 to 1298 in 11150ca
(
_Static_partitioned_mismatch2::_Process_chunk()is very slightly different, testing_Results._Storage._Complete().)Trying to centralize this pattern into a helper function ended up degrading codegen, so it remains repeated. We should consider adding a comment to each occurrence, mentioning the surprisingly subtle control flow here. I don't immediately know what it should say - perhaps a high-level explanation that we have to check
_Complete()before calling_Get_next_key()because if we successfully obtain a_Key, we're responsible for reporting its result and can't simply drop that work on the floor.