-
Notifications
You must be signed in to change notification settings - Fork 12.8k
fix(54760): Report error for 'declare type' followed by newline #54761
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The following TypeScript code does not report a diagnostic. Instead, the TypeScript copmiler parses the code as if ASI was applied between two tokens on the same line: var declare, type, T; declare /*ASI*/ type /*ASI*/ T = null; I think this behavior is confusing. TypeScript v4.3.5 used to report a diagnostic for this code, which I think is better than the current behavior of allowing this code without any diagnostic. Instead of performing ASI between 'declare' and 'type', report a diagnostic telling the user that a newline shouldn't be written after 'type'.
declare type /*unexpected newline*/ | ||
T1 = null; | ||
~~ | ||
!!! error TS1142: Line break not permitted here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question for reviewers: I don't like the placement of the diagnostic, but I don't know TypeScript diagnostic conventions. Is here fine or should it point to the type
keyword on the previous line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can give a specialized diagnostic, but I think this is actually fine as-is.
This looks good but...shouldn't there be a |
The test has |
Ah - maybe I'm being a stickler, but if we turn that off and switch the line to - var declare, type, T;
+ var declare: string, type: number, T: boolean; we can get a slightly better sense of how TypeScript itself is parsing. It would also be good to detect whether or not + var x: T1, y: T2; |
Good idea. I updated this pull request. I also included an explanation for each test case. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Though you'll need to accept baselines.
src/compiler/parser.ts
Outdated
@@ -7093,13 +7093,20 @@ namespace Parser { | |||
case SyntaxKind.PrivateKeyword: | |||
case SyntaxKind.ProtectedKeyword: | |||
case SyntaxKind.PublicKeyword: | |||
case SyntaxKind.ReadonlyKeyword: | |||
case SyntaxKind.ReadonlyKeyword: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: I know it helps with scope hygiene, but since the rest of the codebase avoids it, I'd rather we didn't add braces unless necessary.
case SyntaxKind.ReadonlyKeyword: { | |
case SyntaxKind.ReadonlyKeyword: |
src/compiler/parser.ts
Outdated
continue; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
} |
It looks like this pull request was approved. When can I expect it to be merged? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but I would probably consider making that change suggested by Daniel.
Usually it's the assignee that drives a PR to completion but I'm happy to click the button for parser changes like this.
@strager If you don't have the time to make the change, I'm happy to push it onto the PR. |
Also add some comments.
Almost forgot @typescript-bot test this |
Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at f2190c4. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at f2190c4. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at f2190c4. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the abridged perf test suite on this PR at f2190c4. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the extended test suite on this PR at f2190c4. You can monitor the build here. |
@jakebailey Here they are:Comparison Report - main..54761
System
Hosts
Scenarios
Developer Information: |
@jakebailey Here are the results of running the user test suite comparing There were infrastructure failures potentially unrelated to your change:
Otherwise... Something interesting changed - please have a look. Details
|
@jakebailey Here are the results of running the top-repos suite comparing Everything looks good! |
Hey @jakebailey, the results of running the DT tests are ready. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The following TypeScript code does not report a diagnostic. Instead, the TypeScript copmiler parses the code as if ASI was applied between two tokens on the same line:
I think this behavior is confusing. TypeScript v4.3.5 used to report a diagnostic for this code, which I think is better than the current behavior of allowing this code without any diagnostic.
Instead of performing ASI between 'declare' and 'type', report a diagnostic telling the user that a newline shouldn't be written after 'type'.
Fixes #54760