-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Preserve string delimiter in type printing. #60729
base: main
Are you sure you want to change the base?
Preserve string delimiter in type printing. #60729
Conversation
src/compiler/checker.ts
Outdated
if (!nodeIsSynthesized(range) || !(range.flags & NodeFlags.Synthesized) || !context.enclosingFile || context.enclosingFile !== nodeSourceFile) { | ||
if (range.kind === SyntaxKind.StringLiteral) { | ||
const stringLiteral = range as Node as StringLiteral; | ||
range = factory.createStringLiteral(stringLiteral.text, !!nodeSourceFile && !isStringDoubleQuoted(stringLiteral, nodeSourceFile)) as Node as T; |
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.
This could instead use factory.createStringLiteralFromNode(stringLiteral)
as that should pull the string's text from its original file.
We looked at this in the design meeting; the general consensus is that this is good for declaration files, but the fact that error messages are changing quote styles seems to be wrong; we should try and make diagnostic type printing normalize to |
Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page. Also, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up. |
@@ -6040,13 +6048,28 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker { | |||
} | |||
} | |||
|
|||
/** | |||
* Prints a type, forcing the conversion of string delimiters to " | |||
* This should usually be used for errors, since in errors printed types are inclosed in ' |
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.
* This should usually be used for errors, since in errors printed types are inclosed in ' | |
* This should usually be used for errors, since in errors printed types are enclosed in ' | |
@@ -8,7 +8,7 @@ declare namespace demoNS { | |||
>f : Symbol(f, Decl(demo.d.ts, 0, 26)) | |||
} | |||
declare module 'demoModule' { | |||
>'demoModule' : Symbol("demoModule", Decl(demo.d.ts, 2, 1)) | |||
>'demoModule' : Symbol('demoModule', Decl(demo.d.ts, 2, 1)) |
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.
I'm surprised to see symbol baselines change; were we inconsistent with these before?
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.
Symbol printing is involved in type printing and error printing. I applied the 'preserve source code delimiters in everything except errors' to the symbol printing too. This does mean that the delimiters are now preserved in symbol baselines where they previously were not.
Were they always replaced before? Don't think so. Some error messages used symbol printing for the property names and we can see in error baselines changes that some of those kept the '
delimiter instead of having it replaced with "
"text": "\"resolution-mode\"", | ||
"kind": "stringLiteral" | ||
"kind": "propertyName" | ||
}, |
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.
This is funky; I'm not sure how much this matters in practice, though...
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.
Agreed, but it was already the case that some strings would be marked as things other than text in display parts.
Before, in symbol printing, some identifiers were created that didn't actually have an identifier valid text (identifier name was a string including delimiters). These identifiers had their symbol set, and during display part emit, they were marked as whatever kind of symbol they had attached. However this did not happene for all string created during symbol printing. So we had some parts of symbol names as identifiers with symbol and invalid text, and some as string literals with no symbol.
Now, I create string literals and number literals for all symbol names which are not valid identifiers and set the symbol on those too. This does mean that some parts of the symbol name now have the symbol attached to then (where before they did not) and can have the correct kind set in display parts.
These are the changes in symbolToExpression
in checker.ts and the changes to emitLiteral
in emitter.ts
~ | ||
!!! error TS2741: Property ''1'' is missing in type 'T' but required in type 'S'. | ||
!!! related TS2728 assignmentCompatWithObjectMembersStringNumericNames.ts:5:15: ''1'' is declared here. | ||
!!! error TS2741: Property '"1"' is missing in type 'T' but required in type 'S'. | ||
!!! related TS2728 assignmentCompatWithObjectMembersStringNumericNames.ts:5:15: '"1"' is declared 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.
🎉
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.
I read through all of the baselines; mostly seems correct, with some odd escaping changes, and I would like someone familiar with those displayParts to weigh in on those changes.
>sameName5a : Symbol(sameName5a, Decl(objectLiteralGettersAndSetters.ts, 5, 3)) | ||
>'\t' : Symbol('\t', Decl(objectLiteralGettersAndSetters.ts, 5, 18), Decl(objectLiteralGettersAndSetters.ts, 5, 45)) | ||
>'\t' : Symbol('\t', Decl(objectLiteralGettersAndSetters.ts, 5, 18), Decl(objectLiteralGettersAndSetters.ts, 5, 45)) | ||
>'\t' : Symbol('t', Decl(objectLiteralGettersAndSetters.ts, 5, 18), Decl(objectLiteralGettersAndSetters.ts, 5, 45)) | ||
>'\t' : Symbol('t', Decl(objectLiteralGettersAndSetters.ts, 5, 18), Decl(objectLiteralGettersAndSetters.ts, 5, 45)) | ||
>n : Symbol(n, Decl(objectLiteralGettersAndSetters.ts, 5, 55)) |
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.
Where did the \
go?
@@ -92,7 +92,7 @@ var a: { | |||
>"a b" : Symbol("a b", Decl(objectTypeWithStringNamedPropertyOfIllegalCharacters.ts, 30, 18)) | |||
|
|||
"~!@#$%^&*()_+{}|:'<>?\/.,`": number; | |||
>"~!@#$%^&*()_+{}|:'<>?\/.,`" : Symbol("~!@#$%^&*()_+{}|:'<>?\/.,`", Decl(objectTypeWithStringNamedPropertyOfIllegalCharacters.ts, 31, 20)) | |||
>"~!@#$%^&*()_+{}|:'<>?\/.,`" : Symbol("~!@#$%^&*()_+{}|:'<>?/.,`", Decl(objectTypeWithStringNamedPropertyOfIllegalCharacters.ts, 31, 20)) |
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.
This escaping is also gone, which is odd...
>x : Symbol(x, Decl(stringLiteralPropertyNameWithLineContinuation1.ts, 0, 3)) | ||
>'text\' : Symbol('text\ | ||
', Decl(stringLiteralPropertyNameWithLineContinuation1.ts, 0, 9)) | ||
>'text\' : Symbol('text\\\n', Decl(stringLiteralPropertyNameWithLineContinuation1.ts, 0, 9)) | ||
|
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.
This is certainly an improvement
Related to #60540
This PR shows what the impact of preserving string delimiters in type printing would be.
cc: @jakebailey @weswigham