Use NonNullable<T> in more scenarios #49330
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR builds on #49119 to use
NonNullable<T>
in more scenarios in--strictNullChecks
mode. The PR also cleans up some compiler internals.NonNullable<T>
are now only created only ifT
can possibly benull
orundefined
. Previously, the compiler would sometimes createNonNullable<T>
instantiations even for aT
constrained to a non-nullable type.a
andb
of typeA
andB
, the expressiona || b
now has typeNonNullable<A> | B
ifA
can possibly benull
orundefined
.obj
of a generic typeT
constrained to a nullable type, when an expressionobj?.x
is used in a context that provesx
is notundefined
, the type ofobj
is narrowed toNonNullable<T>
.x
of typeunknown
, the expressionx!
has type{}
.getFalsyFlags
function is gone and its functionality folded intogetTypeFacts
.Some examples (in
--strictNullChecks
mode):