Improve reuse of nodes in signatures with type mapping #58546

dragomirtitian · 2024-05-15T13:48:57Z

Improve reuse of nodes in signatures with type mapping

… Array<T>, ())

typescript-bot · 2024-05-15T13:49:01Z

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

jakebailey · 2024-05-15T20:05:29Z

@typescript-bot test it

typescript-bot · 2024-05-15T20:05:32Z

Starting jobs; this comment will be updated as builds start and complete.

Command	Status	Results
`test top400`	✅ Started	👀 Results
`user test this`	✅ Started	👀 Results
`run dt`	✅ Started	✅ Results
`perf test this faster`	✅ Started	👀 Results

typescript-bot · 2024-05-15T20:34:12Z

Hey @jakebailey, the results of running the DT tests are ready.

Everything looks the same!

You can check the log here.

typescript-bot · 2024-05-15T20:41:08Z

@jakebailey
The results of the perf run you requested are in!

Here they are:

tsc

Comparison Report - baseline..pr

_Metric	_baseline	_pr	_Delta	_Best	_Worst	_p-value
_{Compiler-Unions - node (v18.15.0, x64)}
_Errors	₃₀	₃₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_62,154	_62,154	_~	_~	_~	_{p=1.000 n=6}
_Types	_50,248	_50,248	_~	_~	_~	_{p=1.000 n=6}
_{Memory used}	_{192,881k (± 0.83%)}	_{192,851k (± 0.78%)}	_~	_192,208k	_195,923k	_{p=0.936 n=6}
_{Parse Time}	_{1.55s (± 2.39%)}	_{1.54s (± 1.81%)}	_~	_1.50s	_1.58s	_{p=0.686 n=6}
_{Bind Time}	_{0.87s (± 1.13%)}	_{0.86s (± 0.60%)}	_~	_0.86s	_0.87s	_{p=0.417 n=6}
_{Check Time}	_{11.30s (± 0.38%)}	_{11.33s (± 0.10%)}	_~	_11.31s	_11.34s	_{p=0.293 n=6}
_{Emit Time}	_{3.15s (± 1.29%)}	_{3.16s (± 0.88%)}	_~	_3.13s	_3.21s	_{p=1.000 n=6}
_{Total Time}	_{16.87s (± 0.41%)}	_{16.89s (± 0.23%)}	_~	_16.83s	_16.95s	_{p=0.520 n=6}
_{angular-1 - node (v18.15.0, x64)}
_Errors	₅	₅	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_944,110	_944,110	_~	_~	_~	_{p=1.000 n=6}
_Types	_407,140	_407,140	_~	_~	_~	_{p=1.000 n=6}
_{Memory used}	_{1,222,108k (± 0.01%)}	_{1,222,097k (± 0.01%)}	_~	_1,221,969k	_1,222,189k	_{p=1.000 n=6}
_{Parse Time}	_{8.09s (± 0.47%)}	_{8.08s (± 0.68%)}	_~	_8.02s	_8.16s	_{p=0.748 n=6}
_{Bind Time}	_{2.22s (± 0.54%)}	_{2.22s (± 0.70%)}	_~	_2.20s	_2.23s	_{p=0.797 n=6}
_{Check Time}	_{36.31s (± 0.17%)}	_{36.31s (± 0.25%)}	_~	_36.20s	_36.40s	_{p=1.000 n=6}
_{Emit Time}	_{17.47s (± 0.91%)}	_{17.38s (± 0.37%)}	_~	_17.30s	_17.49s	_{p=0.378 n=6}
_{Total Time}	_{64.09s (± 0.34%)}	_{63.99s (± 0.16%)}	_~	_63.83s	_64.14s	_{p=0.470 n=6}
_{mui-docs - node (v18.15.0, x64)}
_Errors	₅	₅	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_1,964,176	_1,964,176	_~	_~	_~	_{p=1.000 n=6}
_Types	_819,283	_819,283	_~	_~	_~	_{p=1.000 n=6}
_{Memory used}	_{1,849,670k (± 0.00%)}	_{1,849,586k (± 0.00%)}	_{-84k (- 0.00%)}	_1,849,564k	_1,849,611k	_{p=0.005 n=6}
_{Parse Time}	_{6.79s (± 0.49%)}	_{6.78s (± 0.30%)}	_~	_6.75s	_6.81s	_{p=0.325 n=6}
_{Bind Time}	_{2.31s (± 1.27%)}	_{2.29s (± 1.22%)}	_~	_2.28s	_2.35s	_{p=0.155 n=6}
_{Check Time}	_{58.57s (± 0.32%)}	_{58.54s (± 0.32%)}	_~	_58.33s	_58.80s	_{p=0.689 n=6}
_{Emit Time}	_0.14s	_0.14s	_~	_~	_~	_{p=1.000 n=6}
_{Total Time}	_{67.80s (± 0.24%)}	_{67.75s (± 0.32%)}	_~	_67.53s	_68.09s	_{p=0.688 n=6}
_{self-build-src - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_1,221,221	_1,221,227	_{+6 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_Types	_259,523	_259,525	_{+2 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{2,337,728k (± 0.03%)}	_{2,338,453k (± 0.03%)}	_~	_2,337,374k	_2,339,430k	_{p=0.173 n=6}
_{Parse Time}	_{4.98s (± 0.96%)}	_{5.04s (± 0.67%)}	_{+0.06s (+ 1.17%)}	_5.00s	_5.10s	_{p=0.031 n=6}
_{Bind Time}	_{1.88s (± 0.45%)}	_{1.89s (± 0.58%)}	_{+0.01s (+ 0.80%)}	_1.87s	_1.90s	_{p=0.042 n=6}
_{Check Time}	_{33.75s (± 0.32%)}	_{33.83s (± 0.33%)}	_~	_33.67s	_34.00s	_{p=0.199 n=6}
_{Emit Time}	_{2.65s (± 1.61%)}	_{2.62s (± 2.87%)}	_~	_2.48s	_2.69s	_{p=0.747 n=6}
_{Total Time}	_{43.26s (± 0.33%)}	_{43.39s (± 0.41%)}	_~	_43.11s	_43.57s	_{p=0.229 n=6}
_{self-build-src-public-api - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_1,221,221	_1,221,227	_{+6 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_Types	_259,523	_259,525	_{+2 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{2,413,607k (± 0.03%)}	_{2,414,151k (± 0.04%)}	_~	_2,413,029k	_2,415,673k	_{p=0.471 n=6}
_{Parse Time}	_{6.25s (± 1.24%)}	_{6.29s (± 1.46%)}	_~	_6.11s	_6.35s	_{p=0.378 n=6}
_{Bind Time}	_{2.04s (± 0.69%)}	_{2.04s (± 1.25%)}	_~	_2.01s	_2.07s	_{p=0.809 n=6}
_{Check Time}	_{40.23s (± 0.38%)}	_{40.38s (± 0.25%)}	_~	_40.28s	_40.54s	_{p=0.128 n=6}
_{Emit Time}	_{3.12s (± 2.90%)}	_{3.18s (± 1.80%)}	_~	_3.08s	_3.24s	_{p=0.378 n=6}
_{Total Time}	_{51.65s (± 0.35%)}	_{51.88s (± 0.38%)}	_{+0.22s (+ 0.43%)}	_51.49s	_52.03s	_{p=0.031 n=6}
_{self-compiler - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_256,767	_256,784	_{+17 (+ 0.01%)}	_~	_~	_{p=0.001 n=6}
_Types	_104,587	_104,589	_{+2 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{426,072k (± 0.01%)}	_{426,218k (± 0.01%)}	_{+146k (+ 0.03%)}	_426,142k	_426,284k	_{p=0.005 n=6}
_{Parse Time}	_{2.79s (± 0.51%)}	_{2.79s (± 0.42%)}	_~	_2.78s	_2.81s	_{p=0.934 n=6}
_{Bind Time}	_{1.11s (± 0.76%)}	_1.11s	_~	_~	_~	_{p=0.176 n=6}
_{Check Time}	_{15.18s (± 0.49%)}	_{15.19s (± 0.23%)}	_~	_15.14s	_15.22s	_{p=0.574 n=6}
_{Emit Time}	_{1.16s (± 1.22%)}	_{1.13s (± 1.03%)}	_{-0.03s (- 2.44%)}	_1.12s	_1.15s	_{p=0.012 n=6}
_{Total Time}	_{20.23s (± 0.41%)}	_{20.22s (± 0.20%)}	_~	_20.17s	_20.28s	_{p=1.000 n=6}
_{ts-pre-modules - node (v18.15.0, x64)}
_Errors	₃₅	₃₅	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_224,575	_224,575	_~	_~	_~	_{p=1.000 n=6}
_Types	_93,785	_93,785	_~	_~	_~	_{p=1.000 n=6}
_{Memory used}	_{369,789k (± 0.01%)}	_{369,907k (± 0.03%)}	_{+118k (+ 0.03%)}	_369,776k	_370,014k	_{p=0.045 n=6}
_{Parse Time}	_{3.50s (± 0.51%)}	_{3.52s (± 0.39%)}	_~	_3.50s	_3.54s	_{p=0.139 n=6}
_{Bind Time}	_{1.93s (± 0.60%)}	_{1.94s (± 1.51%)}	_~	_1.92s	_2.00s	_{p=0.615 n=6}
_{Check Time}	_{19.38s (± 0.35%)}	_{19.35s (± 0.29%)}	_~	_19.29s	_19.44s	_{p=0.373 n=6}
_{Emit Time}	_0.00s	_0.00s	_~	_~	_~	_{p=1.000 n=6}
_{Total Time}	_{24.81s (± 0.23%)}	_{24.81s (± 0.30%)}	_~	_24.73s	_24.93s	_{p=0.872 n=6}
_{vscode - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_2,823,941	_2,823,941	_~	_~	_~	_{p=1.000 n=6}
_Types	_957,912	_957,912	_~	_~	_~	_{p=1.000 n=6}
_{Memory used}	_{2,996,220k (± 0.00%)}	_{2,996,231k (± 0.00%)}	_~	_2,996,158k	_2,996,290k	_{p=0.689 n=6}
_{Parse Time}	_{13.81s (± 0.19%)}	_{13.82s (± 0.31%)}	_~	_13.75s	_13.88s	_{p=0.459 n=6}
_{Bind Time}	_{4.15s (± 0.47%)}	_{4.14s (± 0.36%)}	_~	_4.13s	_4.17s	_{p=0.742 n=6}
_{Check Time}	_{73.41s (± 0.23%)}	_{73.41s (± 0.22%)}	_~	_73.12s	_73.61s	_{p=0.688 n=6}
_{Emit Time}	_{23.58s (± 1.01%)}	_{23.46s (± 0.52%)}	_~	_23.36s	_23.62s	_{p=0.520 n=6}
_{Total Time}	_{114.95s (± 0.32%)}	_{114.84s (± 0.18%)}	_~	_114.48s	_115.05s	_{p=0.936 n=6}
_{webpack - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_265,866	_265,866	_~	_~	_~	_{p=1.000 n=6}
_Types	_108,401	_108,401	_~	_~	_~	_{p=1.000 n=6}
_{Memory used}	_{410,600k (± 0.02%)}	_{410,598k (± 0.02%)}	_~	_410,508k	_410,762k	_{p=0.936 n=6}
_{Parse Time}	_{4.75s (± 1.03%)}	_{4.77s (± 1.12%)}	_~	_4.68s	_4.82s	_{p=0.422 n=6}
_{Bind Time}	_{2.05s (± 0.97%)}	_{2.07s (± 0.71%)}	_~	_2.04s	_2.08s	_{p=0.155 n=6}
_{Check Time}	_{20.96s (± 0.39%)}	_{20.93s (± 0.27%)}	_~	_20.87s	_21.01s	_{p=0.574 n=6}
_{Emit Time}	_0.00s	_0.00s	_~	_~	_~	_{p=1.000 n=6}
_{Total Time}	_{27.76s (± 0.14%)}	_{27.77s (± 0.25%)}	_~	_27.69s	_27.89s	_{p=1.000 n=6}
_{xstate-main - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_524,639	_524,639	_~	_~	_~	_{p=1.000 n=6}
_Types	_178,906	_178,906	_~	_~	_~	_{p=1.000 n=6}
_{Memory used}	_{462,663k (± 0.01%)}	_{462,717k (± 0.01%)}	_~	_462,667k	_462,773k	_{p=0.128 n=6}
_{Parse Time}	_{3.12s (± 1.34%)}	_{3.11s (± 0.89%)}	_~	_3.09s	_3.16s	_{p=0.934 n=6}
_{Bind Time}	_{1.16s (± 0.89%)}	_{1.17s (± 0.84%)}	_~	_1.16s	_1.18s	_{p=0.437 n=6}
_{Check Time}	_{18.34s (± 0.61%)}	_{18.27s (± 0.34%)}	_~	_18.20s	_18.38s	_{p=0.199 n=6}
_{Emit Time}	_0.00s	_0.00s	_~	_~	_~	_{p=1.000 n=6}
_{Total Time}	_{22.62s (± 0.40%)}	_{22.55s (± 0.26%)}	_~	_22.51s	_22.67s	_{p=0.230 n=6}

System info unknown

Hosts

node (v18.15.0, x64)

Scenarios

Compiler-Unions - node (v18.15.0, x64)
angular-1 - node (v18.15.0, x64)
mui-docs - node (v18.15.0, x64)
self-build-src - node (v18.15.0, x64)
self-build-src-public-api - node (v18.15.0, x64)
self-compiler - node (v18.15.0, x64)
ts-pre-modules - node (v18.15.0, x64)
vscode - node (v18.15.0, x64)
webpack - node (v18.15.0, x64)
xstate-main - node (v18.15.0, x64)

_Benchmark	_Name	_Iterations
_Current	_pr	₆
_Baseline	_baseline	₆

Developer Information:

Download Benchmarks

typescript-bot · 2024-05-15T20:46:32Z

@jakebailey Here are the results of running the user tests comparing main and refs/pull/58546/merge:

Something interesting changed - please have a look.

Details

lodash

/mnt/ts_downloads/_/m/lodash/tsconfig.json

[NEW] error TS2345: Argument of type '{ countBy: Function; each: (collection: any[] | any, iteratee?: Function | undefined) => any[] | any; eachRight: (collection: any[] | any, iteratee?: Function | undefined) => any[] | any; ... 24 more ...; sortBy: Function; }' is not assignable to parameter of type 'string'.
- /mnt/ts_downloads/_/m/lodash/node_modules/lodash/fp/collection.js(2,26)
[NEW] error TS2345: Argument of type '{ at: Function; chain: (value: any) => any; commit: () => any; lodash: typeof lodash; next: typeof wrapperNext; plant: (value: any) => any; reverse: () => any; ... 6 more ...; wrapperChain: () => any; }' is not assignable to parameter of type 'string'.
- /mnt/ts_downloads/_/m/lodash/node_modules/lodash/fp/seq.js(2,26)
[MISSING] error TS2345: Argument of type '{ countBy: Function; each: (collection: any[] | any, iteratee?: Function | undefined) => any; eachRight: (collection: any[] | any, iteratee?: Function | undefined) => any; ... 24 more ...; sortBy: Function; }' is not assignable to parameter of type 'string'.
- /mnt/ts_downloads/_/m/lodash/node_modules/lodash/fp/collection.js(2,26)
[MISSING] error TS2345: Argument of type '{ at: Function; chain: (value: any) => any; commit: () => any; lodash: typeof lodash; next: typeof wrapperNext; plant: (value: any) => any; reverse: () => any; tap: (value: any, interceptor: Function) => any; ... 5 more ...; wrapperChain: () => any; }' is not assignable to parameter of type 'string'.
- /mnt/ts_downloads/_/m/lodash/node_modules/lodash/fp/seq.js(2,26)

typescript-bot · 2024-05-15T21:49:11Z

@jakebailey Here are the results of running the top 400 repos comparing main and refs/pull/58546/merge:

Something interesting changed - please have a look.

Details

tamagui/tamagui

9 of 118 projects failed to build with the old tsc and were ignored

packages/config/tsconfig.json

error TS7056: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.

…arations-mapped-sig-reuse

jakebailey · 2024-05-20T23:56:21Z

Used your tool to review all 201 significantly changed files. Some notes:

These are examples of notably good changes (good enough to point out how good they are):

declarationEmitGlobalThisPreserved.ts
declarationEmitMappedTypeTemplateTypeofSymbol.ts
defaultDeclarationEmitShadowedNamedCorrectly.ts
moduleAugmentationDuringSyntheticDefaultCheck.ts
recursiveFunctionTypes.ts
subtypingWithConstructSignatures.ts and co
unionTypeWithRecursiveSubtypeReduction3.ts

Most changes seem like just good reuse updates, so that's good.

Most of the other changes seem to be a couple of categories:

The preservation of undefined or null, where the test has strictNullChecks disabled (since it's not the default, ugh). Not totally sure how I feel about these, especially if they're going to show in tooltips? But who the heck has this flag off, why do we have this flag, agh
- e.g. tests/cases/compiler/copyrightWithNewLine1.ts showing null as return for getElementById
Objects losing | undefined on optional props. Continually worried about this but that's how it goes when copying...

Other stuff:

constraintSatisfactionWithAny.ts - this looks like a bug in the old code, but why don't I see it in dts emit or hover?
promisePermutations.ts and co - seems to be a very large instantiation count increase here.

dragomirtitian · 2024-05-22T15:18:32Z

`constraintSatisfactionWithAny`

I investigated and the way the signature is printed is different. The types base-line prints the types using the GenerateNamesForShadowedTypeParams flag, while the quick info does not use this flag so no type parameters will be renamed.

And it's not showing up in declarations, because the type reuse in the case of function declarations is actually not done by the checker printer, it's actually done in the declaration transform, which has its own ideas as to how things should be done (I really think we should unify these a lot more than they are today).

Something that would show the bug is const foo4 = null! as <T extends <T>(x: T) => void>(x: T) => T (Playground Link). In this case declaration emit falls back to type printing in the checker with GenerateNamesForShadowedTypeParams and we can see that the type parameters are not renamed appropriately.

On a related node. Why is renaming of shadowed parameters needed in this case? Since both T definitions come from source at the location, I don't really see how an inlined type would ever need to reference the outer T since the outer T was never accessible in the inner scope to being with. Is this a possible improvement or am I missing some case? (cc: @weswigham)

promisePermutations

I do think most of these instantiations actually hit the instantiation cache, but they get counted anyway. So I don't think the performance impact should be too big.

The reason this happens though is because when printing the return type I need to instantiate the return type I extract from the declaration and check it against the resolved return type in the signature. This is because signature return types might be different to the declaration return type (even after mapping). Ideally we should change the cases where these two diverge and then we can remove the check. I found two cases where this is so:

Constructor inherited from the base class.

These constructors signatures actually have the declaration from their original declaration but the return type from their containing class. This is a problem, because if we look at the declaration we get a different return type than the signature. Try as I might I have not been able to find a way, just by looking at the signature, to determine if this is a constructor signature that is inherited (and thus unreliable) or not.

Ex:

type Constructor<T = {}> = new (...args: any[]) => T;

function Mixin<TBase extends Constructor>(Base: TBase) {
    return class extends Base {
    };
}

In the example the constructor signature of Base is actually tied to the declaration that comes from new (...args: any[]) => T, which will not give the correct return type.

Signatures that don't actually have a mapper that can get us from declaration to signature types. For example in

const createTransform = <I, O>(tr: (from: I) => O) => tr;

function withP2<P>(p: P) {
  const m = <I,>(from: I) => ({ ...from, ...p });
  return createTransform(m);
}

const addP2 = withP2({ foo: 1 });

The signature for addP2 actually comes from the declaration tr: (from: I) => O. But the mapper for the signature only contains I -> I, P -> { foo: number }. This mapper is incorrect, it does not actually have a mapping for O which it should for us to be able to correctly get the return type.

This is because in instantiateSignature when creating the new mapper we have:

freshTypeParameters = map(signature.typeParameters, cloneTypeParameter);
mapper = combineTypeMappers(createTypeMapper(signature.typeParameters, freshTypeParameters), mapper);

But signature already has it's own mapper which contains a mapping from O -> I & P. I tried adding the signature mapper in the mix, but that seems to break a bunch of other things and it's an unrelated change I don't feel comfortable commingling in this PR.

jakebailey · 2024-05-22T19:29:46Z

I investigated and the way the signature is printed is different. The types base-line prints the types using the GenerateNamesForShadowedTypeParams flag, while the quick info does not use this flag so no type parameters will be renamed.

Ah, right. I've wanted to make hover pass that flag, honestly. (related, #55821)

On a related node. Why is renaming of shadowed parameters needed in this case? Since both T definitions come from source at the location, I don't really see how an inlined type would ever need to reference the outer T since the outer T was never accessible in the inner scope to being with. Is this a possible improvement or am I missing some case?

We've iterated on the type parameter renaming code so much that I'm not sure why it doesn't work, honestly. I definitely had fixed some cases like this before, but we undid some of that, then redid some of that. So it does sound like an improvement, but that may be challenging because even though we introduce a new name T into the scope, it's possible that the inside bit could still refer to the outer T indirectly and be printed back. At least, that is my guess.

weswigham · 2024-05-22T19:35:36Z

On a related node. Why is renaming of shadowed parameters needed in this case?

It's a bit more pessimistic than it strictly has to be sometimes, but the renaming in general is needed because cases like this

export const a = <T,>() => {
  type U = T;
  return <T extends U>() => null as any as T;
}

exist.

weswigham

I think I'm gonna merge this at this point so we have more time to work on top of it - I like the approach and the changes on the whole look good, and I think that if it doesn't fix some other issues reported with the new node reuse we're doing, it's a required stepping stone for them.

dragomirtitian added 15 commits May 15, 2024 12:03

Updated baseline that have better node reuse.

114e936

Type printed in a different way without any change (ReadonlyArray<T>,…

1b4d000

… Array<T>, ())

Union order is different.

c69b466

Names and types not resolved and preserved as written in source.

1765bef

Default parameters not added

1ecd410

Undefined preserved from the original type.

a85b6c5

Undefined not added to optional properties.

8db4971

Trivial diffs.

4062e36

Type preserved even though original type had error.

00a7bd4

Misc baseline update

c2103f0

Types were wrong in the original baseline

6ec7c6b

Updated test and some declaration baselines.

4f304e5

Code & fixes for four-slash tests

4cab9e1

Trivial reuse after merge with master.

da08515

Updated baseline.

7c43bf9

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

Improve mapping of types in type node builder.

52c6e2f

Merge remote-tracking branch 'remotes/origin/main' into isolated-decl…

69daca1

…arations-mapped-sig-reuse

weswigham approved these changes May 23, 2024

View reviewed changes

weswigham merged commit 2b4e7e3 into microsoft:main May 23, 2024
28 checks passed

weswigham added a commit to weswigham/TypeScript that referenced this pull request May 23, 2024

Add test for issue fixed by microsoft#58546

920815e

weswigham mentioned this pull request May 23, 2024

Add test for issue fixed by #58546 #58635

Merged

weswigham added a commit that referenced this pull request May 23, 2024

Add test for issue fixed by #58546 (#58635)

d66a309

MichaelMitchell-at mentioned this pull request Jun 5, 2024

[compiler crash] TypeError: Cannot read properties of undefined (reading 'kind') #58781

Closed

ssalbdivad mentioned this pull request Jun 19, 2024

Some long function return expressions no longer evaluated in 5.5 #58937

Closed

jfet97 mentioned this pull request Jul 6, 2024

Regression in Type Inference for functions derived from typeclasses in TypeScript 5.5.x Effect-TS/effect#3171

Closed

jakebailey mentioned this pull request Jul 8, 2024

Consider enclosing declaration when serializing inferred return types #59170

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve reuse of nodes in signatures with type mapping #58546

Improve reuse of nodes in signatures with type mapping #58546

dragomirtitian commented May 15, 2024

typescript-bot commented May 15, 2024

jakebailey commented May 15, 2024

typescript-bot commented May 15, 2024 •

edited

Loading

typescript-bot commented May 15, 2024

typescript-bot commented May 15, 2024

tsc

typescript-bot commented May 15, 2024

lodash

/mnt/ts_downloads/_/m/lodash/tsconfig.json

typescript-bot commented May 15, 2024

tamagui/tamagui

packages/config/tsconfig.json

jakebailey commented May 20, 2024

dragomirtitian commented May 22, 2024 •

edited

Loading

jakebailey commented May 22, 2024

weswigham commented May 22, 2024 •

edited

Loading

weswigham left a comment

Improve reuse of nodes in signatures with type mapping #58546

Improve reuse of nodes in signatures with type mapping #58546

Conversation

dragomirtitian commented May 15, 2024

typescript-bot commented May 15, 2024

jakebailey commented May 15, 2024

typescript-bot commented May 15, 2024 • edited Loading

typescript-bot commented May 15, 2024

typescript-bot commented May 15, 2024

tsc

typescript-bot commented May 15, 2024

lodash

/mnt/ts_downloads/_/m/lodash/tsconfig.json

typescript-bot commented May 15, 2024

tamagui/tamagui

packages/config/tsconfig.json

jakebailey commented May 20, 2024

dragomirtitian commented May 22, 2024 • edited Loading

constraintSatisfactionWithAny

promisePermutations

jakebailey commented May 22, 2024

weswigham commented May 22, 2024 • edited Loading

weswigham left a comment

Choose a reason for hiding this comment

typescript-bot commented May 15, 2024 •

edited

Loading

dragomirtitian commented May 22, 2024 •

edited

Loading

`constraintSatisfactionWithAny`

weswigham commented May 22, 2024 •

edited

Loading