ES2015 (ES6) support #15
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
metatoaster
force-pushed
the
es2015
branch
3 times, most recently
from
9fd68d7 to
d8bd376
Compare
metatoaster
force-pushed
the
es2015
branch
2 times, most recently
from
42c6f5b to
58ed10f
Compare
metatoaster
force-pushed
the
es2015
branch
2 times, most recently
from
1faef6e to
339a9d0
Compare
metatoaster
force-pushed
the
es2015
branch
2 times, most recently
from
9fb50df to
912db9d
Compare
|
Wow can I just say this is awesome! This work should receive way more attention because it is super important! |
- Provide support of the spread operator and arrow function, along with
naive support of the template literal.
- The template literal currently does NOT have awareness of available
identifiers and the like, it's just a dumb string with a funny quote
for this initial implementation.
- Contains fixes to the regex rules introduced in commits authored later
than the initial author date of this commit.
- Implement the lookahead and properly check the newlines. - However, that whole escape sequence check might have to be done _inside_ the token formation as this is still going to fail valid input templates such as `foo \ bar` when it will reduce to effectively `foo bar`, rather than a syntax error. Likewise for string literals.
- Mark the generated tokens with the appropriate types.
- Use an excess of extra tokens relevant to this particular syntax.
- This is basically identical to the ES5 parser at this point, with the references modify to reflect the ES2015 intent that this parser will handle. - Additional changes since the initial cut have been squashed into this commit to match as close to the current implementation and tests, including: - Fix to disambiguation of DIV vs. REGEX lexer tokens.
- The parser can now parse template literals from tokens produced by the lexer and produce the ast with the new asttypes for templates. - Initial set of test cases included, however there are certain limitations which have been found that needed correction in the lexer itself.
- This must be done as templates can nest templates - Not to mention the fact that objects can be provided as values. Given they share the RBRACE symbol, there needs to be a way to disambiguate that symbol for objects and the opening of the template middle/tail fragments.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently just started so this is a complete work in progress. Absolutely no ETA at the moment because I can only spare hobby level time to work on this.
A very rough outline of what needs to be done