#5482 makes most of the `RegExpOptions` not be needed outside `new` method. So only store the remaining options which are actually needed on `RegExp`. This reduces size of `RegExp`.
(this is micro-optimization, and unlikely to make a measurable difference, but why not?)
Similar to #5482. Calculate whether any unsupported RegExp patterns at start, to make checking if need to check for patterns cheaper (a single comparison operation, rather than 3 comparisons and ORs).
Calculate unsupported RegExp flags at start, to make checking flags on each RegExp during traversal cheaper (a single OR operation). i.e. do work once at the start, rather than over and over each time you find a `RegExp`.
related: #4754
The implementation port from [esbuild](332727499e/internal/js_parser/js_parser.go (L12820-L12840)). And cover all babel's regexp plugins
---
## The following description was generated by `Graphite` 😋
### TL;DR
Added support for transforming various RegExp features to ensure compatibility with older JavaScript environments.
### What changed?
- Implemented a new `RegExp` transformer to handle unsupported RegExp literal features
- Added options to control different RegExp transformations (e.g., sticky flag, unicode flag, dot-all flag, etc.)
- Updated the transformer to convert unsupported RegExp literals into `new RegExp()` constructor calls
- Added test cases for different RegExp transformations
- Integrated the new RegExp transformer into the existing transformation pipeline
### How to test?
1. Run the existing test suite to ensure no regressions
2. Execute the new RegExp-specific tests in the `tasks/transform_conformance/tests/esbuild-tests/test/fixtures/regexp/` directory
3. Try transforming code with various RegExp features using different target environments to verify correct transformations
As of now if we remove the implementation of a trait for a type and implement the method on that type directly it wouldn't break while it isn't the original trait anymore so that method might do something entirely different.
This change is more explicit on trait calls so we hit compile errors on these kinds of changes.
#5223 altered `JSXElementName` so `JSXElementName::Identifier` is used only for non-reference JSX names (e.g. `<div>`). `JSXElementName::IdentifierReference` is used where the name is a reference (e.g. `<Foo>`). Similarly `JSXMemberExpressionObject`'s `object` is always an `IdentifierReference` now.
So, the net result is that `JSXIdentifier` is now never a reference, it's just the JSX equivalent of `IdentifierName`. So I don't think `JSXIdentifier` can ever have side-effects.
This PR:
1. Removes `impl ListenerMap for JSXIdentifier`
2. Adds `impl ListenerMap for JSXMemberExpression` and makes sure the root `IdentifierReference` (`Foo` in `<Foo.bar.qux>`) is visited.
So far, the `ReferenceFlags::TSTypeQuery` only used indicates it is referenced by `TSTypeQuery` that we can confirm the reference should be regarded as a type reference, namely `ReferenceFlags::Type`.
This PR adds a `ReferenceFlags::ValueAsType` instead of `ReferenceFlags::TSTypeQuery`. The new flag has the same behavior as the previous one. But it looks more general and is not only used in `TSTypeQuery`. But now it is a temporary flag. We use it to resolve the symbol correctly and replace `ReferenceFlags::ValueAsTyoe` with `ReferenceFlags::Type` after resolved.
Also, this change eliminates the inconsistency in behavior between the `Reference::is_type` and `ReferenceFlags::is_type` methods.
close: #5435
The behavior of `IdentifierReference` in `TSPropertySignature` is the same as in `TSTypeQuery`, both allow only reference value bindings and type-only import bindings.
I still use `ReferenceFlags::TSTypeQuery` here because I want to avoid producing many changes unrelated to the bug in this PR. I will refactor it in the follow-up PR soon
This should be causing more negative tests to fail than it actually is. This is
because our typescript coverage tests use the "declarations" option to change
the source type to `.d.ts`, which is incorrect. This setting enables `.d.ts`
emits, it does not mean that input files should be treated as `.d.ts`
themselves.
`SymbolTable::get_symbol_id_from_name(name).is_none()` is not always correct, because it will return `false` if there is a binding *anywhere* in the AST with that name, whereas what we actually want to know is whether *this* `IdentifierReference` is referring to a global or not.
Instead, look up whether this reference is resolved or not using `SymbolTable::is_global_reference`.
The 3 test cases added were not working prior to this change.
`Expression::get_inner_expression` and `Expression::get_inner_expression_mut` use a loop rather than recursive function calls. Loops are usually cheaper.
1. wasm-pack with release flag will increase wasm bundling time, which
hurts dx when developing playground.
2. only enable `release` flag when `build-wasm`.
Follow-on after #5425. Further optimize `oxc_syntax::identifier::is_identifier_name` by processing string in blocks of 8 bytes, and checking if all bytes in a block are ASCII in one go, rather than testing each byte individually.
Optimize `oxc_syntax::identifier::is_identifier_name`. Add a fast path for ASCII, which will be the common case. Only fall back to iterating over `char`s and using the more expensive test functions e.g. `is_identifier_start_unicode` if non-ASCII chars are found.
