[pull] canary from vercel:canary#1089
Merged
Merged
Conversation
Started from #93989 Noticed we even have a test helper to account for overhead: https://github.com/vercel/next.js/blob/fa4c0def823447e75366153690abeda79c7c4ec2/test/e2e/app-dir/actions/account-for-overhead.js#L1-L11 Let's document that the flag controls the raw http body size, overhead + data
### What?
Updates the `ctor` crate dependency from `0.10` to `1.0.6` in the
workspace and migrates the two call sites to the new API.
### Why?
We've been running into a rust-analyzer issue with `ctor` 0.10 that the
newer release looks like it should fix. While bumping, the major version
jump also brings in a number of stability and safety improvements
(post-libc-init default priority, required `unsafe` marker, declarative
re-export form, expanded platform support).
### How?
`ctor` 1.x has several breaking changes that affect us:
1. **`#[ctor]` now requires an explicit `unsafe` marker.** Both call
sites were updated:
- `turbopack/crates/turbo-tasks-macros-tests/tests/trybuild.rs`:
`#[ctor::ctor]` → `#[ctor::ctor(unsafe)]`. The function body already
wraps `std::env::remove_var` in `unsafe`, so no further change was
needed.
- `turbopack/crates/turbo-tasks-macros/src/value_impl_macro.rs`: the
proc-macro emits a vtable registration ctor for every
`#[turbo_tasks::value_impl]`. Migrated to the new declarative form (see
next bullet).
2. **`crate_path = ...` is deprecated in favor of
`ctor::declarative::ctor!`.** The ctor 1.0.6 docs explicitly recommend
the declarative macro for crates that re-export ctor (`turbo-tasks`
re-exports it via `macro_helpers::ctor` so user crates don't need a
direct dep). The emission in `value_impl_macro.rs` was rewritten from
```rust
#[turbo_tasks::macro_helpers::ctor::ctor(
crate_path = turbo_tasks::macro_helpers::ctor,
)]
#[allow(non_snake_case)]
fn #vtable_register_ident() { ... }
```
to
```rust
turbo_tasks::macro_helpers::ctor::declarative::ctor! {
#[ctor(unsafe)]
#[allow(non_snake_case)]
fn #vtable_register_ident() { ... }
}
```
3. **Default priority changed.** In 0.x the default priority was `0`
(run before C library init); in 1.x the default is `default` (≈500,
after libc init). We don't specify a priority, and the registration
ctors only push into a `Vec` guarded by a registry — they don't touch
libc — so the later timing is safe and we accept the new default. The
lazy `VTableRegistry::finalize` step (driven by the `VALUES` `LazyLock`)
is unchanged, so visible ordering semantics for downstream code are
preserved.
4. **Other 1.x breaking changes verified as non-issues for this repo:**
- `dtor` was split into its own crate — not used here.
- `priority = naked` syntax removed — not used.
- MSRV bumps: base is 1.60, only the optional `priority` feature
requires 1.85 — we don't enable `priority`.
- `used_linker` / `no_warn_on_missing_unsafe` were replaced by `--cfg
linktime_*` flags — neither was used here.
#### Verification
- `cargo check` / `cargo clippy` clean across `turbo-tasks`,
`turbo-tasks-backend`, `turbo-tasks-macros`, `turbo-tasks-macros-tests`,
and `turbopack-tests`.
- `cargo test -p turbo-tasks-backend`: all tests pass (58 in the largest
suite, 0 failures across all integration tests, 0 doc-test failures).
- `cargo test -p turbopack-tests`: 218 + 87 tests pass, 0 failures, 1
ignored.
#### Lockfile changes
`Cargo.lock` reflects the new dep graph: `ctor` jumps to `1.0.6`,
`link-section` to `0.17.2`, a new `linktime-proc-macro` is pulled in,
and the old `ctor-proc-macro` / `dtor` / `dtor-proc-macro` entries are
dropped (they were transitive deps of `ctor` 0.10).
<!-- NEXT_JS_LLM_PR -->
Co-authored-by: v-work-app[bot] <262237222+v-work-app[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Tobias Koppers <sokra@users.noreply.github.com>
… example (#93961) ### What? When the Turbopack trace server starts (via `next internal trace <file>`), it prints a hint suggesting users run `next internal query-trace --help` from another terminal. That suggestion doesn't include the actual MCP port the server is listening on, so anyone who copies it verbatim ends up querying the default port (`5748`) — which is wrong as soon as the server picked a non-default `--mcp-port`. This PR threads the running MCP port into both the startup hint and the `query-trace --help` output so the suggested command lines target the server that's actually running. Before: ``` Trace file opened Turbopack trace server started. View trace at https://trace.nextjs.org?port=5750 Query this trace from the command line: next internal query-trace --help Alternatively, connect an MCP client to http://127.0.0.1:5751/mcp ``` After: ``` Trace file opened Turbopack trace server started. View trace at https://trace.nextjs.org?port=5750 Query this trace from the command line: next internal query-trace --help --port 5751 Alternatively, connect an MCP client to http://127.0.0.1:5751/mcp ``` And `next internal query-trace --help --port 5751` now ends with: ``` Example: next internal query-trace --port 5751 --parent <id> ``` ### Why? The MCP HTTP port is dynamic (defaults to `wsPort + 1`, and `--mcp-port` can override it). Without echoing it into the hint, the suggested follow-up command silently connects to the wrong port and the user gets a confusing "Could not connect to trace server on port 5748" error instead of a useful response. Surfacing the right `--port` value at the point the user copies the command keeps the discovery flow self-consistent. ### How? - `packages/next/src/cli/internal/turbo-trace-server.ts`: the startup hint now interpolates the actual `httpPort` the MCP server bound to, so it prints `next internal query-trace --help --port <httpPort>`. - `packages/next/src/bin/next.ts`: the `query-trace` command gains an `.addHelpText('after', …)` block that reads the parsed `--port` option (falling back to the default `5748`) and appends an `Example:` section using that value. Passing `--port <port>` alongside `--help` therefore produces an immediately-runnable example for that specific server. The `--port` CLI option itself, its default, and parsing/validation are unchanged. ### Verification Built `next` and ran: - `next internal query-trace --help` → example shows `--port 5748` (default). - `next internal query-trace --help --port 5751` → example shows `--port 5751`. - `next internal query-trace --port 5751 --help` → example shows `--port 5751`. The existing `test/e2e/turbopack-trace-server-query/turbopack-trace-server.test.ts` suite still matches the substrings it asserts on (`next internal trace <file>` and `next internal query-trace --help`). <!-- NEXT_JS_LLM_PR --> Co-authored-by: v-work-app[bot] <262237222+v-work-app[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Tobias Koppers <sokra@users.noreply.github.com>
Refactor the module-graph bit of NFT so that we can provide `Endpoint.traced_files()` which is needed for the bundle analyzer There should be no logic change whatsoever
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )