> **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.
Fixesrolldown/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.
## Implementation Complete: Add warning for top-level await usage
Successfully implemented warning for top-level await usage when the
target doesn't support it, following the same pattern as the existing
BigInt warning.
✅ **Successfully merged main branch and resolved all conflicts**
All changes have been merged with the latest main and all tests pass.
Ready for review and merge.
## Summary
- [x] Add `ES2022TopLevelAwait` feature to `oxc_compat` crate
- [x] Add `top_level_await` option to `ES2022Options`
- [x] Update `EnvOptions` to include `top_level_await` feature detection
- [x] Implement `enter_await_expression` handler in `ES2022` to emit
warning for top-level await
- [x] Add test cases to verify the warning is emitted correctly
- [x] Run tests to ensure everything works
- [x] Address review feedback: use `ctx.scoping().root_scope_id()` to
check for top-level
- [x] Add feature to `es-features.js` for proper tracking
- [x] Add test case for nested block with await (confirms current
implementation is correct)
- [x] **Merge main branch and resolve all conflicts** ✨
## Test Results
All tests pass successfully:
- ✅ oxc_transformer: 30 unit tests + 3 integration tests (es_target)
- ✅ oxc_compat: 3 tests
- ✅ No clippy warnings
- ✅ Successfully merged with latest main
## Resolved Conflicts
Merged with main and resolved conflicts in:
- `crates/oxc_compat/src/es_features.rs` - kept both
ES2020ArbitraryModuleNamespaceNames and ES2022TopLevelAwait features
- `crates/oxc_transformer/src/lib.rs` - kept both import/export
specifier methods and await expression method
- `crates/oxc_transformer/tests/integrations/es_target.rs` - kept both
test cases
- `crates/oxc_transformer/tests/integrations/snapshots/es_target.snap` -
updated test numbering to include both features
- `tasks/compat_data/data.json` - kept both
ArbitraryModuleNamespaceNames and TopLevelAwait entries
Fixesoxc-project/oxc#14258
<!-- START COPILOT CODING AGENT SUFFIX -->
<details>
<summary>Original prompt</summary>
>
> ----
>
> *This section details on the original issue you should resolve*
>
> <issue_title>transformer: warn top level await usage if not
supported</issue_title>
> <issue_description>A warning is emitted when BigInt is used and the
target does not support it
([playground](https://playground.oxc.rs/#eNptUj1vGzEM/SuGZg9Np9ZFp6YGAvQjyJCd0fEuSnTkgeQ5Dg7+76Euljwkk6RHkXzvkUuIYRcik9qmZ9783FzRj7ANHHZLkJnKkRNZ2PWQFbehZxnBDOUjcnPBTIC0BMLOZHYgKWcw7K4xZhCw5B3b75fHZKgTRGzQCDTkyzPyOAnqJUUjTx5+L66v4wPn+or9cP522oYJRAvXJeDRkNT7ul7To2uEnPnlDm0W+j+bpg73M8VCrZYqPVEOeAviuRVd8+6/3ZBJ8oqxBRSdtqX4W4TljDqH4t/Kwe/NmHdSBjKgmxtQv365+u6kZsVr7BPhnuVXBtV9wty1FnicUNKIZJDdS3YrWyuPjska+hcNOjBoPD6fwRLUdUyuBoXAXazWRe5wwHUDqIy4GfykHfvWnM0gYltrVSTjUP+uVerkivw6VlfO0x88YCv6jDj9gxHriNdUd5jz3t0uGQeUB9a6E0UPPWF085bL7eRwt9pX4HY7FbzYXDWd3gBEIxCc)).
Similar to that, it would be helpful if a warning is emitted for
top-level await as well.</issue_description>
>
> ## Comments on the Issue (you are @copilot in this section)
>
> <comments>
> </comments>
>
</details>
Fixesoxc-project/oxc#14258
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: sapphi-red <49056869+sapphi-red@users.noreply.github.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Dunqing <29533304+Dunqing@users.noreply.github.com>
Co-authored-by: Dunqing <dengqing0821@gmail.com>
feat(transformer): add warning for arbitrary module namespace identifier
names
Implements warnings for the ES2020 "Arbitrary module namespace
identifier names" feature (TC39 proposal #2154), which allows string
literals as import/export specifiers. Similar to #14276.
### Changes
- **Compatibility data**: Added `ArbitraryModuleNamespaceNames` to
`tasks/compat_data/custom-compat-data.js` with browser support (Chrome
88+, Edge 88+, Opera 74+, Firefox 87+, Safari 14.1+, Node 16.0+, Deno
1.6+)
- **Transformer**: Added warning logic in `ES2020` for string literals
in `ImportSpecifier`, `ExportSpecifier`, and `ExportAllDeclaration`
nodes
- **Configuration**: Added `arbitrary_module_namespace_names` option and
environment target mapping
### Example
```javascript
// Triggers warning when targeting ES2019 or Chrome 87
export { foo as "kebab-case-name" };
import { "string-name" as bar } from "./module";
export * as "namespace" from "./module";
```
Warning message:
```
⚠ Arbitrary module namespace identifier names are not available in the configured target environment.
```
### Testing
Added integration tests covering supported/unsupported targets, multiple
literals, and normal identifiers.
<!-- START COPILOT CODING AGENT SUFFIX -->
<details>
<summary>Original prompt</summary>
> Similar to https://github.com/oxc-project/oxc/pull/14276, add a
warning for "Arbitrary module namespace identifier names" feature
(https://github.com/tc39/ecma262/pull/2154). Add the compat data to
`tasks/compat_data/custom-compat-data.js` as the data is not included in
the compat table.
</details>
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).
---------
Signed-off-by: 翠 <green@sapphi.red>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: sapphi-red <49056869+sapphi-red@users.noreply.github.com>
Co-authored-by: 翠 <green@sapphi.red>
## Summary
fixes#12796
* Added target `ES2026`
* Moves the explicit resource management feature from proposals to ES2026, as it is now a finalized ECMAScript 2026 feature.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Dunqing