Temporary sender in `transform_sender` may dangle
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
Línea de trabajo
Comienza en el punto de entrada __transform_sender mostrado en el issue y compara el tratamiento de su categoría de retorno con la redacción del borrador enlazado de exec.transform. Determina cómo deben conservarse los resultados prvalue de transform_sender y de los adaptadores de sender sin devolver una referencia a un temporal; se considerará terminado cuando la semántica de la implementación y de la especificación esté resuelta.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
transform_sender is defined like this:
struct __transform_sender {
template <class _Self = __transform_sender, class _Domain, class _Sender, class... _Env>
STDEXEC_ATTRIBUTE((always_inline))
/*constexpr*/
decltype(auto)
operator()(_Domain __dom, _Sender&& __sndr, const _Env&... __env) const
noexcept(__nothrow_callable<__transform_sender_1, _Domain, _Sender, const _Env&...>) {
using _Sender2 = __call_result_t<__transform_sender_1, _Domain, _Sender, const _Env&...>;
// If the transformation doesn't change the sender's type, then do not
// apply the transform recursively.
if constexpr (__decay_same_as<_Sender, _Sender2>) {
return __transform_sender_1()(__dom, static_cast<_Sender&&>(__sndr), __env...);
} else {
// We transformed the sender and got back a different sender. Transform that one too.
return _Self()(
__dom,
__transform_sender_1()(__dom, static_cast<_Sender&&>(__sndr), __env...),
__env...);
}
}
};
In general it takes care to "perfectly backward" the value category of any custom transform_sender implementation it calls by using decltype(auto).
But I think there is a lifetime bug in the last else clause. What happens if the return value of __transform_sender_1 is a prvalue? This is given as an argument to the call _Self()(...) and therefore materializes as an xvalue. Thus, _Self()(...) possibly returns a xvalue as well, as inside, it cannot distinguish between xvalue and prvalue. But now we are returning a reference to a temporary! Shouldn't the "prvalue-ness" of the return value of __transform_sender_1 be "perfectly backwarded" with something like this:
if constexpr (std::is_reference_v<decltype(__transform_sender_1()(
__dom, static_cast<_Sender&&>(__sndr), __env...))>) {
return _Self()(
__dom,
__transform_sender_1()(__dom, static_cast<_Sender&&>(__sndr), __env...),
__env...);
} else {
return auto(_Self()(
__dom,
__transform_sender_1()(__dom, static_cast<_Sender&&>(__sndr), __env...),
__env...));
}
This is the relevant place in the draft: https://eel.is/c++draft/exec#snd.transform-1
Let transformed-sndr be the expression dom.transform_sender(std::forward(sndr), env...)
if that expression is well-formed; otherwise, default_domain().transform_sender(std::forward(sndr), env...)
Let final-sndr be the expression transformed-sndr if transformed-sndr and sndr have the same type ignoring cv-qualifiers; otherwise, it is the expression transform_sender(dom, transformed-sndr, env...).
I think it should say something like:
Let transformed-sndr be the expression dom.transform_sender(std::forward(sndr), env...)
if that expression is well-formed; otherwise, default_domain().transform_sender(std::forward(sndr), env...)
Let final-sndr be the expression transformed-sndr if transformed-sndr and sndr have the same type ignoring cv-qualifiers; otherwise, it is the expression auto(transform_sender(dom, transformed-sndr, env...)) if transformed-sndr is a prvalue, and transform_sender(dom, transformed-sndr, env...) otherwise.
Also, in the sender adaptors like https://eel.is/c++draft/exec#then-3 for example, it should probably say auto(transform_sender(get-domain-early(sndr), make-sender(then-cpo, f, sndr))), right? make-sender is a prvalue, and this should be preserved.
- Lenguaje dominante
- C++
- Estrellas
- 2.4k
- Forks
- 270
- Merge medio
- 2 d 17 h
- PR fusionados (30 d)
- 37
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de NVIDIA/stdexec
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 66/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 74/100
Todos los issues de NVIDIA/stdexec
Issues similares
-
ai_reviewed
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
ydb-platform/ydb#53869 · 3 comentarios ·
-
bug cert blocker needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
project-chip/connectedhomeip#74373 ·
-
[request] tracy/0.14.1 Abiertoupstream update
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
conan-io/conan-center-index#31035 ·
-
Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
vllm-project/vllm-ascend#17329 ·