Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-30 21:01:00 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Token.h

259 lines
12 KiB
C
Raw Normal View History

LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
/*
Everywhere: Use s.unverwerth@serenityos.org :^)
2021-05-29 12:38:28 +02:00
* Copyright (c) 2020, Stephan Unverwerth <s.unverwerth@serenityos.org>
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
*
Everything: Move to SPDX license identifiers in all files. 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 *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
*/
#pragma once
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
#include <AK/FlyString.h>
LibJS: Remove DeprecatedString usage from Token
2023-01-26 08:38:09 -05:00
#include <AK/String.h>
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
#include <AK/StringView.h>
LibJS: Allow Unicode escape sequences in identifiers 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.
2021-08-18 16:34:25 -04:00
#include <AK/Variant.h>
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
namespace JS {
LibJS: Support all line terminators (LF, CR, LS, PS) https://tc39.es/ecma262/#sec-line-terminators
2020-10-21 22:16:45 +01:00
// U+2028 LINE SEPARATOR
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
constexpr char const line_separator_chars[] { (char)0xe2, (char)0x80, (char)0xa8, 0 };
Everywhere: Use east const in more places 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.
2024-04-18 15:32:56 -04:00
constexpr StringView const LINE_SEPARATOR_STRING { line_separator_chars, sizeof(line_separator_chars) - 1 };
constexpr u32 const LINE_SEPARATOR { 0x2028 };
LibJS: Support all line terminators (LF, CR, LS, PS) https://tc39.es/ecma262/#sec-line-terminators
2020-10-21 22:16:45 +01:00
// U+2029 PARAGRAPH SEPARATOR
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
constexpr char const paragraph_separator_chars[] { (char)0xe2, (char)0x80, (char)0xa9, 0 };
Everywhere: Use east const in more places 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.
2024-04-18 15:32:56 -04:00
constexpr StringView const PARAGRAPH_SEPARATOR_STRING { paragraph_separator_chars, sizeof(paragraph_separator_chars) - 1 };
constexpr u32 const PARAGRAPH_SEPARATOR { 0x2029 };
LibJS: Correctly handle Unicode characters in JS source text Also recognize additional white space characters.
2021-08-14 17:07:47 +02:00
// U+00A0 NO BREAK SPACE
Everywhere: Use east const in more places 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.
2024-04-18 15:32:56 -04:00
constexpr u32 const NO_BREAK_SPACE { 0x00A0 };
LibJS: Correctly handle Unicode characters in JS source text Also recognize additional white space characters.
2021-08-14 17:07:47 +02:00
// U+200C ZERO WIDTH NON-JOINER
Everywhere: Use east const in more places 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.
2024-04-18 15:32:56 -04:00
constexpr u32 const ZERO_WIDTH_NON_JOINER { 0x200C };
LibJS: Correctly handle Unicode characters in JS source text Also recognize additional white space characters.
2021-08-14 17:07:47 +02:00
LibJS: Disallow yield expression correctly in formal parameters And add ZERO WIDTH NO BREAK SPACE to valid whitespace.
2021-08-21 11:31:36 +02:00
// U+FEFF ZERO WIDTH NO-BREAK SPACE
Everywhere: Use east const in more places 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.
2024-04-18 15:32:56 -04:00
constexpr u32 const ZERO_WIDTH_NO_BREAK_SPACE { 0xFEFF };
LibJS: Disallow yield expression correctly in formal parameters And add ZERO WIDTH NO BREAK SPACE to valid whitespace.
2021-08-21 11:31:36 +02:00
LibJS: Correctly handle Unicode characters in JS source text Also recognize additional white space characters.
2021-08-14 17:07:47 +02:00
// U+200D ZERO WIDTH JOINER
Everywhere: Use east const in more places 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.
2024-04-18 15:32:56 -04:00
constexpr u32 const ZERO_WIDTH_JOINER { 0x200D };
LibJS: Support all line terminators (LF, CR, LS, PS) https://tc39.es/ecma262/#sec-line-terminators
2020-10-21 22:16:45 +01:00
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 22:28:59 +01:00
#define ENUMERATE_JS_TOKENS \
__ENUMERATE_JS_TOKEN(Ampersand, Operator) \
__ENUMERATE_JS_TOKEN(AmpersandEquals, Operator) \
__ENUMERATE_JS_TOKEN(Arrow, Operator) \
__ENUMERATE_JS_TOKEN(Asterisk, Operator) \
__ENUMERATE_JS_TOKEN(AsteriskEquals, Operator) \
__ENUMERATE_JS_TOKEN(Async, Keyword) \
__ENUMERATE_JS_TOKEN(Await, Keyword) \
__ENUMERATE_JS_TOKEN(BigIntLiteral, Number) \
__ENUMERATE_JS_TOKEN(BoolLiteral, Keyword) \
__ENUMERATE_JS_TOKEN(BracketClose, Punctuation) \
__ENUMERATE_JS_TOKEN(BracketOpen, Punctuation) \
__ENUMERATE_JS_TOKEN(Break, Keyword) \
__ENUMERATE_JS_TOKEN(Caret, Operator) \
__ENUMERATE_JS_TOKEN(CaretEquals, Operator) \
__ENUMERATE_JS_TOKEN(Case, ControlKeyword) \
__ENUMERATE_JS_TOKEN(Catch, ControlKeyword) \
__ENUMERATE_JS_TOKEN(Class, Keyword) \
__ENUMERATE_JS_TOKEN(Colon, Punctuation) \
__ENUMERATE_JS_TOKEN(Comma, Punctuation) \
__ENUMERATE_JS_TOKEN(Const, Keyword) \
__ENUMERATE_JS_TOKEN(Continue, ControlKeyword) \
__ENUMERATE_JS_TOKEN(CurlyClose, Punctuation) \
__ENUMERATE_JS_TOKEN(CurlyOpen, Punctuation) \
__ENUMERATE_JS_TOKEN(Debugger, Keyword) \
__ENUMERATE_JS_TOKEN(Default, ControlKeyword) \
__ENUMERATE_JS_TOKEN(Delete, Keyword) \
__ENUMERATE_JS_TOKEN(Do, ControlKeyword) \
__ENUMERATE_JS_TOKEN(DoubleAmpersand, Operator) \
LibJS: Implement logical assignment operators (&&=, ||=, ??=) TC39 proposal, stage 4 as of 2020-07. https://tc39.es/proposal-logical-assignment/
2020-10-05 16:49:43 +01:00
__ENUMERATE_JS_TOKEN(DoubleAmpersandEquals, Operator) \
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 22:28:59 +01:00
__ENUMERATE_JS_TOKEN(DoubleAsterisk, Operator) \
LibJS: Implement logical assignment operators (&&=, ||=, ??=) TC39 proposal, stage 4 as of 2020-07. https://tc39.es/proposal-logical-assignment/
2020-10-05 16:49:43 +01:00
__ENUMERATE_JS_TOKEN(DoubleAsteriskEquals, Operator) \
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 22:28:59 +01:00
__ENUMERATE_JS_TOKEN(DoublePipe, Operator) \
LibJS: Implement logical assignment operators (&&=, ||=, ??=) TC39 proposal, stage 4 as of 2020-07. https://tc39.es/proposal-logical-assignment/
2020-10-05 16:49:43 +01:00
__ENUMERATE_JS_TOKEN(DoublePipeEquals, Operator) \
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 22:28:59 +01:00
__ENUMERATE_JS_TOKEN(DoubleQuestionMark, Operator) \
LibJS: Implement logical assignment operators (&&=, ||=, ??=) TC39 proposal, stage 4 as of 2020-07. https://tc39.es/proposal-logical-assignment/
2020-10-05 16:49:43 +01:00
__ENUMERATE_JS_TOKEN(DoubleQuestionMarkEquals, Operator) \
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 22:28:59 +01:00
__ENUMERATE_JS_TOKEN(Else, ControlKeyword) \
__ENUMERATE_JS_TOKEN(Enum, Keyword) \
__ENUMERATE_JS_TOKEN(Eof, Invalid) \
__ENUMERATE_JS_TOKEN(Equals, Operator) \
__ENUMERATE_JS_TOKEN(EqualsEquals, Operator) \
__ENUMERATE_JS_TOKEN(EqualsEqualsEquals, Operator) \
LibJS: Fix some small remaining issues with parsing unicode escapes 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.
2021-08-21 11:27:20 +02:00
__ENUMERATE_JS_TOKEN(EscapedKeyword, Identifier) \
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 22:28:59 +01:00
__ENUMERATE_JS_TOKEN(ExclamationMark, Operator) \
__ENUMERATE_JS_TOKEN(ExclamationMarkEquals, Operator) \
__ENUMERATE_JS_TOKEN(ExclamationMarkEqualsEquals, Operator) \
__ENUMERATE_JS_TOKEN(Export, Keyword) \
__ENUMERATE_JS_TOKEN(Extends, Keyword) \
__ENUMERATE_JS_TOKEN(Finally, ControlKeyword) \
__ENUMERATE_JS_TOKEN(For, ControlKeyword) \
__ENUMERATE_JS_TOKEN(Function, Keyword) \
__ENUMERATE_JS_TOKEN(GreaterThan, Operator) \
__ENUMERATE_JS_TOKEN(GreaterThanEquals, Operator) \
__ENUMERATE_JS_TOKEN(Identifier, Identifier) \
__ENUMERATE_JS_TOKEN(If, ControlKeyword) \
__ENUMERATE_JS_TOKEN(Implements, Keyword) \
__ENUMERATE_JS_TOKEN(Import, Keyword) \
__ENUMERATE_JS_TOKEN(In, Keyword) \
__ENUMERATE_JS_TOKEN(Instanceof, Keyword) \
__ENUMERATE_JS_TOKEN(Interface, Keyword) \
__ENUMERATE_JS_TOKEN(Invalid, Invalid) \
__ENUMERATE_JS_TOKEN(LessThan, Operator) \
__ENUMERATE_JS_TOKEN(LessThanEquals, Operator) \
__ENUMERATE_JS_TOKEN(Let, Keyword) \
__ENUMERATE_JS_TOKEN(Minus, Operator) \
__ENUMERATE_JS_TOKEN(MinusEquals, Operator) \
__ENUMERATE_JS_TOKEN(MinusMinus, Operator) \
__ENUMERATE_JS_TOKEN(New, Keyword) \
__ENUMERATE_JS_TOKEN(NullLiteral, Keyword) \
__ENUMERATE_JS_TOKEN(NumericLiteral, Number) \
__ENUMERATE_JS_TOKEN(Package, Keyword) \
__ENUMERATE_JS_TOKEN(ParenClose, Punctuation) \
__ENUMERATE_JS_TOKEN(ParenOpen, Punctuation) \
__ENUMERATE_JS_TOKEN(Percent, Operator) \
__ENUMERATE_JS_TOKEN(PercentEquals, Operator) \
__ENUMERATE_JS_TOKEN(Period, Operator) \
__ENUMERATE_JS_TOKEN(Pipe, Operator) \
__ENUMERATE_JS_TOKEN(PipeEquals, Operator) \
__ENUMERATE_JS_TOKEN(Plus, Operator) \
__ENUMERATE_JS_TOKEN(PlusEquals, Operator) \
__ENUMERATE_JS_TOKEN(PlusPlus, Operator) \
__ENUMERATE_JS_TOKEN(Private, Keyword) \
LibJS: Lex private identifiers, identifiers prefixed with a '#'
2021-10-08 00:39:17 +02:00
__ENUMERATE_JS_TOKEN(PrivateIdentifier, Identifier) \
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 22:28:59 +01:00
__ENUMERATE_JS_TOKEN(Protected, Keyword) \
__ENUMERATE_JS_TOKEN(Public, Keyword) \
__ENUMERATE_JS_TOKEN(QuestionMark, Operator) \
__ENUMERATE_JS_TOKEN(QuestionMarkPeriod, Operator) \
__ENUMERATE_JS_TOKEN(RegexFlags, String) \
LibJS: Implement logical assignment operators (&&=, ||=, ??=) TC39 proposal, stage 4 as of 2020-07. https://tc39.es/proposal-logical-assignment/
2020-10-05 16:49:43 +01:00
__ENUMERATE_JS_TOKEN(RegexLiteral, String) \
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 22:28:59 +01:00
__ENUMERATE_JS_TOKEN(Return, ControlKeyword) \
__ENUMERATE_JS_TOKEN(Semicolon, Punctuation) \
__ENUMERATE_JS_TOKEN(ShiftLeft, Operator) \
__ENUMERATE_JS_TOKEN(ShiftLeftEquals, Operator) \
__ENUMERATE_JS_TOKEN(ShiftRight, Operator) \
__ENUMERATE_JS_TOKEN(ShiftRightEquals, Operator) \
__ENUMERATE_JS_TOKEN(Slash, Operator) \
__ENUMERATE_JS_TOKEN(SlashEquals, Operator) \
__ENUMERATE_JS_TOKEN(Static, Keyword) \
__ENUMERATE_JS_TOKEN(StringLiteral, String) \
__ENUMERATE_JS_TOKEN(Super, Keyword) \
__ENUMERATE_JS_TOKEN(Switch, ControlKeyword) \
__ENUMERATE_JS_TOKEN(TemplateLiteralEnd, String) \
__ENUMERATE_JS_TOKEN(TemplateLiteralExprEnd, Punctuation) \
__ENUMERATE_JS_TOKEN(TemplateLiteralExprStart, Punctuation) \
__ENUMERATE_JS_TOKEN(TemplateLiteralStart, String) \
__ENUMERATE_JS_TOKEN(TemplateLiteralString, String) \
__ENUMERATE_JS_TOKEN(This, Keyword) \
__ENUMERATE_JS_TOKEN(Throw, ControlKeyword) \
__ENUMERATE_JS_TOKEN(Tilde, Operator) \
__ENUMERATE_JS_TOKEN(TripleDot, Operator) \
LibJS+LibWebView: Treat trivia tokens as comments Trivia is whatever whitespace and comments appear before a token. Previously this was always given a TokenCategory of Invalid, so it would be displayed as an error in the view-source page, with red wiggly underlines. Instead, treat it as what it actually is: whitespace and comments!
2025-03-04 16:36:34 +00:00
__ENUMERATE_JS_TOKEN(Trivia, Trivia) \
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 22:28:59 +01:00
__ENUMERATE_JS_TOKEN(Try, ControlKeyword) \
__ENUMERATE_JS_TOKEN(Typeof, Keyword) \
__ENUMERATE_JS_TOKEN(UnsignedShiftRight, Operator) \
__ENUMERATE_JS_TOKEN(UnsignedShiftRightEquals, Operator) \
__ENUMERATE_JS_TOKEN(UnterminatedRegexLiteral, String) \
__ENUMERATE_JS_TOKEN(UnterminatedStringLiteral, String) \
__ENUMERATE_JS_TOKEN(UnterminatedTemplateLiteral, String) \
__ENUMERATE_JS_TOKEN(Var, Keyword) \
__ENUMERATE_JS_TOKEN(Void, Keyword) \
__ENUMERATE_JS_TOKEN(While, ControlKeyword) \
__ENUMERATE_JS_TOKEN(With, ControlKeyword) \
__ENUMERATE_JS_TOKEN(Yield, ControlKeyword)
LibJS: Use some macro magic to avoid duplicating all the token types
2020-03-30 13:11:07 +02:00
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
enum class TokenType {
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 22:28:59 +01:00
#define __ENUMERATE_JS_TOKEN(type, category) type,
LibJS: Use some macro magic to avoid duplicating all the token types
2020-03-30 13:11:07 +02:00
ENUMERATE_JS_TOKENS
#undef __ENUMERATE_JS_TOKEN
LibJS: Parser refactored to use constexpr precedence table Replaced implementation dependent on HashMap with a constexpr PrecedenceTable based on array lookup.
2020-08-18 19:46:36 +03:00
_COUNT_OF_TOKENS
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
};
LibJS: Parser refactored to use constexpr precedence table Replaced implementation dependent on HashMap with a constexpr PrecedenceTable based on array lookup.
2020-08-18 19:46:36 +03:00
constexpr size_t cs_num_of_js_tokens = static_cast<size_t>(TokenType::_COUNT_OF_TOKENS);
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 22:28:59 +01:00
enum class TokenCategory {
Invalid,
LibJS+LibWebView: Treat trivia tokens as comments Trivia is whatever whitespace and comments appear before a token. Previously this was always given a TokenCategory of Invalid, so it would be displayed as an error in the view-source page, with red wiggly underlines. Instead, treat it as what it actually is: whitespace and comments!
2025-03-04 16:36:34 +00:00
Trivia,
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 22:28:59 +01:00
Number,
String,
Punctuation,
Operator,
Keyword,
ControlKeyword,
Identifier
};
LibJS: Revert Enable EXPLICIT_SYMBOL_EXPORT This reverts commit c14173f651f5a50fdb86beb4b79487454a00f3f6. We should only annotate the minimum number of symbols that external consumers actually use, so I am starting from scratch to do that
2025-07-19 10:41:08 -07:00
class Token {
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
public:
LibJS: Allow Unicode escape sequences in identifiers 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.
2021-08-18 16:34:25 -04:00
Token() = default;
LibJS: Remove unused field Token::m_filename
2024-09-02 11:14:18 +02:00
Token(TokenType type, StringView message, StringView trivia, StringView value, size_t line_number, size_t line_column, size_t offset)
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
: m_type(type)
LibJS: Make Token::m_message a StringView This is only ever a string literal, so there's no need to keep creating the same strings at runtime.
2024-03-23 11:38:58 +01:00
, m_message(message)
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
, m_trivia(trivia)
LibJS: Allow Unicode escape sequences in identifiers 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.
2021-08-18 16:34:25 -04:00
, m_original_value(value)
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
, m_value(value)
LibJS: Plumb line and column information through Lexer / Parser While debugging test failures, it's pretty frustrating to have to go do printf debugging to figure out what test is failing right now. While watching your JS Raytracer stream it seemed like this was pretty furstrating as well. So I wanted to start working on improving the diagnostics here. In the future I hope we can eventually be able to plumb the info down to the Error classes so any thrown exceptions will contain enough metadata to know where they came from.
2020-04-05 02:34:03 -07:00
, m_line_number(line_number)
, m_line_column(line_column)
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
, m_offset(offset)
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
{
}
TokenType type() const { return m_type; }
LibJS: Unify syntax highlighting So far we have three different syntax highlighters for LibJS: - js's Line::Editor stylization - JS::MarkupGenerator - GUI::JSSyntaxHighlighter This not only caused repetition of most token types in each highlighter but also a lot of inconsistency regarding the styling of certain tokens: - JSSyntaxHighlighter was considering TokenType::Period to be an operator whereas MarkupGenerator categorized it as punctuation. - MarkupGenerator was considering TokenType::{Break,Case,Continue, Default,Switch,With} control keywords whereas JSSyntaxHighlighter just disregarded them - MarkupGenerator considered some future reserved keywords invalid and others not. JSSyntaxHighlighter and js disregarded most Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well as each individual highlighter's switch/case construct. I added a TokenCategory enum, and each TokenType is now associated to a certain category, which the syntax highlighters then can use for styling rather than operating on the token type directly. This also makes changing a token's category everywhere easier, should we need to do that (e.g. I decided to make TokenType::{Period,QuestionMarkPeriod} TokenCategory::Operator for now, but we might want to change them to Punctuation.
2020-10-04 22:28:59 +01:00
TokenCategory category() const;
static TokenCategory category(TokenType);
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
char const* name() const;
static char const* name(TokenType);
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
LibJS: Make Token::m_message a StringView This is only ever a string literal, so there's no need to keep creating the same strings at runtime.
2024-03-23 11:38:58 +01:00
StringView message() const { return m_message; }
Everywhere: Pass AK::StringView by value
2021-11-11 00:55:02 +01:00
StringView trivia() const { return m_trivia; }
StringView original_value() const { return m_original_value; }
LibJS: Allow Unicode escape sequences in identifiers 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.
2021-08-18 16:34:25 -04:00
StringView value() const
{
return m_value.visit(
Everywhere: Pass AK::StringView by value
2021-11-11 00:55:02 +01:00
[](StringView view) { return view; },
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
[](FlyString const& identifier) { return identifier.bytes_as_string_view(); },
LibJS: Allow Unicode escape sequences in identifiers 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.
2021-08-18 16:34:25 -04:00
[](Empty) -> StringView { VERIFY_NOT_REACHED(); });
}
LibJS: Add Token::flystring_value() to produce FlyString directly When parsing identifiers, we ultimately want to sink the token string into a FlyString anyway, and since Token may have a FlyString already inside it, this allows us to bypass the costly FlyString(StringView). This gives a ~3% speedup when parsing the largest Discord JS file.
2022-02-13 13:22:12 +01:00
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
FlyString fly_string_value() const
LibJS: Add Token::flystring_value() to produce FlyString directly When parsing identifiers, we ultimately want to sink the token string into a FlyString anyway, and since Token may have a FlyString already inside it, this allows us to bypass the costly FlyString(StringView). This gives a ~3% speedup when parsing the largest Discord JS file.
2022-02-13 13:22:12 +01:00
{
return m_value.visit(
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
[](StringView view) -> FlyString { return MUST(FlyString::from_utf8(view)); },
[](FlyString const& identifier) -> FlyString { return identifier; },
[](Empty) -> FlyString { VERIFY_NOT_REACHED(); });
LibJS: Add Token::flystring_value() to produce FlyString directly When parsing identifiers, we ultimately want to sink the token string into a FlyString anyway, and since Token may have a FlyString already inside it, this allows us to bypass the costly FlyString(StringView). This gives a ~3% speedup when parsing the largest Discord JS file.
2022-02-13 13:22:12 +01:00
}
LibJS: Plumb line and column information through Lexer / Parser While debugging test failures, it's pretty frustrating to have to go do printf debugging to figure out what test is failing right now. While watching your JS Raytracer stream it seemed like this was pretty furstrating as well. So I wanted to start working on improving the diagnostics here. In the future I hope we can eventually be able to plumb the info down to the Error classes so any thrown exceptions will contain enough metadata to know where they came from.
2020-04-05 02:34:03 -07:00
size_t line_number() const { return m_line_number; }
size_t line_column() const { return m_line_column; }
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
size_t offset() const { return m_offset; }
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
double double_value() const;
bool bool_value() const;
LibJS: Handle hex and unicode escape sequences in string literals Introduces the following syntax: '\x55' '\u26a0' '\u{1f41e}'
2020-05-16 23:27:25 -07:00
enum class StringValueStatus {
Ok,
MalformedHexEscape,
MalformedUnicodeEscape,
UnicodeEscapeOverflow,
LibJS: Support LegacyOctalEscapeSequence in string literals https://tc39.es/ecma262/#sec-additional-syntax-string-literals The syntax and semantics of 11.8.4 is extended as follows except that this extension is not allowed for strict mode code: Syntax EscapeSequence:: CharacterEscapeSequence LegacyOctalEscapeSequence NonOctalDecimalEscapeSequence HexEscapeSequence UnicodeEscapeSequence LegacyOctalEscapeSequence:: OctalDigit [lookahead ∉ OctalDigit] ZeroToThree OctalDigit [lookahead ∉ OctalDigit] FourToSeven OctalDigit ZeroToThree OctalDigit OctalDigit ZeroToThree :: one of 0 1 2 3 FourToSeven :: one of 4 5 6 7 NonOctalDecimalEscapeSequence :: one of 8 9 This definition of EscapeSequence is not used in strict mode or when parsing TemplateCharacter. Note It is possible for string literals to precede a Use Strict Directive that places the enclosing code in strict mode, and implementations must take care to not use this extended definition of EscapeSequence with such literals. For example, attempting to parse the following source text must fail: function invalid() { "\7"; "use strict"; }
2020-10-24 13:30:57 +01:00
LegacyOctalEscapeSequence,
LibJS: Handle hex and unicode escape sequences in string literals Introduces the following syntax: '\x55' '\u26a0' '\u{1f41e}'
2020-05-16 23:27:25 -07:00
};
Everywhere: Rename {Deprecated => Byte}String 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')
2023-12-16 17:49:34 +03:30
ByteString string_value(StringValueStatus& status) const;
ByteString raw_template_value() const;
LibJS: Handle hex and unicode escape sequences in string literals Introduces the following syntax: '\x55' '\u26a0' '\u{1f41e}'
2020-05-16 23:27:25 -07:00
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
void set_identifier_value(FlyString value)
LibJS: Clean up token constructor and use method instead for identifiers Having two large constructor with just one parameter difference in the middle seems quite dangerous so just do it with a method.
2021-09-01 18:35:33 +02:00
{
m_value = move(value);
}
LibJS: Allow reserved words as keys in object expressions.
2020-04-18 20:31:27 +02:00
bool is_identifier_name() const;
LibJS: Support all line terminators (LF, CR, LS, PS) https://tc39.es/ecma262/#sec-line-terminators
2020-10-21 22:16:45 +01:00
bool trivia_contains_line_terminator() const;
LibJS: Allow reserved words as keys in object expressions.
2020-04-18 20:31:27 +02:00
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
private:
LibJS: Allow Unicode escape sequences in identifiers 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.
2021-08-18 16:34:25 -04:00
TokenType m_type { TokenType::Invalid };
LibJS: Make Token::m_message a StringView This is only ever a string literal, so there's no need to keep creating the same strings at runtime.
2024-03-23 11:38:58 +01:00
StringView m_message;
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
StringView m_trivia;
LibJS: Allow Unicode escape sequences in identifiers 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.
2021-08-18 16:34:25 -04:00
StringView m_original_value;
LibJS: Use FlyString in PropertyKey instead of DeprecatedFlyString This required dealing with *substantial* fallout.
2025-03-18 18:08:02 -05:00
Variant<Empty, StringView, FlyString> m_value {};
LibJS: Allow Unicode escape sequences in identifiers 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.
2021-08-18 16:34:25 -04:00
size_t m_line_number { 0 };
size_t m_line_column { 0 };
size_t m_offset { 0 };
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
};
}
Reference in a new issue Copy permalink