mirror of
https://github.com/hanzoai/next.js.git
synced 2026-10-30 14:46:38 +00:00
### What? Replace the `async fn resolve()`, `async fn resolve_strongly_consistent()`, and `async fn to_resolved()` methods on `RawVc`, `Vc<T>`, and `OperationVc<T>` with hand-written custom `Future` implementations, following the existing `ReadRawVcFuture` pattern. New types: - **`ResolveRawVcFuture`** (`raw_vc.rs`) — core implementation, replaces `async fn resolve_inner()` - **`ResolveVcFuture<T>`** (`vc/mod.rs`) — typed wrapper over `ResolveRawVcFuture`, returned by `Vc::resolve()` - **`ResolveOperationVcFuture<T>`** (`vc/operation.rs`) — typed wrapper, returned by `OperationVc::resolve()` - **`ToResolvedVcFuture<T>`** (`vc/mod.rs`) — typed wrapper, returned by `Vc::to_resolved()` All new future types expose a `.strongly_consistent()` builder method, enabling `resolve_strongly_consistent()` to be replaced by `.resolve().strongly_consistent()` at call sites. `ReadRawVcFuture` is also updated to delegate its phase-1 resolve loop to `ResolveRawVcFuture` instead of duplicating the logic. `std::task::ready!` is used throughout to simplify poll implementations. Also adds `#[inline(never)]` to `ReadRawVcFuture::poll` and `ResolveRawVcFuture::poll` to avoid inlining large poll implementations into every await site. ### Why? Performance, binary size, and improved API ergonomics: - The hand-written `Future` pattern (already used by `ReadRawVcFuture`) gives the compiler more predictable, smaller code than the state machines generated for `async fn`. The `#[inline(never)]` attributes on `poll` prevent large poll bodies from being duplicated at every await site, which the async desugaring otherwise allows. - The new builder API (`.resolve().strongly_consistent()`) is more composable and removes the need for separate `_strongly_consistent` method variants, reducing the number of methods on `RawVc`/`Vc`/`OperationVc`. - Having `ReadRawVcFuture` delegate to `ResolveRawVcFuture` removes the duplicated resolve loop and ensures both paths stay in sync. ### How? - `ResolveRawVcFuture` stores `current: RawVc`, `read_output_options: ReadOutputOptions`, `strongly_consistent: bool`, and `listener: Option<EventListener>`. Its `poll` replicates the loop from the old `resolve_inner` using `try_read_task_output` / `try_read_local_output`. - On `Err(listener)` from a `try_*` call, the listener is stored in `self.listener` and `Poll::Pending` is returned. At the top of the loop, `ready!(poll_listener(...))` re-polls it and short-circuits if still pending. - Consistency is downgraded to `Eventual` after the first `TaskOutput` hop, matching the previous behavior. - `strongly_consistent: true` keeps the `SUPPRESS_EVENTUAL_CONSISTENCY_TOP_LEVEL_TASK_CHECK` suppression across all polls (same logic as `ReadRawVcFuture`). - `ReadRawVcFuture` now holds a `ResolveRawVcFuture` for phase 1 and drives it via `Pin::new(&mut self.resolve).poll(cx)` before proceeding to the cell read in phase 2. This eliminates the duplicated loop that previously existed in both types. - Typed wrappers (`ResolveVcFuture<T>`, `ResolveOperationVcFuture<T>`, `ToResolvedVcFuture<T>`) delegate `poll` to the inner `ResolveRawVcFuture` and map the output to the appropriate typed result. - `OperationVc::resolve_strongly_consistent()` is removed; 16 call sites updated to `.resolve().strongly_consistent()`. - All new types implement `Unpin` and are exported from `lib.rs`. - `std::task::ready!` is used in all `poll` implementations to reduce boilerplate. No behavioral changes — this is a pure implementation refactor. ### Binary size impact A release build (`pnpm swc-build-native --release`) was measured before and after the branch changes on the same merge-base commit (`a41bef94`): | | Size | |---|---| | Base (`a41bef94`, before branch) | 199,690,656 bytes (~190.4 MB) | | Branch (`6f7846f9`, after changes) | 199,252,384 bytes (~190.0 MB) | | **Difference** | **−438,272 bytes (−428 KB, −0.22%)** | The branch produces a slightly smaller binary. The reduction comes primarily from the `#[inline(never)]` attributes preventing large `poll` bodies from being duplicated at every await site. --------- Co-authored-by: Tobias Koppers <[email protected]> Co-authored-by: Claude <[email protected]>
92 lines
2.7 KiB
Rust
92 lines
2.7 KiB
Rust
#![feature(arbitrary_self_types)]
|
|
#![feature(arbitrary_self_types_pointers)]
|
|
#![allow(clippy::needless_return)] // tokio macro-generated code doesn't respect this
|
|
|
|
use anyhow::Result;
|
|
use turbo_tasks::{
|
|
Vc, mark_top_level_task, unmark_top_level_task_may_leak_eventually_consistent_state,
|
|
};
|
|
use turbo_tasks_testing::{Registration, register, run_once};
|
|
|
|
static REGISTRATION: Registration = register!();
|
|
|
|
#[turbo_tasks::value]
|
|
#[derive(Clone, Debug)]
|
|
struct Value {
|
|
value: u32,
|
|
}
|
|
|
|
#[turbo_tasks::function(operation)]
|
|
async fn returns_value_operation() -> Result<Vc<Value>> {
|
|
Ok(Value { value: 42 }.cell())
|
|
}
|
|
|
|
/// Test that eventually consistent reads (default .await) cause an error in top-level tasks
|
|
/// The panic happens but we just verify it's an error, not the exact message
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
|
#[should_panic]
|
|
async fn test_eventual_read_in_top_level_task_fails() {
|
|
run_once(®ISTRATION, || async {
|
|
// This should fail because we're in a top-level task (run_once)
|
|
// and doing an eventually consistent read (default .await)
|
|
returns_value_operation().connect().await
|
|
})
|
|
.await
|
|
.unwrap()
|
|
}
|
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
|
async fn test_cell_read_in_top_level_task_succeeds() {
|
|
run_once(®ISTRATION, || async {
|
|
let cell = returns_value_operation()
|
|
.resolve()
|
|
.strongly_consistent()
|
|
.await?;
|
|
let value = cell.await?;
|
|
assert_eq!(value.value, 42);
|
|
Ok(())
|
|
})
|
|
.await
|
|
.unwrap()
|
|
}
|
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
|
async fn test_manual_mark_unmark_top_level_task() {
|
|
run_once(®ISTRATION, || async {
|
|
// We're in a top-level task initially, but let's unmark it
|
|
unmark_top_level_task_may_leak_eventually_consistent_state();
|
|
|
|
// Now eventually consistent reads should work
|
|
let value = returns_value_operation().connect().await?;
|
|
assert_eq!(value.value, 42);
|
|
|
|
// Re-mark as top-level task
|
|
mark_top_level_task();
|
|
|
|
anyhow::Ok(())
|
|
})
|
|
.await
|
|
.unwrap()
|
|
}
|
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
|
#[should_panic]
|
|
async fn test_manual_mark_top_level_task_causes_error() {
|
|
#[turbo_tasks::function(operation)]
|
|
async fn operation() -> Result<Vc<Value>> {
|
|
// Manually mark as top-level task
|
|
mark_top_level_task();
|
|
|
|
// This should panic because we marked it as a top-level task
|
|
returns_value_operation().connect().await?;
|
|
|
|
Ok(Value { value: 42 }.cell())
|
|
}
|
|
|
|
run_once(®ISTRATION, || async {
|
|
operation().read_strongly_consistent().await
|
|
})
|
|
.await
|
|
.unwrap()
|
|
}
|