beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-25 09:00:22 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 7
ladybird/Userland/Libraries/LibJS/Token.h

258 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 18:27:43 +00:00
/*
Everywhere: Use s.unverwerth@serenityos.org :^)
2021-05-29 10:38:28 +00: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 18:27:43 +00: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 08:24:48 +00: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 18:27:43 +00:00
*/
#pragma once
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 20:34:25 +00:00
#include <AK/FlyString.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 18:27:43 +00:00
#include <AK/String.h>
#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 20:34:25 +00: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 18:27:43 +00:00
namespace JS {
LibJS: Support all line terminators (LF, CR, LS, PS) https://tc39.es/ecma262/#sec-line-terminators
2020-10-21 21:16:45 +00:00
// U+2028 LINE SEPARATOR
constexpr const char line_separator_chars[] { (char)0xe2, (char)0x80, (char)0xa8, 0 };
LibJS: Correctly handle Unicode characters in JS source text Also recognize additional white space characters.
2021-08-14 15:07:47 +00:00
constexpr const StringView LINE_SEPARATOR_STRING { line_separator_chars };
constexpr const u32 LINE_SEPARATOR { 0x2028 };
LibJS: Support all line terminators (LF, CR, LS, PS) https://tc39.es/ecma262/#sec-line-terminators
2020-10-21 21:16:45 +00:00
// U+2029 PARAGRAPH SEPARATOR
constexpr const char paragraph_separator_chars[] { (char)0xe2, (char)0x80, (char)0xa9, 0 };
LibJS: Correctly handle Unicode characters in JS source text Also recognize additional white space characters.
2021-08-14 15:07:47 +00:00
constexpr const StringView PARAGRAPH_SEPARATOR_STRING { paragraph_separator_chars };
constexpr const u32 PARAGRAPH_SEPARATOR { 0x2029 };
// U+00A0 NO BREAK SPACE
constexpr const u32 NO_BREAK_SPACE { 0x00A0 };
// U+200C ZERO WIDTH NON-JOINER
constexpr const u32 ZERO_WIDTH_NON_JOINER { 0x200C };
LibJS: Disallow yield expression correctly in formal parameters And add ZERO WIDTH NO BREAK SPACE to valid whitespace.
2021-08-21 09:31:36 +00:00
// U+FEFF ZERO WIDTH NO-BREAK SPACE
constexpr const u32 ZERO_WIDTH_NO_BREAK_SPACE { 0xFEFF };
LibJS: Correctly handle Unicode characters in JS source text Also recognize additional white space characters.
2021-08-14 15:07:47 +00:00
// U+200D ZERO WIDTH JOINER
constexpr const u32 ZERO_WIDTH_JOINER { 0x200D };
LibJS: Support all line terminators (LF, CR, LS, PS) https://tc39.es/ecma262/#sec-line-terminators
2020-10-21 21:16:45 +00: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 21:28:59 +00: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 15:49:43 +00: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 21:28:59 +00: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 15:49:43 +00: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 21:28:59 +00: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 15:49:43 +00: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 21:28:59 +00: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 15:49:43 +00: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 21:28:59 +00: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 09:27:20 +00: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 21:28:59 +00: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) \
__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 15:49:43 +00: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 21:28:59 +00: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) \
__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 11:11:07 +00: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 18:27:43 +00: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 21:28:59 +00:00
#define __ENUMERATE_JS_TOKEN(type, category) type,
LibJS: Use some macro magic to avoid duplicating all the token types
2020-03-30 11:11:07 +00: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 16:46:36 +00: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 18:27:43 +00: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 16:46:36 +00: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 18:27:43 +00: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 21:28:59 +00:00
enum class TokenCategory {
Invalid,
Number,
String,
Punctuation,
Operator,
Keyword,
ControlKeyword,
Identifier
};
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 18:27:43 +00:00
class Token {
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 20:34:25 +00:00
Token() = default;
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-10 20:46:17 +00:00
Token(TokenType type, String message, StringView trivia, StringView value, StringView filename, 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 18:27:43 +00:00
: m_type(type)
LibJS: Add message string to Token This allows us to communicate details about invalid tokens to the parser without having to invent a bunch of specific invalid tokens like TokenType::InvalidNumericLiteral.
2020-10-26 20:08:01 +00: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 18:27:43 +00: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 20:34:25 +00: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 18:27:43 +00:00
, m_value(value)
LibJS: Keep track of file names, lines and columns inside the AST
2021-02-28 09:42:34 +00:00
, m_filename(filename)
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 09:34:03 +00: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-10 20:46:17 +00:00
, 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 18:27:43 +00:00
{
}
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 20:34:25 +00:00
Token(TokenType type, String message, StringView trivia, StringView original_value, FlyString value, StringView filename, size_t line_number, size_t line_column, size_t offset)
: m_type(type)
, m_message(message)
, m_trivia(trivia)
, m_original_value(original_value)
, m_value(move(value))
, m_filename(filename)
, m_line_number(line_number)
, m_line_column(line_column)
, 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 18:27:43 +00: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 21:28:59 +00:00
TokenCategory category() const;
static TokenCategory category(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 18:27:43 +00:00
const char* name() const;
static const char* name(TokenType);
LibJS: Add message string to Token This allows us to communicate details about invalid tokens to the parser without having to invent a bunch of specific invalid tokens like TokenType::InvalidNumericLiteral.
2020-10-26 20:08:01 +00:00
const String& message() const { return 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 18:27:43 +00:00
const StringView& trivia() const { return 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 20:34:25 +00:00
const StringView& original_value() const { return m_original_value; }
StringView value() const
{
return m_value.visit(
[](StringView const& view) { return view; },
[](FlyString const& identifier) { return identifier.view(); },
[](Empty) -> StringView { VERIFY_NOT_REACHED(); });
}
LibJS: Keep track of file names, lines and columns inside the AST
2021-02-28 09:42:34 +00:00
const StringView& filename() const { return m_filename; }
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 09:34:03 +00: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-10 20:46:17 +00:00
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 18:27:43 +00: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-17 06:27:25 +00: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 12:30:57 +00:00
LegacyOctalEscapeSequence,
LibJS: Handle hex and unicode escape sequences in string literals Introduces the following syntax: '\x55' '\u26a0' '\u{1f41e}'
2020-05-17 06:27:25 +00:00
};
String string_value(StringValueStatus& status) const;
LibJS: Fix that windows style line endings were not ignored or converted 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.
2021-09-01 16:34:19 +00:00
String raw_template_value() const;
LibJS: Handle hex and unicode escape sequences in string literals Introduces the following syntax: '\x55' '\u26a0' '\u{1f41e}'
2020-05-17 06:27:25 +00:00
LibJS: Allow reserved words as keys in object expressions.
2020-04-18 18:31:27 +00: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 21:16:45 +00:00
bool trivia_contains_line_terminator() const;
LibJS: Allow reserved words as keys in object expressions.
2020-04-18 18:31:27 +00: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 18:27:43 +00: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 20:34:25 +00:00
TokenType m_type { TokenType::Invalid };
LibJS: Add message string to Token This allows us to communicate details about invalid tokens to the parser without having to invent a bunch of specific invalid tokens like TokenType::InvalidNumericLiteral.
2020-10-26 20:08:01 +00:00
String 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 18:27:43 +00: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 20:34:25 +00:00
StringView m_original_value;
Variant<Empty, StringView, FlyString> m_value { Empty {} };
LibJS: Keep track of file names, lines and columns inside the AST
2021-02-28 09:42:34 +00:00
StringView m_filename;
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 20:34:25 +00: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 18:27:43 +00:00
};
}
Reference in a new issue Copy permalink