This fixes the docstrings on `FutureExt` so that the bias and fairness
notes are correct and consistent in all cases.
All cancellation-related wrappers are biased towards the completion of
the inner future, but they do initially check if the token is
already cancelled at construction time.
This patch fixes an issue where the `CancellationToken::run_until_cancelled` never cancels the `Future` that returns `Ready` at the first `poll`.
---------
Co-authored-by: Luca BRUNO <[email protected]>
# 1.46.1 (July 4th, 2025)
This release fixes incorrect spawn locations in runtime task hooks for tasks
spawned using `tokio::spawn` rather than `Runtime::spawn`. This issue only
effected the spawn location in `TaskMeta::spawned_at`, and did not effect task
locations in Tracing events.
## Unstable
- runtime: add `TaskMeta::spawn_location` tracking where a task was spawned
([#7440)])
[#7440]: https://github.com/tokio-rs/tokio/pull/7440
## Motivation
Unfortunately, due to an oversight on my part, the capturing of spawn
locations was only tested with the `Runtime::spawn` method, and *not*
with `tokio::spawn`/`tokio::task::spawn`, which is how most tasks are
spawned in Real Life. And, it turned out that because this was not
tested...well, it was broken. Agh. My bad.
## Solution
Although the whole call chain for spawning tasks using `tokio::spawn`
was correctly annotated with `#[track_caller]`, the location wasn't
propagated correctly because of the `context::with_current(|handle| {
... })` closure that accesses the current runtime. Because the call to
spawn the task occurs inside a closure, the *closure*'s location is
captured instead of the caller. This means any task spawned by
`tokio::spawn` records its location as being in
`tokio/src/task/spawn.rs`, which is not what we'd like. This commit
fixes that by capturing the spawn location outside the `with_current`
closure and passing it in explicitly.
I've updated the tests to also spawn a task with `tokio::spawn`, so that
we ensure this works correctly.
Motoyuki Kimura