make_future: drop static_assert from detail::make_future

[guptapratykshh]

Proposed Changes

• Drop the sender_completion_is_run_loop_scheduler trait and the static_assert added inside detail::make_future(Sender, Allocator) by make_future: static_assert against silent-hang run_loop_scheduler sender #7248. They were intended to catch make_future(sender) calls whose set_value completion scheduler is run_loop_scheduler (1-arg overload would silently hang because future_data has no loop.run() driver), but the static_assert is a hard error during template substitution, not a SFINAE-friendly constraint, so it breaks tag_priority's overload-resolution probing on GCC 12 debug.
• Add an explanatory comment in detail::make_future pointing at the actual silent-hang protection: the public make_future CPO's tag_override_invoke overload already routes make_future(run_loop_sender) to the scheduler-form tag_invoke, which builds future_data_with_run_loop and drives loop.run() in execute_deferred.

Any background context you want to provide?

Checklist

Not all points below apply to all pull requests.

• I have added a new feature and have added tests to go along with it.
• I have fixed a bug and have added a regression test.
• I have added a test using random numbers; I have made sure it uses a seed, and that random numbers generated are valid inputs for the tests.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[StellarBot]

Can one of the admins verify this patch?

[Copilot]

Pull request overview

This PR removes a non-SFINAE-friendly static_assert (and its helper trait) from detail::make_future(Sender, Allocator) that was introduced to prevent a known runtime hang for run-loop scheduled senders, and replaces it with an explanatory comment. The PR relies on the public make_future CPO’s existing tag_override_invoke routing to ensure run-loop completion schedulers are handled by the scheduler-form overload that drives loop.run().

Changes:

• Removed sender_completion_is_run_loop_scheduler and the static_assert in detail::make_future(Sender, Allocator) that could break GCC 12 debug due to template probing/instantiation.
• Added a comment explaining why the compile-time guard is not present in the fallback and where the actual run-loop driving behavior is implemented.