fix(minifier): preserve RegExp feature detection#24712
Conversation
Merging this PR will not alter performance
Comparing Footnotes
|
e3c3f57 to
efb85e2
Compare
|
@codex review |
|
Codex Review: Didn't find any major issues. 🎉 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Monitor OxcCommit:
|
53ced01 to
1a3ef05
Compare
1a3ef05 to
91d1240
Compare
0e7b2ae to
602e7f4
Compare
91d1240 to
4490b5e
Compare
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
4490b5e to
32a4d45
Compare
03df362 to
f51789f
Compare
9c04aa6 to
96987da
Compare
f51789f to
3efd4d0
Compare
96987da to
4994d9b
Compare
27fd72e to
a6ec664
Compare
a6ec664 to
2273082
Compare
Merge activity
|
> **PR stack (3 of 3)** > 1. #24739 > 2. #24742 > 3. **#24712 (this PR)** > > Review #24739 and #24742 first. This PR is based on #24742, so GitHub shows only the RegExp behavior change. Stacked on #24742, which exposes strict engine-target capabilities to side-effect analysis. RegExp constructor calls used for engine feature detection were removed by DCE when their pattern was valid according to the current Oxc RegExp parser. A pattern can be valid at build time but still throw a `SyntaxError` on the configured runtime, so removing the call changes the result of surrounding `try`/`catch` checks. RegExp purity now requires both syntactic validity and support from every configured target. Consumers without concrete targets remain conservative, while an explicit target allows the minifier to remove constructors known to be safe for those engines. Target-independent flag validation and pattern compatibility checks now live in `oxc_regular_expression`; side-effect analysis only maps target support to unsupported flags and patterns. String patterns, modern flags, named groups, property escapes, lookbehind, modifiers, invalid flags, and lone-surrogate strings are covered. A RegExp literal with replacement flags is removable only when the target supports both those flags and the dedicated `ES2015RegExpConstructorCanAlterFlags` compatibility feature. Explicitly targeting `esnext` opts into current features. ## Example Input: ```js export function supportsUnicodeRegExp() { try { new RegExp("\\p{Ll}", "u"); return true; } catch { return false; } } ``` Before: ```js export function supportsUnicodeRegExp() { try { return true; } catch { return false; } } ``` After: ```js export function supportsUnicodeRegExp() { try { new RegExp("\\p{Ll}", "u"); return true; } catch { return false; } } ``` Verified with all `oxc_regular_expression`, `oxc_compat`, `oxc_ecmascript`, and `oxc_minifier` tests; the no-feature/`side_effects`/`constant_evaluation` `oxc_ecmascript` matrix; affected-crate clippy; formatting; and diff checks. Fixes rolldown/rolldown#10279. Implemented with AI assistance (OpenAI Codex and Claude). The contributor remains responsible for reviewing, understanding, and submitting these changes under the repository AI usage policy.
> **PR stack (1 of 3)** > 1. **#24739 (this PR)** > 2. #24742 > 3. #24712 > > Review and merge in this order. The `oxc_ecmascript` crate currently compiles constant evaluation and side-effect analysis for every consumer, even when a consumer only needs the small shared ECMAScript value primitives. This makes optional analysis code and its dependencies part of unrelated builds. This introduces two explicit features: - `side_effects` enables side-effect analysis and its RegExp support. - `constant_evaluation` enables constant evaluation and implies `side_effects`, because side-effect analysis uses constant folding for several purity decisions. `ConstantValue`, `ValueType`, and `DetermineValueType` move to feature-independent root modules so `GlobalContext` remains available without either analysis feature. Existing paths through `constant_evaluation` remain re-exported when that feature is enabled. This is a prerequisite for #24742, which exposes engine targets to side-effect analysis without making compatibility data part of every `oxc_ecmascript` consumer. This is a breaking Cargo feature change for direct consumers of `oxc_ecmascript`: code using side-effect analysis or constant evaluation must enable the corresponding feature. Verified locally with the no-feature, `side_effects`, and `constant_evaluation` configurations, crate tests, dependent linter and minifier tests, rustdoc with warnings denied, and `just ready`. The release oxlint binary on this commit is 13,350,096 bytes. Implemented with AI assistance (OpenAI Codex and Claude). The contributor remains responsible for reviewing, understanding, and maintaining these changes.
> **PR stack (2 of 3)** > 1. #24739 > 2. **#24742 (this PR)** > 3. #24712 > > Review #24739 first. This PR is based on its branch, so GitHub shows only the engine-target plumbing. Stacked on #24739, which introduces the `side_effects` and `constant_evaluation` feature boundary for `oxc_ecmascript`. Side-effect analysis sometimes needs to know whether runtime syntax is supported by every configured engine. `MayHaveSideEffectsContext` currently has no access to target information, while `EngineTargets::has_feature` is intentionally permissive about missing compatibility data because it answers whether a transformation is needed. `MayHaveSideEffectsContext::engine_targets()` exposes the configured targets through a general-purpose accessor. Its default is `None`, so consumers without target information remain conservative, while the minifier supplies its existing `CompressOptions::target`. `EngineTargets::supports_es_feature` provides the corresponding strict capability query. Every configured engine must have compatibility data and meet the required version; empty targets and missing rows are not treated as proof of support. The existing transformation-oriented `has_feature` behavior remains unchanged. Because `oxc_linter` enables `side_effects`, this also adds `oxc_compat` to the oxlint and language-server build graphs. It does not change side-effect decisions by itself; #24712 consumes the new capability for target-aware RegExp validation. Verified with all `oxc_compat` tests, the no-feature/`side_effects`/`constant_evaluation` `oxc_ecmascript` matrix, a minifier check, formatting, and Clippy. Implemented with AI assistance (OpenAI Codex and Claude). The contributor remains responsible for reviewing, understanding, and maintaining these changes.
4994d9b to
01c3611
Compare
2273082 to
79e6d77
Compare

Stacked on #24742, which exposes strict engine-target capabilities to side-effect analysis.
RegExp constructor calls used for engine feature detection were removed by DCE when their pattern was valid according to the current Oxc RegExp parser. A pattern can be valid at build time but still throw a
SyntaxErroron the configured runtime, so removing the call changes the result of surroundingtry/catchchecks.RegExp purity now requires both syntactic validity and support from every configured target. Consumers without concrete targets remain conservative, while an explicit target allows the minifier to remove constructors known to be safe for those engines.
Target-independent flag validation and pattern compatibility checks now live in
oxc_regular_expression; side-effect analysis only maps target support to unsupported flags and patterns. String patterns, modern flags, named groups, property escapes, lookbehind, modifiers, invalid flags, and lone-surrogate strings are covered. A RegExp literal with replacement flags is removable only when the target supports both those flags and the dedicatedES2015RegExpConstructorCanAlterFlagscompatibility feature. Explicitly targetingesnextopts into current features.Example
Input:
Before:
After:
Verified with all
oxc_regular_expression,oxc_compat,oxc_ecmascript, andoxc_minifiertests; the no-feature/side_effects/constant_evaluationoxc_ecmascriptmatrix; affected-crate clippy; formatting; and diff checks.Fixes rolldown/rolldown#10279.
Implemented with AI assistance (OpenAI Codex and Claude). The contributor remains responsible for reviewing, understanding, and submitting these changes under the repository AI usage policy.