Uh oh!
There was an error while loading. Please reload this page.
add support for Lift Template Literal Restriction - #23801
Conversation
| } | ||
| /* @internal */ | ||
| export function isHexDigit(ch: number): boolean { |
There was a problem hiding this comment.
Neither of these are used outside of scanner.ts, so just don't export them.
| reScanSlashToken(): SyntaxKind; | ||
| reScanTemplateToken(): SyntaxKind; | ||
| reScanTemplateToken(isTaggedTemplate?: boolean): SyntaxKind; | ||
| reScanTemplateHead(): SyntaxKind; |
There was a problem hiding this comment.
Mohamed Hegazy (@mhegazy), thoughts on just having reScanTemplateToken operate on template heads as well? The implementation could have a Debug.assert like so:
if(token!==SyntaxKind.TemplateHead){Debug.assert(isTaggedTemplate,"'reScanTemplateToken' should only be called with a template head when in a tagged template.");}else{Debug.assert(token===SyntaxKind.CloseBraceToken,"'reScanTemplateToken' should only be called on a '}' or TemplateHead.");}
Daniel Rosenwasser (DanielRosenwasser)
left a comment
There was a problem hiding this comment.
I haven't looked too closely at the logic yet, but the general mechanism between the parser and the scanner looks close to what I would've done, so that's good!
I think what we also need is tests for es5 and es2015. One thing we need to discuss is whether the es2015 target needs the downleveled version.
| kind: SyntaxKind.TemplateHead; | ||
| parent?: TemplateExpression; | ||
| /* @internal */ | ||
| notEscapeFlags?: TokenFlags; |
There was a problem hiding this comment.
Consider just calling these templateFlags.
| BinarySpecifier = 1 << 7, // e.g. `0b0110010000000000` | ||
| OctalSpecifier = 1 << 8, // e.g. `0o777` | ||
| ContainsSeparator = 1 << 9, // e.g. `0b1100_0101` | ||
| NotEscape = 1 << 10, // e.g. `\uhello` |
There was a problem hiding this comment.
ContainsInvalidEscape
Wenlu Wang (Kingwl)
commented
May 2, 2018
In my memory, there are several issues related to escape sequences (es2015) that can be fixed together |
Wenlu Wang (Kingwl)
commented
May 2, 2018
wow, seems ci is upgrade😄 |
| } | ||
| function parseTemplateExpression(): TemplateExpression { | ||
| function parseNoSubstitutionTemplate(isTaggedTemplate?: boolean) { |
There was a problem hiding this comment.
There's no public API, just make this parameter required.
| @@ -0,0 +1,47 @@ | |||
| tests/cases/conformance/es2018/invalidTaggedTemplateEscapeSequences.ts(5,18): error TS1125: Hexadecimal digit expected. | |||
There was a problem hiding this comment.
We still need to figure out exactly how to prevent the errors from the initial scan...
Wenlu Wang (Kingwl)
commented
May 7, 2018
should this move to es2018 transform? |
I would say yes, but only run conditionally. So you only use the ES5-style transformed syntax when an "invalid escape" template string is used, but leave it alone otherwise in the ES2018 transform. |
Also, I'm not sure if you want to share that logic between each transform, or to just do the ES2015 transform in ES2018. Ron Buckton (@rbuckton) might have a better idea here. |
Ron Buckton (rbuckton)
commented
May 9, 2018
I think the best approach would be to do something similar to what we do for destructuring and pull the logic for template literal down-leveling out of both places. You can then have the esnext.ts transform call this separate API for the tagged templates that need it, and the es2015.ts transform can call it for all tagged templates. |
Ron Buckton (rbuckton)
commented
May 9, 2018
Not the ES2018 transform, since this is not part of ES2018. Rather, this should go in the esnext.ts transform. |
Wenlu Wang (Kingwl)
commented
May 10, 2018
is that mean i should add a new transformer, eg: taggedTemplate.ts and export the parse function, call the function in es2015 or esnext transformer? |
Mohamed Hegazy (mhegazy)
commented
May 23, 2018
we already have esnext transform. i would put it there.. |
e92b6bc to
2f49205CompareWenlu Wang (Kingwl)
commented
Jun 6, 2018
⬆ |
Sorry, I didn't have full context as I was reviewing this. Please ignore the last batch of comments. |
Wenlu Wang (Kingwl)
commented
Jun 8, 2018
Daniel Rosenwasser (@DanielRosenwasser) there are a other commit that i miss |
2f49205 to
e92b6bcCompareWenlu Wang (Kingwl)
commented
Jun 8, 2018
ahhh, Sure enough it committed in my another pc |
Mohamed Hegazy (mhegazy)
commented
Jun 8, 2018
Ron Buckton (@rbuckton) can you take a look. |
Ryan Cavanaugh (RyanCavanaugh)
left a comment
There was a problem hiding this comment.
Wenlu Wang (@Kingwl) sorry for the delay on this. One last change while you're working on the merge conflicts -- please use the multi-target feature of the test baselines (e.g. @target: es5, es2016) to reduce code duplication. Thanks for the great work here!
Marking as tentative Approve
Wenlu Wang (Kingwl)
commented
Jan 13, 2020
TypeScript Bot (@typescript-bot) pack this |
Heya Wenlu Wang (@Kingwl), I've started to run the tarball bundle task on this PR at 569b35e. You can monitor the build here. It should now contribute to this PR's status checks. |
Nathan Shively-Sanders (sandersn)
commented
Feb 5, 2020
One last CI run and I will merge this. |
Nathan Shively-Sanders (sandersn)
commented
Feb 5, 2020
Oh no, it failed on the lint rules we just enabled! I pushed a new commit. |
Wenlu Wang (Kingwl)
commented
Feb 5, 2020
What is the meaning of |
Nathan Shively-Sanders (sandersn)
commented
Feb 5, 2020
Wenlu Wang (@Kingwl) the PR is intended to fix a bug that has been accepted into a milestone. That contrasts with "For Backlog Bug", which are PRs intended to fix a backlog bug. This PR technically fixes a backlog bug, but it's an Ecmascript conformance bug, so I think it should have been put in a milestone long ago. |
Wenlu Wang (Kingwl)
commented
Feb 6, 2020
TypeScript Bot (@typescript-bot) pack this. |
Heya Wenlu Wang (@Kingwl), I've started to run the tarball bundle task on this PR at f8b9bbb. You can monitor the build here. It should now contribute to this PR's status checks. |
This problem was introduced in 70399e1 (from PR microsoft#23801), which added a `visitTaggedTemplateExpression` case for `TaggedTemplateExpression`, before that, it would fallback to the default of `visitNode`. So re-add that happen in `processTaggedTemplateExpression`. Since it doesn't hurt, I left a `Debug.checkDefined(property.name)` instead of `!`-ing it. Fixesmicrosoft#38558.
This problem was introduced in 70399e1 (from PR microsoft#23801), which added a `visitTaggedTemplateExpression` case for `TaggedTemplateExpression`, before that, it would fallback to the default of `visitNode`. So re-add that happen in `processTaggedTemplateExpression`. Since it doesn't hurt, I left a `Debug.checkDefined(property.name)` instead of `!`-ing it. Fixesmicrosoft#38558.
This problem was introduced in 70399e1 (from PR #23801), which added a `visitTaggedTemplateExpression` case for `TaggedTemplateExpression`, before that, it would fallback to the default of `visitNode`. So re-add that happen in `processTaggedTemplateExpression`. Since it doesn't hurt, I left a `Debug.checkDefined(property.name)` instead of `!`-ing it. Fixes#38558.
Fixes#12700