Fixes a bug when "'Await' expression is not allowed in formal parameters
of an async function" is thrown for "await" encountered in a function
definition assigned to a default function parameter.
Fixes loading of https://excalidraw.com/
This is actually safe everywhere but in the topmost program scope.
For web compatibility reasons, we have to flush all top-level bindings
to the environment, in case a subsequent separate <script> program
comes looking for them.
By using separate struct we can avoid updating AST node and
ECMAScriptFunctionObject constructors every time there is a need to
add or remove some additional information colllected during parsing.
Allows to skip function environment allocation for non-arrow functions
if the only reason it is needed is to hold `this` binding.
The parser is changed to do following:
- If a function is an arrow function and uses `this` then all functions
in a scope chain are marked to allocate function environment for
`this` binding.
- If a function uses `new.target` then all functions in a scope chain
are marked to allocate function environment.
`ordinary_call_bind_this()` is changed to put `this` value in execution
context when function environment allocation is skipped.
35% improvement in Octane/typescript.js
50% improvement in Octane/deltablue.js
19% improvement in Octane/raytrace.js
This allows us to skip allocating a function environment in cases where
it was previously impossible because the arguments object needed a
binding.
This change does not bring visible improvement in Kraken or Octane
benchmarks but seems useful to have anyway.
If a function has the following properties:
- uses only local variables and registers
- does not use `this`
- does not use `new.target`
- does not use `super`
- does not use direct eval() calls
then it is possible to entirely skip function environment allocation
because it will never be used
This change adds gathering of information whether a function needs to
access `this` from environment and updates `prepare_for_ordinary_call()`
to skip allocation when possible.
For now, this optimisation is too aggressively blocked; e.g. if `this`
is used in a function scope, then all functions in outer scopes have to
allocate an environment. It could be improved in the future, although
this implementation already allows skipping >80% of environment
allocations on Discord, GitHub and Twitter.
These changes are compatible with clang-format 16 and will be mandatory
when we eventually bump clang-format version. So, since there are no
real downsides, let's commit them now.
This commit un-deprecates DeprecatedString, and repurposes it as a byte
string.
As the null state has already been removed, there are no other
particularly hairy blockers in repurposing this type as a byte string
(what it _really_ is).
This commit is auto-generated:
$ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \
Meta Ports Ladybird Tests Kernel)
$ perl -pie 's/\bDeprecatedString\b/ByteString/g;
s/deprecated_string/byte_string/g' $xs
$ clang-format --style=file -i \
$(git diff --name-only | grep \.cpp\|\.h)
$ gn format $(git ls-files '*.gn' '*.gni')
In particular, this patch focuses on:
- Updating the old "import assertions" to the new "import attributes"
- Allowing realms as module import referrer
When deciding whether we need to create a full-blown `arguments` object,
we look at various things, starting as early as in the parser.
Until now, if the parser saw the identifier `arguments`, we'd decide
that it's enough of a clue that we should create the `arguments` object
since somebody is obviously accessing it.
However, that missed the case where someone is just accessing a property
named `arguments` on some object. In such cases (`o.arguments`), we now
hold off on creating an `arguments` object.
~11% speed-up on Octane/typescript.js :^)
Previously, certain crafted input could cause the JS parser to hang, as
it repeatedly tried to parse an EOF token after hitting an "invalid
destructuring assignment target" error. This change ensures that we
stop parsing after hitting this error condition.
Before usage of GetGlobal was prevented whenever eval() is present in
the scope chain.
With this change GetGlobal is emitted for `g` in the following program:
```js
function screw_everything_up() {
eval("");
}
var g;
g;
```
It makes Octane/mandreel.js benchmark run 2x faster :)
This change makes LibJS correctly report a syntax error when a unary
expression is followed by exponentiation, as the spec requires.
Apparently this is due to that expression being ambiguous ordering.
Strangely this check does not seem to apply in the same way for '++' and
'--' for reasons that I don't fully understand. For example
```
let x = 5;
++x ** 2
```
Since `--5` and `++5` on it's own results in a syntax error anyway, it
seems we do not need to perform this exponentiation check in those
places.
Diff Tests:
+6 ✅ -6 ❌
When determining the precedence of the + and - operators, the parser
always returned the precedence using these operators in a binary
expression (lower than division!). The context of whether the operator
is used in a unary or binary expression must be taken into account.
We had an edge case where calls to eval() left the environment untainted
*if* `eval` had also been declared as a local variable in the same
parsing context.
This broke the expected direct eval behavior when the variable `eval`
was still pointing at the global `eval` function.
This patch fixes the issue by simply always tainting the environment
when a call to something named `eval` is encountered. It doesn't seem
worth worrying about optimizing the case where someone is calling their
own function named `eval`..
Fixes 1 test-js test in bytecode mode. :^)
This change speeds up the process of checking variable declaration
within the scope by replacing the iteration through all declared
variables (without the ability to exit early from the loop) with hash
map lookups.
This change cuts google maps loading by 17s on my computer.
Previously, the usage of local variables was limited for all function
declarations. This change relaxes the restriction and only prohibits
locals for hoistable annexB declarations.
Initially, the usage of local variables for parameters had to be
disabled when default values were used because there was a bug that
didn't allow to correctly find the scope to which identifiers used
within the default parameter expression belonged, and hence correctly
identify if a variable can be local. However, this bug was fixed in
2f85faef0f, so now this restriction
is no longer needed.
This change fixes an issue where identifiers used in default function
parameters were being "registered" in the function's parent scope
instead of its own scope. This bug resulted in incorrectly detected
local variables. (Variables used in the default function parameter
expression should be considered 'captured by nested function'.)
To resolve this issue, the function scope is now created before parsing
function parameters. Since function parameters can no longer be passed
in the constructor, a setter function has been introduced to set them
later, when they are ready.
Using local variables to store function parameters makes Kraken tests
run 7-10% faster.
For now this optimization is limited to only be applied if:
- Parameter does not use destructuring assignment
- None of the function params has default value
- There is no access to "arguments" variable inside function body
This modification enables the parser to determine whether an identifier
used within a function refers to a local variable or not. In this
context, a local identifier means that it is not captured by any nested
function declaration which means it modified only from inside a
function.
The information about whether identifier is local is stored inside
Identifier AST node and also contains information about the index of
local variable inside a function and information about total number
of local variables used by a function is stored in function nodes.
By using Identifier class to represent the name of a class expression,
it becomes possible to consistently store information within the
identifier object, indicating whether the name refers to a local
variable or not.
The flag indicating the presence of an await expression should be
passed up to the parent scope until the nearest function scope is
reached. This resolves several problems related to identifying
top-level awaits, which are currently not recognized correctly
when used within a nested scope.
Previously we were unable to parse code like `yield/2` because `/2`
was parsed as a regex. At the same time `for (a in / b/)` was parsed
as a division.
This is solved by defaulting to division in the lexer, but calling
`force_slash_as_regex()` from the parser whenever an IdentifierName
is parsed as a ReservedWord.
Instead of passing the continuously merged initial forbidden token set
(with the new additional forbidden tokens from each parsed secondary
expression) to the next call of parse_secondary_expression(), keep a
copy of the original set and use it as the base for parsing the next
secondary expression.
This bug prevented us from properly parsing the following expression:
```js
0 ?? 0 ? 0 : 0 || 0
```
...due to LogicalExpression with LogicalOp::NullishCoalescing returning
both DoubleAmpersand and DoublePipe in its forbidden token set.
The following correct AST is now generated:
Program
(Children)
ExpressionStatement
ConditionalExpression
(Test)
LogicalExpression
NumericLiteral 0
??
NumericLiteral 0
(Consequent)
NumericLiteral 0
(Alternate)
LogicalExpression
NumericLiteral 0
||
NumericLiteral 0
An alternate solution I explored was only merging the original forbidden
token set with the one of the last parsed secondary expression which is
then passed to match_secondary_expression(); however that led to an
incorrect AST (note the alternate expression):
Program
(Children)
ExpressionStatement
LogicalExpression
ConditionalExpression
(Test)
LogicalExpression
NumericLiteral 0
??
NumericLiteral 0
(Consequent)
NumericLiteral 0
(Alternate)
NumericLiteral 0
||
NumericLiteral 0
Truth be told, I don't know enough about the inner workings of the
parser to fully explain the difference. AFAICT this patch has no
unintended side effects in its current form though.
Fixes#18087.
This class had slightly confusing semantics and the added weirdness
doesn't seem worth it just so we can say "." instead of "->" when
iterating over a vector of NNRPs.
This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
In this patch only top level and not the more complicated for loop using
statements are supported. Also, as noted in the latest meeting of tc39
async parts of the spec are not stage 3 thus not included.
DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so
let's rename it to A) match the name of DeprecatedString, B) write a new
FlyString class that is tied to String.
