summaryrefslogtreecommitdiff
path: root/Libraries/LibJS/Token.cpp
AgeCommit message (Collapse)Author
2020-06-01LibJS: Fix out-of-bounds read when parsing escape sequencesSergey Bugaev
We cannot look at i+1'th character until we verify it's there.
2020-05-18LibJS: Handle hex and unicode escape sequences in string literalsMatthew Olsson
Introduces the following syntax: '\x55' '\u26a0' '\u{1f41e}'
2020-05-04LibJS: Add template literalsmattco98
Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-04-24LibJS: Add TokenType::TemplateLiteralLinus Groh
This is required for template literals - we're not quite there yet, but at least the parser can now tell us when this token is encountered - currently this yields "Unexpected token Invalid". Not really helpful. The character is a "backtick", but as we already have TokenType::{StringLiteral,RegexLiteral} this seemed like a fitting name. This also enables syntax highlighting for template literals in the js REPL and LibGUI's JSSyntaxHighlighter.
2020-04-18LibJS: Allow reserved words as keys in object expressions.Stephan Unverwerth
2020-04-05LibJS: Add numeric literal parsing for different bases and exponentsStephan Unverwerth
2020-04-04LibJS: Hack the lexer to allow numbers with decimalsAndreas Kling
This is very hackish and should definitely be improved. :^)
2020-03-30LibJS: Use some macro magic to avoid duplicating all the token typesAndreas Kling
2020-03-29LibJS: Lexer and parser support for "switch" statementsAndreas Kling
2020-03-21LibJS: Parse object expressions0xtechnobabble
2020-03-16LibJS: Implement null and undefined literals0xtechnobabble
2020-03-14LibJS: Unescape strings in Token::string_value()Stephan Unverwerth
2020-03-14LibJS: Strip double-quote characters from StringLiteral tokensAndreas Kling
This is very hackish since I'm just doing it to make progress on something else. :^)
2020-03-14LibJS: Lex single quote strings, escaped chars and unterminated stringsStephan Unverwerth
2020-03-14LibJS: Add missing tokens to name()Oriko
2020-03-14LibJS: Add operator precedence parsingStephan Unverwerth
Obey precedence and associativity rules when parsing expressions with chained operators.
2020-03-12LibJS: Add Javascript lexer and parserStephan Unverwerth
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.: