Closes the migration tracked in #23043.
The new builder API (methods on the AST types themselves) has been in place for a while, all Oxc crates are migrated, and every crate which uses `AstBuilder` already enables `disable_old_builder` in its tests. The module docs said "after a few weeks, we will remove `AstBuilder`'s own methods entirely" — this does that.
## What's removed
- `crates/oxc_ast/src/generated/ast_builder.rs` and `builder/methods.rs` — `AstBuilder`'s own node and primitive constructors.
- `AstBuilderGenerator`, which produced the former.
- The `disable_old_builder` Cargo feature, plus the dev-dependency hacks it required across 33 manifests. Eight crates depended on `oxc_ast` *purely* to turn the feature on; those deps and their `cargo-shear` ignore entries are gone too.
## One thing worth reviewing
`AstBuilderGenerator` owned the `#[builder(default)]` / `#[builder(skip)]` attr registration that `BuilderMethodsGenerator` only *reads* — its doc comment said as much. Deleting it naively would have silently dropped `skip`/`default` handling for the 12 AST types using those attrs, so `attrs()` and `parse_attr()` move to `BuilderMethodsGenerator`.
The evidence this was faithful: after regenerating, `builder_methods.rs` and every other generated file are **byte-identical**. The only generated change in the diff is the deletion.
## Breaking changes
- `AstBuilder`'s own methods are gone. Use the AST type methods: `Statement::new_expression_statement(span, expr, &builder)` instead of `builder.statement_expression(span, expr)`.
- `AstBuilder` is no longer `Copy`/`Clone`, and its `allocator` field is private — use the `allocator` method from `GetAllocator`.
- `AstBuilder` and `NONE` are no longer re-exported from the crate root; import them from `oxc_ast::builder`. (The `disable_old_builder` feature already gated these off, so nothing in-tree used the root path.)
- The `disable_old_builder` feature no longer exists — remove it from any manifest that sets it.
A migration note covering all of the above is in `crates/oxc_ast/src/builder/mod.rs`.
---
Implemented with AI assistance (Claude Code); design, review, and verification driven by the author per the repo AI-usage policy.
> **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.
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [syn](https://redirect.github.com/dtolnay/syn) |
workspace.dependencies | major | `2` → `3` |
---
### Release Notes
<details>
<summary>dtolnay/syn (syn)</summary>
###
[`v3.0.0`](https://redirect.github.com/dtolnay/syn/releases/tag/3.0.0)
[Compare
Source](https://redirect.github.com/dtolnay/syn/compare/2.0.119...3.0.0)
This release contains adjustments to the syntax tree to account for
ongoing Rust language development from the 3 years since syn 2.0.0 and
to anticipate some in-flight Rust language RFCs.
These include: default values in fields, pinned type sugar, raw
lifetimes, generator blocks and functions, unnamed enum variants,
attributes in tuple types and tuple patterns, named arguments in
parenthesized generic argument lists, lightweight clones, const traits,
const function pointers, mutability restricted fields, supertrait auto
implementation, final associated functions, trait implementability
restrictions, const blocks in path arguments, item-level const blocks,
return type notation, never patterns, function delegation, mutable
by-reference bindings, in-place initialization, field projections,
explicitly dyn-compatible traits, view types, file-level frontmatter,
generic const arguments, guard patterns, lazy type aliases, explicitly
safe foreign items, super let, unsafe fields, pattern types,
heterogeneous try-blocks, function contracts, async function trait
bounds, static closure coroutine syntax, unsafe binder types, move
expressions, for-await loops, and postfix keywords.
<br>
<p align="center"><a href="https://docs.rs/syn/3/syn">[API documentation
for 3.0]</a></p>
### Breaking changes
#### Modifiers
To reserve more room for language evolution, there are 10 new
non-exhaustive structs in the syntax tree having the following
commonality:
- Name ending in `Modifiers`. {`BlockModifiers`, `ClosureModifiers`,
`ConstModifiers`, `FieldModifiers`, `FnModifiers`, `ImplModifiers`,
`LocalModifiers`, `TraitBoundModifiers`, `TraitModifiers`,
`TypeModifiers`}
- Each implements `Default`. The default value is guaranteed to comprise
no tokens.
- Non-exhaustive. Can only be instantiated by Syn's parser or by
creating and then mutating `▁▁Modifiers::default()`.
- Does not implement `Parse`. When parsing, they are parsed by the
enclosing syntax tree node.
- Does not implement `ToTokens`. In some cases the syntax that these
nodes might hold in the future is not necessarily contiguous tokens.
- Provides `.require_empty() -> Result<()>` which returns a meaningfully
spanned error if the modifiers are different from the empty default.
This enables a caller to reject syntax it does not recognize without
knowing what that syntax may be.
#### Types
- `Type::BareFn` has been renamed to `Type::FnPtr` to mirror the
compiler's terminology. Together with this, `BareVariadic` is renamed to
`FnPtrVariadic`.
- The mutually exclusive `const_token` and `mutability` fields of
`Type::Ptr` have been unified into an enum of type `PointerMutability`,
which was already previously used by `Expr::RawAddr`.
- Every `Type` variant now holds attributes, which can represent the
attributes of element types inside a tuple type, or attributes for a
function return type.
- `BareFnArg` is renamed to `NamedArg` and is used in
`ParenthesizedGenericArguments`, in addition to the existing use in
`Type::FnPtr`.
#### Expressions
- In `Expr::Closure`, the fields `or1_token` and `or2_token` have been
renamed to `inputs_begin` and `inputs_end` to indicate the beginning and
ending `|` token of the closure inputs.
#### Statements
- Attributes are now preserved on all expression kinds in statement
position. Previously, parsing would silently lose attributes on some
expression statements without a dedicated Expr variant, such as
tail-call expressions.
#### Patterns
- The `guard` field of `Arm` is replaced by a new `Pat::Guard` variant
held in the arm's `pat`.
#### Items
- The `unsafety` field of `Signature`, which represented the presence or
absence of `unsafe`, is replaced by a 3-way `Safety` enum which may be
safe, unsafe, or default. `ForeignItem::Static` also gets a `Safety`.
- Some of the fields of `Receiver` have been split to a non-exhaustive
`ReceiverKind` enum to create room for proposed new kinds of method
receivers, such as pinned.
- Type aliases now hold a `WhereClausePlacement` to distinguish between
early placement (which is the default for item-level type aliases and is
*deprecated* in associated type aliases) and late placement (which is
the default for associated type aliases and is *unstable* in item-level
type aliases). Parsing and printing a syntax tree will now preserve the
where-clause placement rather than rewriting it to the default placement
for the item kind.
#### Generics
- `WherePredicate::Lifetime` and `WherePredicate::Type` have a new field
holding the attributes on the where-predicates.
- `GenericParam::Type` and `GenericParam::Const` now match the rest of
the syntax tree in holding their optional default using a single Option
of tuple, rather than a pair of Option.
#### Literals
- The `Parse` implementation of `Lifetime` no longer permits keyword
lifetimes, matching a change in Rust 1.81 to deny such lifetimes
pre-expansion. `Lifetime::parse_any` may be used to parse lifetimes
permissive of keywords.
- `LitInt` and `LitFloat` no longer implement
`From<proc_macro2::Literal>`. Use `Lit::new(literal)` and then match
`Lit::Int` or `Lit::Float`.
- The `StrStyle` enum was unused and has been deleted.
#### More
- `File` contains a new `Option<Frontmatter>`, but does not yet parse
frontmatter in `syn::parse_file` until that language feature progresses
closer to stabilization.
- Some enums no longer provide `From` impls. Construct the variant by
name instead, such as `Expr::Array(e)` in place of `e.into()`.
- The `pop` method of `Punctuated<T, P>` now returns `Option<T>`
discarding the trailing punctuation if any, rather than `Option<Pair<T,
P>>`. A new method `pop_pair` provides the old behavior.
- Syntax tree traversal (`visit`, `visit_mut`, `fold`) no longer
provides a method for processing `Span`. This was already incompletely
supported and never walked most of the spans in a syntax tree.
- The `Speculative` and `AnyDelimiter` traits have been sealed and
cannot be implemented for types outside of Syn's `ParseStream`.
</details>
---
### Configuration
📅 **Schedule**: (in timezone Asia/Shanghai)
- Branch creation
- "before 10am on monday"
- Automerge
- At any time (no schedule defined)
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/oxc-project/oxc).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4yNjUuMSIsInVwZGF0ZWRJblZlciI6IjQzLjI2NS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Cameron Clark <cameron.clark@hey.com>
Part of #23043.
We don't enable `oxc_ast`'s `disable_old_builder` Cargo feature in any of our published crates, or crates that are depended on by published crates.
Tasks are private to the repo, so enable this feature on them, to ensure no usage of legacy `AstBuilder` methods sneak in during the transition period before we delete these methods.
## Summary
- Disable `test = false` and `doctest = false` for crates that have no tests
- Reduces CI noise from "0 passed; 0 failed" output
- Saves compilation time for empty test targets
**Affected crates:**
- `oxc_ast_macros` - lib test
- `oxc_language_server` - bin test, lib doctest
- `oxc_napi` - lib test
- `oxc_syntax` - lib doctest
- `oxc_compat_data` - bin test
- `oxc_coverage` - lib test
- `oxc_linter_codegen` - bin test
- `oxc_prettier_conformance` - lib test
- `oxc_transform_conformance` - lib test
- `vscode_docs` - bin test
- `website_common` - lib test, lib doctest
## Test plan
- [x] `cargo test` passes with no empty test suites
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## 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)
Updates compat-table dependency to the latest commit.
- Previous SHA: `047878d9b67327ebd642ea855649e029fe066a50`
- New SHA: `a970fc00cc33b58d0b84d4b290ea46a185c8fcf1`
Replace `#[allow]` with `#[expect]` through the whole codebase.
This also surfaced many places where the `#[allow]` attributes were outdated/pointless and could be removed entirely.
Only places `#[allow]` remains are:
1. In generated code and macros, where lint errors may or may not be triggered depending on the generated code.
2. A few places where clippy malfunctions. These use e.g. `#[allow(unused, clippy::allow_attributes)]`.
Pure refactor. Re-order imports for clarity:
1. `std`
2. External crates
3. `oxc_*` crates
4. Current crate `use crate::...`
5. Super `use super::...`
6. Local modules
This order is from "furthest away" to "closest". This makes it clearer to see what is coming from where.
`cargo +nightly fmt` (#7877) did a lot of the work, but unfortunately `rustfmt` does not have an option to (a) put workspace crates in a separate block from external crates and (b) move `mod` statements to after `use` statements.
Boshen