Preserve string delimiter in type printing. #60729

dragomirtitian · 2024-12-10T17:08:36Z

Related to #60540

This PR shows what the impact of preserving string delimiters in type printing would be.

tests/baselines/reference/ambientErrors.types

rbuckton · 2024-12-13T17:45:42Z

src/compiler/checker.ts

+            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;


This could instead use factory.createStringLiteralFromNode(stringLiteral) as that should pull the string's text from its original file.

jakebailey · 2024-12-13T19:19:23Z

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 " quotes because that's what our messages assume happen.

typescript-bot · 2024-12-18T17:35:15Z

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.

robpalme · 2024-12-18T18:40:47Z

src/compiler/checker.ts

@@ -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 '


Suggested change

* 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 '

jakebailey · 2024-12-18T20:17:48Z

tests/baselines/reference/aliasDoesNotDuplicateSignatures.symbols

@@ -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))


I'm surprised to see symbol baselines change; were we inconsistent with these before?

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 "

jakebailey · 2024-12-18T20:22:05Z

tests/baselines/reference/completionListForImportAttributes.baseline

              "text": "\"resolution-mode\"",
-              "kind": "stringLiteral"
+              "kind": "propertyName"
            },


This is funky; I'm not sure how much this matters in practice, though...

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

jakebailey · 2024-12-18T20:29:28Z

tests/baselines/reference/assignmentCompatWithObjectMembersStringNumericNames.errors.txt

        ~
-!!! 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.


jakebailey

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.

jakebailey · 2024-12-18T21:54:21Z

tests/baselines/reference/objectLiteralGettersAndSetters.symbols

 >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))


Where did the \ go?

The code to remove the \ dates back a long long time.

symbolName.substring(1, symbolName.length - 1).replace(/\\./g, s => s.substring(1))

I have traced it back to this commit 8bb7230

Maybe @weswigham can shed more light on it, but this seems to be there to deal with escape sequences. Since when we build the string we need the escaped version, but what we have in symbolName is the source code version of the string. I will look for a better solution.

The current version can cause issues in both quick info and declaration emit:

// index.ts class T { static readonly "\t" = Symbol() } let x = { [T['\t']]: 1 } //index.d.ts declare class T { static readonly "\t": unique symbol; } declare let x: { [T["t"]]: number; // ❌ wrong symbol };

Playground Link

jakebailey · 2024-12-18T21:54:51Z

tests/baselines/reference/objectTypeWithStringNamedPropertyOfIllegalCharacters.symbols

@@ -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))


This escaping is also gone, which is odd...

jakebailey · 2024-12-18T21:57:28Z

tests/baselines/reference/stringLiteralPropertyNameWithLineContinuation1.symbols

 >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))



This is certainly an improvement

typescript-bot · 2024-12-20T14:56:56Z

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

Preserve string delimiter in type printing.

2906dea

typescript-bot added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Dec 10, 2024

dragomirtitian mentioned this pull request Dec 10, 2024

Extract types from object literals instead of using the type checker. #60540

Open

jakebailey reviewed Dec 10, 2024

View reviewed changes

tests/baselines/reference/ambientErrors.types Show resolved Hide resolved

rbuckton reviewed Dec 13, 2024

View reviewed changes

dragomirtitian added 3 commits December 16, 2024 18:32

Only preserve string delimiters if we print for declaration files.

275f6b9

Preserve original quotes in all except errors.

638ceea

Preserve symbol name string delimiters

b8d575a

robpalme reviewed Dec 18, 2024

View reviewed changes

jakebailey reviewed Dec 18, 2024

View reviewed changes

Improve preservation of strings in symbol printing.

1f2c52c

dragomirtitian marked this pull request as ready for review December 20, 2024 14:56

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Preserve string delimiter in type printing. #60729

Preserve string delimiter in type printing. #60729

dragomirtitian commented Dec 10, 2024

rbuckton Dec 13, 2024

jakebailey commented Dec 13, 2024

typescript-bot commented Dec 18, 2024

robpalme Dec 18, 2024

jakebailey Dec 18, 2024

dragomirtitian Dec 18, 2024

jakebailey Dec 18, 2024

dragomirtitian Dec 18, 2024

jakebailey Dec 18, 2024 •

edited

Loading

jakebailey left a comment

jakebailey Dec 18, 2024

dragomirtitian Dec 19, 2024

jakebailey Dec 18, 2024

jakebailey Dec 18, 2024

typescript-bot commented Dec 20, 2024

	* 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 '

Preserve string delimiter in type printing. #60729

Are you sure you want to change the base?

Preserve string delimiter in type printing. #60729

Conversation

dragomirtitian commented Dec 10, 2024

Choose a reason for hiding this comment

jakebailey commented Dec 13, 2024

typescript-bot commented Dec 18, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jakebailey Dec 18, 2024 • edited Loading

Choose a reason for hiding this comment

jakebailey left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

typescript-bot commented Dec 20, 2024

jakebailey Dec 18, 2024 •

edited

Loading