You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
functionf(){constb=newBar();// Changes depending on if the next line is commented.console.log(b.value);}classBar<T>{num!: number;// Also changes depending on if this next line is commented.field: number=(thisasBar<any>).num;value=(thisasBar<any>).num;// ^?// ~~~~~ implicit any}
Sometimes we hit a circularity, sometimes we don't.
Even with inlay hints/semantic highlighting off.
Get an error in the editor, but not the compiler.
In an editor context, the order of type-checking two files changes.
This is all due to variance computation.
Why?
Need to see if the this type can be related to Bar<any>.
Means eventually we need to see if Bar<T> is related to Bar<any>.
That means we need to calculate variance of the type parameters of Bar.
And so this variance computation means we will re-encounter Bar<T> in the resolution stack because in the editor, this might
Is it possible to "reset" the resolution stack when we start doing variance computations?
What are the implications of doing that?
Could get strange behavior, but worth trying.
But type variances can relate on other types' type variances!
If you reset the resolution stack, you need to keep track of when you do that.
"Resolution resolution stack?" 🥴😵💫
No, idea is you'd only reset the stack the first time you start computing variance.
It seems like we really shouldn't need to see if this is related to Bar<any>.
It should be "trivial" to just fetch the type of num without checking the type assertion.
Type resolution vs. type checking.
Could defer the rest of the computation?
Resolution could be smarter and not trigger checking.
Not a sufficient fix - can encounter the same issue with overload resolution issues. May not be enough.
Check for Strict Subtyping and Fall Back to Regular Subtyping in
getNarrowedType
#52984
Type guard affects type of variable in surprising way #50916
unknown
should narrow to the asserted type.{}
?This definitely comes up with index signatures,
any
vs.unknown
.Strict subtype relationship aims to create a partial ordering among types.
If you end up with mutual subtypes, then at the "join points" of control flow analysis you will possibly lose the original type.
We did have to fix a few things in strict-subtyping in 5.0 in strict-subtype (Improvements to
strictSubtypeRelation
andgetNarrowedType
#52282)Check for strict subtypes and then regular subtypes in getNarrowedType #52984
isArrayLike(value: any): value is { length: number }
Theoretically can break this:
Idea: once test cases added, once reviewed, merge. Then run on top 200-300 GH repos.
Regardless of results, current state is pretty bad.
Any reason why we have to "merge" instead of falling back to original type?
Info is lossy as to why something got narrowed.
Circularity Errors Depending on Ordering
#52813
this
type can be related toBar<any>
.Bar<T>
is related toBar<any>
.Bar
.Bar<T>
in the resolution stack because in the editor, this mightthis
is related toBar<any>
.It should be "trivial" to just fetch the type of
num
without checking the type assertion.Type resolution vs. type checking.
Could defer the rest of the computation?
Resolution could be smarter and not trigger checking.
Not a sufficient fix - can encounter the same issue with overload resolution issues. May not be enough.
Octal Escape Sequences
#51837
The text was updated successfully, but these errors were encountered: