fix(es/minifier): drop spans of cached globals values - #12129

Related issue: none filed yet — happy to open one if you would like the report separately.

Rewritten after your review: the fix moved from inline_globals to the cache that produces the values, and the PR now leads with a failing test.

Description

GlobalPassOption::build parses each jsc.transform.optimizer.globals.vars value into an anonymous file of the SourceMap it is handed, and memoizes the parsed Expr in a process-wide static CACHE. A span is only meaningful to the SourceMap that produced it, so the cache outlives what its contents point at.

For a host that builds a fresh SourceMap per file — which is what swc::Compiler does, and what a bundler does — the emitted source map depends on whether the call hit the cache:

• on the call that parses the value, the mappings point into the anonymous file. With source_file_name set, map_file_name_to_source reports that file under the name of the file being compiled, so the position is silently attributed to the user's source;
• on every call that hits the cache, the position belongs to a SourceMap that no longer exists: it is dropped when it is past the end of the file being compiled, and points at an unrelated line when that file is longer.

Three things that cannot affect the semantics of globals currently affect its output:

1. the order the host passes the defines in — the cache key is a Vec<(Atom, Atom)> built from vars, so a host that holds the defines in a std::collections::HashMap (whose iteration order differs per instance) produces a different key per call, and therefore a different hit/miss pattern;
2. whether the call hits the process-wide cache — a cache should be semantically a no-op;
3. which file was compiled first in the process — the cached position is derived from the size of that file, so in a parallel build it depends on scheduling.

That is how this surfaced: in a Rspack build the source map is part of the module hash, so the chunk hash moved between builds of unchanged sources, and with minification on every mangled name in the chunk moved with it.

Fix

Drop the spans before the value is cached.

Parsing still happens in the caller's SourceMap, so a syntax error in a define value is still reported with a position — but nothing SourceMap-dependent survives into the cache. Substituted values then carry DUMMY_SP, which srcmap! skips, so no mapping is emitted for them on any call, whether it parsed the value or got it from the cache.

The previous revision of this PR overwrote the spans at the four substitution sites in inline_globals instead. It left the cache poisoned for any other consumer, added a subtree visit per substitution on a hot path, and gave synthesized nodes the span of real source. This one is a single drop_span at the point the value is created, which is also what inline_globals' own tests already assume — they build their globals map with DropSpan.

If you would rather keep a mapping for substituted values (__DEV__ mapping back to __DEV__ is nicer than no mapping at all), that can be layered on top cheaply now: with the cached children already dummy, the substitution site only needs value.set_span(ident.span), no visitor. I left it out because it is a separate change.

Tests

crates/swc/tests/source_map.rs gets a test that compiles the same input twice, each in a fresh SourceMap, and compares the emitted maps. It is committed before the fix and fails there:

assertion failed: `(left == right)`: the same input produced two different source maps
< {"version":3,"sources":["input.js","<anon>"],"sourcesContent":[...,"true"],...}
> {"version":3,"sources":["input.js"],"sourcesContent":[...],...}

The first compilation leaks the define value itself into the map as a source file; the second, which hits the cache, does not.

• cargo test -p swc_ecma_transforms_optimization — pass
• cargo test -p swc --test projects — 889 pass
• cargo test -p swc --test rust_api — pass
• cargo test -p swc --test source_map — pass except issue_622 and the stacktrace fixtures, which fail on main on my machine too (Node version)

The end-to-end numbers in the original description (400 transforms → 1 distinct source map, 40 builds → 1 distinct chunk hash) were measured with the previous revision. I have not rebuilt the downstream binding against this revision; the invariant is the one the new test asserts, and this revision removes the mappings entirely rather than rewriting them.