next.js

75eafdff - Turbopack: address review feedback on export name mangling

Turbopack: address review feedback on export name mangling - Move the name table out of `turbo-tasks-hash` and next to its only consumer, as `references/esm/mangle/table.rs`. It is JS-identifier-specific and has nothing to do with generic hashing; it just uses `hash_xxh3_hash64`. - Reserve the export keys the runtime defines on the exports object itself (`default`, `__esModule`). Nothing stops the table from *assigning* one of those strings to some other export once it is long enough to reach them, and that key would then collide with the runtime's own property. Reserved names claim their bucket before anything is hashed, and the table grows if the reservations no longer leave room. - Carry `mangle_export_names` on `EsmExports` instead of a defaulted `EcmascriptChunkPlaceable` trait method. A module that derives its exports from another one — a facade, a locals module, a part, a rename — now inherits it with the data instead of through a hand-written delegation that a new module type could forget. The facades built by `reexport_including_default` pass `false`, since a host framework looks their exports up by name. - Drop the single-name special case. It saved nothing and made the 1 → 2 export transition rename the first export; hashing a lone name into the one-character table keeps it stable instead. - Work in `RcStr` throughout the table, so a preserved name is a refcount bump and an assigned one converts the encoder's `String` exactly once. - Make the encoder and decoder private; only the assignment entry point is used outside the module. Also documents why JS keywords need no special treatment: the assigned names are only ever emitted as property keys — object-literal keys in the export table and bracket-access strings at the consumer — never as bare bindings, so a key that spells `if` or `in` is legal. Covered by a test, along with the new reserved-name behaviour and the stability of a single export. Co-authored-by: Luke Sandberg <210140+lukesandberg@users.noreply.github.com> Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>