-
Notifications
You must be signed in to change notification settings - Fork 17
Work around clang issue #201
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR implements workarounds for a clang compiler issue by modifying the prop deduction guide and refactoring the affine_on implementation to avoid problematic code patterns.
Changes:
- Modified the
propdeduction guide to accept an additionalnon_assignableparameter with a default value - Introduced a new
ao_envhelper struct to replace the combination ofjoin_envandenv{prop{...}} - Renamed the
envparameter toevintransform_senderto avoid naming conflicts with theenvtemplate
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| include/beman/execution/detail/prop.hpp | Updated deduction guide to include third parameter for workaround |
| include/beman/execution/detail/affine_on.hpp | Added ao_env helper struct and refactored code to avoid clang issues |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| #else | ||
| if constexpr (::beman::execution::detail::nested_sender_has_affine_on<Sender, Env>) | ||
| #endif | ||
| { |
Copilot
AI
Jan 18, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Creating a constexpr local variable t and then immediately using it to call affine_on is unusual. If this is a workaround for a clang issue, consider adding a comment explaining why this intermediate variable is necessary instead of directly using child_tag_t{}.affine_on(...) as was done previously.
| { | |
| { | |
| // NOTE: Some compilers (e.g. certain Clang versions) have had issues | |
| // when invoking affine_on on a temporary, i.e. child_tag_t{}.affine_on(...). | |
| // Using a named constexpr instance here avoids those issues; do not | |
| // simplify back to a temporary without re-validating compiler support. |
| ::beman::execution::env{::beman::execution::prop{::beman::execution::get_stop_token, | ||
| ::beman::execution::never_stop_token{}}}, | ||
| ::beman::execution::env{::beman::execution::prop{ | ||
| ::beman::execution::get_stop_token, ::beman::execution::never_stop_token{}, {}}}, |
Copilot
AI
Jan 18, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The third parameter {} is passed explicitly to the prop constructor even though the deduction guide provides a default value for the non_assignable parameter. If the default value works correctly, this explicit {} may be unnecessary. Consider removing it to simplify the code and rely on the default parameter, or add a comment explaining why the explicit parameter is required.
| ::beman::execution::get_stop_token, ::beman::execution::never_stop_token{}, {}}}, | |
| ::beman::execution::get_stop_token, ::beman::execution::never_stop_token{}}}, |
|
|
||
| template <typename Query, typename Value> | ||
| prop(Query, Value) -> prop<Query, ::std::unwrap_reference_t<Value>>; | ||
| prop(Query, Value, ::beman::execution::detail::non_assignable = {}) -> prop<Query, ::std::unwrap_reference_t<Value>>; |
Copilot
AI
Jan 18, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The deduction guide now requires passing an extra parameter (the non_assignable object with default value) that doesn't correspond to a user-provided value. While this may work around a clang issue, this creates an inconsistency where users of prop must now be aware of this implementation detail. Consider whether this is the intended workaround, as it exposes the internal non_assignable_ member in the public API of the deduction guide.
No description provided.