If the next token isn't a TokenType::Colon (:), this can't possibly be a
labelled statement, so we can fail before having to save_state().
This improves parsing time on a large chunk of JS by ~12.5%.
The save/load of parser state performed by lookahead parsing is quite
expensive so let's try to avoid it in the most common case.
This is a 15-20% speedup on various chunks of JS I've tested. :^)
These are tested by test262 but the current test262-runner reads the
files in python which automatically converts \r\n to \n.
This meant that we passed the tests while we should not have.
Our existing implementation did not check the element type of the other
pointer in the constructors and move assignment operators. This meant
that some operations that would require explicit casting on raw pointers
were done implicitly, such as:
- downcasting a base class to a derived class (e.g. `Kernel::Inode` =>
`Kernel::ProcFSDirectoryInode` in Kernel/ProcFS.cpp),
- casting to an unrelated type (e.g. `Promise<bool>` => `Promise<Empty>`
in LibIMAP/Client.cpp)
This, of course, allows gross violations of the type system, and makes
the need to type-check less obvious before downcasting. Luckily, while
adding the `static_ptr_cast`s, only two truly incorrect usages were
found; in the other instances, our casts just needed to be made
explicit.
And also try_create<T> => try_make_ref_counted<T>.
A global "create" was a bit much. The new name matches make<T> better,
which we've used for making single-owner objects since forever.
- Fix some places where escaped keywords are (not) allowed.
- Be more strict about parameters for functions with 'use strict'.
- Fix that expressions statements allowed functions and classes.
- Fix that class expressions were not allowed.
- Added a new next_token() method for checking the look ahead.
- Fix that continue labels could jump to non iterating targets.
- Fix that generator functions cannot be declared in if statements.
Added a test to ensure the behavior stays the same.
We now throw on a direct usage of an escaped keywords with a specific
error to make it more clear to the user.
For example, "property.br\u{64}wn" should resolve to "property.brown".
To support this behavior, this commit changes the Token class to hold
both the evaluated identifier name and a view into the original source
for the unevaluated name. There are some contexts in which identifiers
are not allowed to contain Unicode escape sequences; for example, export
statements of the form "export {} from foo.js" forbid escapes in the
identifier "from".
The test file is added to .prettierignore because prettier will replace
all escaped Unicode sequences with their unescaped value.
This is a small step in the right direction although the amount of
different checks is becoming unsustainable. In the future we probably
want to have the current_scope handle all declarations.
Problem:
- New `any_of` implementation takes the entire container so the user
does not need to pass explicit begin/end iterators. This is unused
except is in tests.
Solution:
- Make use of the new and more user-friendly version where possible.
The spec requires that invalid RegExp literals must cause a Syntax Error
before the JavaScript is executed. See:
https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors
This is explicitly tested in the RegExp/property-escapes test262 tests.
For example, see unsupported-property-Line_Break.js:
$DONOTEVALUATE();
/\p{Line_Break}/u;
That RegExp literal is invalid because Line_Break is not a supported
Unicode property. $DONOTEVALUATE() just throws an exception when it is
executed. The test expects that this file will fail to be parsed.
Note that RegExp patterns can still be parsed at execution time by way
of "new RegExp(...)".
If a function is strict (has 'use strict' directive) it cannot have
bindings, cannot have duplicated parameter names and cannot have some
reserved keywords and identifiers as parameter names.
The logic partly applies depending on whether we are already in strict
mode or the function contains 'use strict';
Instead of only parsing a primary expression, we should also allow
member expressions, call expressions, and tagged template literals (and
optional chains, which we don't have yet).
In the spec, all of this is covered by `LeftHandSideExpression`
(https://tc39.es/ecma262/#prod-LeftHandSideExpression).
This requires variables that should be exported to the script host
or to other scripts to be declared as var (such as in test-common.js),
since lexically-scoped variables won't be visible.
The parser doesn't always track lexical scopes correctly, so let's not
rely on that for direct argument loading.
This reverts the LoadArguments bytecode instruction as well. We can
bring these things back when the parser can reliably tell us that
a given Identifier is indeed a function argument.
To better follow the spec, we need to distinguish between the current
execution context's lexical environment and variable environment.
This patch moves us to having two record pointers, although both of
them point at the same environment records for now.
This patch makes the following name changes:
- ScopeObject => EnvironmentRecord
- LexicalEnvironment => DeclarativeEnvironmentRecord
- WithScope => ObjectEnvironmentRecord
From the specification:
It is a Syntax Error if StringValue of IdentifierName is the same
String value as the StringValue of any ReservedWord except for yield
or await.
It is a Syntax Error if this phrase is contained in strict mode code
and the StringValue of IdentifierName is: "implements", "interface",
"let", "package", "private", "protected", "public", "static", or
"yield".
This commit implements parsing for `yield *expr`, and the multiple
ways something can or can't be parsed like that.
Also makes yield-from a TODO in the bytecode generator.
Behold, the glory of javascript syntax:
```js
// 'yield' = expression in generators.
function* foo() {
yield
*bar; // <- Syntax error here, expression can't start with *
}
// 'yield' = identifier anywhere else.
function foo() {
yield
*bar; // Perfectly fine, this is just `yield * bar`
}
```
This patch adds an "argument index" field to Identifier AST nodes.
If the Identifier refers to a function parameter in the currently
open function scope, we stash the index of the parameter here.
This will allow us to implement much faster direct access to function
argument variables.
The property name in an object literal can either be a literal or a
computed name, in which case any AssignmentExpression can be used, we
now only parse AssignmentExpression instead of the previous incorrect
behaviour which allowed any Expression (Specifically, comma
expressions).
The addition of an is_generator parameter broke this, as is_strict was
being passed in, causing an assertion.
This is being addressed by changing it to an enum in #7981, but in the
meantime let's just fix these two cases.
Checking for this (and get()'ing it) is always invalid, so let's just
disallow it.
This also finds two bugs where the code is checking for types that can
never actually be in the variant (which was actually a refactor
artifact).
This patch changes the validation of RegExp flags (checking for
invalid and duplicate values) from a SyntaxError at runtime to a
SyntaxError at parse time - it's not something that's supposed to be
catchable.
As a nice side effect, this simplifies the RegExpObject constructor a
bit, as it can no longer throw an exception and doesn't have to validate
the flags itself.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
The auto naming of function expressions is a purely syntactic
decision, so shouldn't be decided based on the dynamic type of
an assignment. This moves the decision making into the parser.
One icky hack is that we add a field to FunctionExpression to
indicate whether we can autoname. The real solution is to actually
generate a CompoundExpression node so that the parser can make
the correct decision, however this would have a potentially
significant run time cost.
This does not correct the behaviour for class expressions.
Patch from Anonymous.
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
