Skip to content

[pull] canary from vercel:canary#1089

Merged
pull[bot] merged 4 commits into
code:canaryfrom
vercel:canary
Jun 1, 2026
Merged

[pull] canary from vercel:canary#1089
pull[bot] merged 4 commits into
code:canaryfrom
vercel:canary

Conversation

@pull
Copy link
Copy Markdown

@pull pull Bot commented Jun 1, 2026

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 : )

icyJoseph and others added 4 commits June 1, 2026 13:42
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
@pull pull Bot locked and limited conversation to collaborators Jun 1, 2026
@pull pull Bot added the ⤵️ pull label Jun 1, 2026
@pull pull Bot merged commit 87ee4fe into code:canary Jun 1, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants