[pull] canary from vercel:canary - #1341
Merged
Merged
Conversation
The value of the argument is actually `Argument | Default value`. Previously, the `take_pat_value` would take it and the recursive `visit_pat` would not see it anymore.
#97805) The `allowedDevOrigins`, and `allowedOrigins` options, behave slightly different to each other, the former drops the PORT, and it is not clear where are these picked up from. This PR improves guidance on how to use these two.
### What?
Makes `turbo-rcstr`'s tagged value work on wasm — and on any target
whose pointer is narrower than the
value — **without changing the representation or the inline capacity on
any target**. `RcStr` stays 8
bytes wide everywhere, `MAX_INLINE_LEN` stays 7 everywhere, and `rcstr!`
stays a `const`.
### Why?
`TaggedValue` stored a `NonNull<()>` on 64-bit but a bare `NonZeroU64`
when
`target_pointer_width = "32"`. `rcstr!` expands to a `const`, so both
constructors must be usable
during const evaluation — and with integer storage `new_ptr` needs a
pointer→integer cast, which
const-eval forbids. Every `rcstr!` taking the static path failed to
compile:
```
error[E0080]: unable to turn pointer into integer
```
Concretely, `cargo check -p turbopack-core --target
wasm32-wasip1-threads` reported **4** of these
before this change and **0** after.
### How?
The fix rests on an asymmetry in const evaluation:
| direction | const-eval | why |
|---|---|---|
| pointer → integer | **forbidden** | a pointer is an abstract
(allocation, offset) pair; its numeric address doesn't exist until the
linker assigns one |
| integer → pointer | allowed | the result carries no provenance, which
is fine as long as it is never dereferenced |
64-bit already only needs the legal directions: `new_ptr` is
pointer→pointer, `new_tag` is
integer→pointer. So rather than narrow the value on other targets, they
now store a struct that keeps
a **real pointer field**:
```rust
#[repr(C, align(8))]
struct RawLittle { ptr: NonNull<()>, pad: [u8; PAD] }
```
`new_ptr` stores the pointer as a pointer; `new_tag` transmutes an
integer into the struct. Reading the
value back as an integer (`get_ptr`, `get_value`, `tag_byte`) only
happens at **run time**, where
pointer→integer is perfectly legal.
Three details are load-bearing, and each has a static assertion:
- **`align(8)`** — a pointer field alone would align the struct to 4 on
wasm32, and reading the value
as a `u64` then traps with `RuntimeError: operation does not support
unaligned accesses`.
- **No padding** — the byte payload is sized to the pointer width,
because padding bytes are
uninitialised and would make the whole-value transmute in `new_tag`
invalid.
- **Endian-dependent field order** — the pointer's least-significant
byte must land where the value's
least-significant byte lives (offset 0 little-endian, last byte
big-endian), since that is where the
tag is read from. Both layouts are declared unconditionally so the
big-endian assertion still
compiles (and was verified to fail when deliberately broken) on a
little-endian host.
A union satisfies both constructors too, but unions carry no niche in
rustc, so `Option<RcStr>` would
grow to 16 bytes. The struct keeps it at 8 — also asserted.
### Testing
- `turbo-rcstr`: **11 passed** on host, **10 passed / 1 ignored** on
`wasm32-wasip1-threads`
(the ignored one needs the static-`RcStr` registry, which depends on the
link-section loader hook).
- Round-trips every `rcstr!` length from 0 to 9 on both targets,
covering both sides of the inline
boundary and the static path.
- Each of the new static assertions was verified to **fail** when
deliberately broken, including the
big-endian layout one.
- `MAX_INLINE_LEN == 7` asserted on host and wasm.
- The five `const … = rcstr!(…)` sites in the tree — including two `pub
const`s in `turbopack-core` —
are untouched and still compile as `const`.
- `atom_size_128` still builds; its pre-existing const limitation is
unchanged and out of scope.
- `cargo fmt --check`, and clippy `-D warnings` for the host and for
`wasm32-wasip1-threads`.
Big-endian and 16-bit are compile-checked and assertion-protected, but
not runtime-exercised — no such
target is available here.
<!-- NEXT_JS_LLM -->
<!-- fleet b6d0486f-97c7-42a7-bdaf-3490774cdec3 -->
Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com>
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
Co-authored-by: Luke Sandberg <210140+lukesandberg@users.noreply.github.com>
### What? Reports HTTP as unsupported on wasm, in the shape of the `reqwest` API `turbo-tasks-fetch` consumes, so the crate compiles for wasm targets. ### Why? `reqwest` cannot serve wasm here. Its only wasm backend targets `wasm32-unknown-unknown` and is built on the browser `fetch` API via `wasm-bindgen`. Under `wasm32-wasip1-threads` that backend is still selected (it keys off `target_arch = "wasm32"`), and it is both API-incompatible (no `ClientBuilder::connect_timeout`, no `ClientBuilder::timeout`, no `Error::is_connect`) and — fatally — **`!Send`**, which `turbo-tasks` requires of every task future. WASI preview1 has no sockets to build a native client on either. ### How? This is deliberately **not** a client and does not pretend to be one: building a client fails immediately with a clear error, so no request is ever attempted, nothing is retried, and no response is ever produced. The remaining types exist only so the shared fetch code type-checks, and the paths that could never be reached say so rather than returning plausible dummy values. The error names the consequence and the alternatives, rather than surfacing as a generic failure: > HTTP requests are not supported in wasm builds of Next.js: this platform has no HTTP client. > Features that fetch at build time, such as `next/font/google`, cannot be used here — self-host the > assets, or use a platform with native Next.js binaries. ### Follow-up Real support needs the **host** to provide HTTP: for wasm builds of the Next.js bindings that means a napi callback into the JS `fetch`, kept behind the existing `FetchClientConfig` interface so callers are unaffected. That is a separate PR by design — a `ThreadsafeFunction` call from a wasi thread cannot be validated until the wasm bindings can be instantiated, which is blocked on the unreleased emnapi v2. <!-- fleet b6d0486f-97c7-42a7-bdaf-3490774cdec3 --> Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com> Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
Add a new method to `EcmascriptAnalyzable` to return the list of
non-inlined env vars
In this PR, this isn't used anywhere outside of the tests yet
While `cargo bench -p turbopack-ecmascript` does regress:
```
Benchmarking references/packages-bundle.js/full: Warming up for 1.0000 s
references/packages-bundle.js/full
time: [152.99 ms 153.34 ms 153.70 ms]
change: [+11.939% +12.678% +13.307%] (p = 0.00 < 0.05)
Performance has regressed.
Found 4 outliers among 100 measurements (4.00%)
4 (4.00%) high mild
Benchmarking references/packages-bundle.js/tracing: Warming up for 1.0000 s
references/packages-bundle.js/tracing
time: [153.07 ms 153.92 ms 155.15 ms]
change: [+34.997% +36.345% +37.554%] (p = 0.00 < 0.05)
Performance has regressed.
Found 4 outliers among 100 measurements (4.00%)
2 (2.00%) high mild
2 (2.00%) high severe
```
There is no measurable overall perf impact:
```
commit 7d29e35 (HEAD, tag: v16.4.0-canary.5)
v16.4.0-canary.5
pnpm next build --experimental-build-mode=compil 400.89s user 51.96s system 747% cpu 1:00.61 total
pnpm next build --experimental-build-mode=compil 394.99s user 54.10s system 757% cpu 59.289 total
pnpm next build --experimental-build-mode=compil 399.87s user 58.71s system 772% cpu 59.398 total
```
vs
```
commit 9335597 (HEAD -> mischnic/env-var-references)
remove runtime_all
pnpm next build --experimental-build-mode=compil 399.83s user 50.09s system 719% cpu 1:02.57 total
pnpm next build --experimental-build-mode=compil 403.57s user 53.79s system 743% cpu 1:01.52 total
pnpm next build --experimental-build-mode=compil 402.23s user 55.05s system 758% cpu 1:00.29 total
pnpm next build --experimental-build-mode=compil 400.17s user 55.15s system 761% cpu 59.817 total
```
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.
3 participants
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 : )