next.js

b39e17ad - fix(turbo-rcstr): keep the const constructor working on 32-bit targets

fix(turbo-rcstr): keep the const constructor working on 32-bit targets `rcstr!` expands to a `const`, so `TaggedValue`'s constructors have to be usable during const evaluation. Const evaluation is asymmetric about pointer/integer conversions: integer -> pointer is allowed (the result simply carries no provenance), but pointer -> integer is forbidden, because a pointer is an abstract (allocation, offset) pair until the linker assigns an address. On 64-bit that is already fine - storage is a `NonNull`, so `new_ptr` is a pointer -> pointer cast and `new_tag` an integer -> pointer transmute. On 32-bit, storage was a bare `NonZeroU64`, so `new_ptr` needed the one conversion that cannot work and every `rcstr!` taking the static path failed with `error[E0080]: unable to turn pointer into integer`. Keep the value 8 bytes wide - so `MAX_INLINE_LEN` stays 7 on every target - but hold the address in a real pointer field paired with a byte payload sized to the pointer width (no padding, since `new_tag` transmutes the whole value). Field order follows endianness so the pointer's least significant byte always lands where the value's least significant byte lives, which is where the tag is read from. Two things this needs that are easy to miss, both now covered by assertions: - `align(8)`: a pointer field only aligns to 4, but the value is read back as a `u64` to extract the tag, and wasm traps on an unaligned 64-bit load. - `get_ptr` must keep masking `TAG_MASK`: the tag lives in the pointer's low bits, so returning the field directly dereferences a dynamic string's `Arc` two bytes off. Both endian layouts are declared unconditionally so their offset assertions compile everywhere; `atom_size_128` keeps its existing 16-byte representation and is unaffected. Note: big-endian and 16-bit layouts are checked at compile time but not exercised at runtime, as no such target is available here. The one-line Cargo.lock delta is cargo's own removal of a stale `turbo-tasks-fetch` entry; it is regenerated on every build of this tree. Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com> Co-authored-by: Luke Sandberg <210140+lukesandberg@users.noreply.github.com>