| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
| return includes & TypeFlags.Any ? includes & TypeFlags.IncludesWildcard ? wildcardType : anyType : unknownType; | ||
| return includes & TypeFlags.Any ? | ||
| includes & TypeFlags.IncludesWildcard ? wildcardType : anyType : | ||
| includes & TypeFlags.Null || containsType(typeSet, unknownType) ? unknownType : nonNullUnknownType; |
There was a problem hiding this comment.
What’s an example where this produces nonNullUnknownType? Would nonNullUnknownType itself have to be one of the union constituents?
Sorry, something went wrong.
There was a problem hiding this comment.
Yes, it'll produce nonNullUnknownType when there are no regular unknownType instances in the set (which implies all are nonNullUnknownType instances) and the set contains no TypeFlags.Null types. Effectively, a non-null unknown type survives only if there are no regular unknown types and no null types.
Sorry, something went wrong.
| assumeTrue ? TypeFacts.EQNull : TypeFacts.NENull : | ||
| assumeTrue ? TypeFacts.EQUndefined : TypeFacts.NEUndefined; | ||
| return getTypeWithFacts(type, facts); | ||
| return type.flags & TypeFlags.Unknown && facts & (TypeFacts.NENull | TypeFacts.NEUndefinedOrNull) ? nonNullUnknownType : getTypeWithFacts(type, facts); |
There was a problem hiding this comment.
Can this not just be handled by getTypeWithFacts?
Sorry, something went wrong.
There was a problem hiding this comment.
Well, getTypeWithFacts(…) is used in many more places, and nonNullUnknownType should never escape control flow analysis: https://github.com/microsoft/TypeScript/blob/7e231a2ebfce3692663fe2583a19a8cb0c59e457/src/compiler/checker.ts#L23118-L23119
So probably not?
Sorry, something went wrong.
There was a problem hiding this comment.
Sorry, something went wrong.
|
This reminded me of #29317! 😮 Does special-casing this mean the team is still undecided on Negated Types? |
Sorry, something went wrong.
|
In any case, thanks for this fix! I have this pop up every so often, and it'll be nice to see it finally solved. 😀 |
Sorry, something went wrong.
| const nonInferrableAnyType = createIntrinsicType(TypeFlags.Any, "any", ObjectFlags.ContainsWideningType); | ||
| const intrinsicMarkerType = createIntrinsicType(TypeFlags.Any, "intrinsic"); | ||
| const unknownType = createIntrinsicType(TypeFlags.Unknown, "unknown"); | ||
| const nonNullUnknownType = createIntrinsicType(TypeFlags.Unknown, "unknown"); |
There was a problem hiding this comment.
It's already pretty hard to understand what these are for. I'd encourage us to start documenting what the use-cases for each of these are. For example.
| const nonNullUnknownType = createIntrinsicType(TypeFlags.Unknown, "unknown"); | |
| /** | |
| * An `unknown` type that is used purely for narrowing. | |
| * Used to record that a `x !== null` check has occurred to specially handle `typeof x === "object"`. | |
| */ | |
| const nonNullUnknownType = createIntrinsicType(TypeFlags.Unknown, "unknown"); |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
With this PR we fix the following long standing issue:
Above, the order of the checks mattered because unknown is an "indivisible" non-union type and therefore a check for x !== null couldn't narrow x in the second if statement. We implemented a partial fix in #37507, but this only worked for truthy checks combined with typeof checks using the && operator in the same expression.
With this PR we remove the partial fix and instead introduce an internal nonNullUnknownType that is used in control flow analysis to represent an unknown type that is known to be non-null. The non-null unknown type results when the unknown type is subjected to a truthiness check or an x !== null check, and when the non-null unknown is subsequently subjected to a typeof x === 'object' check, we narrow to object instead of object | null. Because we rely on control flow analysis, this solution properly reflects the effects of non-null checks in separate expressions or statements:
Fixes #28131.