Repository navigation
5.6 regression: Incorrect param type inference for type with all optional props #59656
Description
Activity
FWIW, in Google's codebase, I'm seeing other new inference related bugs popping up. For the life of me, I can't make a simplified repro for one particular case that I've been looking at for a while...
I'll try to add other repros when I can...
I’d appreciate any kind of repros - they could even be not-so-minimal 😉
A useful observation is that this can be fixed by a single variance annotation
interface Observable<in T> {
which implies we're likely measuring the variance wrong.
I’d appreciate any kind of repros - they could even be not-so-minimal 😉
Yeah. This one is just some internal team who has produced a pipeline with some pretty complicated TS types and inference is breaking in a new way. I'll be looking more at overall compilation issues in the codebase and will try to highlight other similar issues when they seem relevant.
This changes the behavior even in 5.5:
interface Observable<T> { pipe<R>(op: OperatorFunction<T, R>): Observable<R>; } type OperatorFunction<T, R> = (source: Observable<T>) => Observable<R>; -declare function tap<T>(next: (value: T) => void): OperatorFunction<T, T>; +interface UnaryFunction<T, R> { (source: T): R; } +declare function tap<T>(next: (value: T) => void): UnaryFunction<Observable<T>, Observable<T>> declare const obs: Observable<{ a?: string; b?: number }>; function test(): Observable<{ a?: string }> { return obs.pipe( tap((tapped) => { tapped; // ^? }), ); }And, like Ryan suspected,
TinObservable<T>is measured to haveVarianceFlags.Independenthere. That means it was first measured to haveVarianceFlags.Bivariant(TS playground):interface Observable<T> { pipe<R>(op: OperatorFunction<T, R>): Observable<R>; } type OperatorFunction<T, R> = (source: Observable<T>) => Observable<R>; type Test1 = Observable<string | number> extends Observable<string> ? 1 : 0; // ^? type Test1 = 1 type Test2 = Observable<string> extends Observable<string | number> ? 1 : 0; // ^? type Test2 = 1
Declaring
pipeas a property instead of a method doesn't change this (TS playground).Clearly, we get different results here when either type arguments-based or structure-based inference is used. For now, I'll look into understanding what changed for the latter with my PR.
By the way, I've identified a number of other new compilation issues a little different from this that I believe is related to this issue.
Once there is a new 5.6.0 build with this PR, I can see if it resolves the other new issues I've been seeing.
In this example, basically, inference appears to be dropping optional parameters from a type or making them required. I haven't dug into it super deep. If this PR doesn't fix the issue, I'll try to boil it down to a repro.
Can you try the build on #59709 (comment) to see if that fixes your issues?
Hey there. Confirmed that this fix does fix the specific issue noted here.
That said, I am still seeing other new inference-related bugs that I was hoping this fix would resolve. I'll try to construct repros in TS Playground for those ones and file new issues.
- changed the title
[-]5.6.0 regression: Incorrect param type inference for type with all optional props[/-][+]5.6 regression: Incorrect param type inference for type with all optional props[/+]on Aug 27, 2024
🔎 Search Terms
inference, param
🕗 Version & Regression Information
⏯ Playground Link
https://www.typescriptlang.org/play/?ts=5.6.0-dev.20240816#code/JYOwLgpgTgZghgYwgAgMoHsC2EAqBPABxQG8AoZC5AeiuQHkRkBWAOgDYWAGAGmQgA8iUYNnDIARnmSY4Aa1ABzZGAAWwAM7ICUdAWRQIARwCuwAwBMW5SsZDATEAAo6CAfgBcydWGEgFAblIAX1JScwgEABs4A2QEdBBvZHRxdU86VOgANzhxSIgAHgxsfCIAPkDSGFsEMGAE5BiFAHEIMHUAdR0-UogACgBKdMyoHLzC4iCy5DJKfTbjKEYU9RYCYCI+sDgCPqbkAF5p2bnKJsDTyhoAPVdrS5pkAFFBCMhzT2LcQhRQZhZWAAWe6nR4AQVqxjgkU8FEmyD+WVYHE4AFpxG04Mp0P8UajwlkWAAmThEwGcAAcAEY2Mg9mBkPk4N4BiCggMBoEQlUanUGk1Wu0AMLoKAGWq9QYzEEGMCLZapNYbfrbXb7I7Sy4Uc4guY3O5a6i0MGRADucDwmniYrebI5XNCoEgsEQKAy6myuXyBRwxxB6yIBTBZT6unSQjgYFFADFefUQD7eMGhvQRmNvcGHU7oPAkMgAKogGJ4WMgWrxxPIABKxzp6nQiyQnhwKar-mQIWzLrzdAjUagpfLCUrNb4-EgIHMmkLxcHfIT7s94x9ZV4i9GXsKNdrnfAOddyAAsgl0L1e9BIzG48PfWOJ1P6H2r2X55Xb8QO2EItFYtUX-HlB2Fc+hAAQwE8PockiYwIGbAZDmmLJ0GAcwU2PEBTx+c8oEvAdrwTX1AiAA
💻 Code
🙁 Actual behavior
argis inferred as{}🙂 Expected behavior
argis inferred asSomeTypeas was consistent in v5.5.4Additional information about the issue
(Google note: See http://cl/664889390 for local workaround)