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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR improves our checking of nullable operands in expressions. Specifically, we now error in the following cases:
If either operand of a + operator is nullable, and neither operand is of type any or string.
If either operand of a -, *, **, /, %, <<, >>, >>>, &, |, or ^ operator is nullable.
If either operand of a <, >, <=, >=, or in operator is nullable.
If the right operand of an instanceof operator is nullable.
If the operand of a +, -, ~, ++, or -- unary operator is nullable.
An operand is considered nullable if the type of the operand is null or undefined or a union type that includes null or undefined. Note that the union type case only only occurs in --strictNullChecks mode because null and undefined disappear from unions in classic type checking mode.
The reason will be displayed to describe this comment to others. Learn more.
Object is definitelynull, and typically we don't think of objects as being operands to arithmetic operations (whereas we do when it comes to primitives). Would be nice if we could be more precise on the error message.
The reason will be displayed to describe this comment to others. Learn more.
Two orthogonal issues:
First, we could do extra work to omit the word possibly when the type is exactlynull or undefined. However, it is very rare for someone to explicitly use null or undefined as an operand, so it's not clear that it really matters all that much. This is the type of error that only surfaces in a test.
Second, we could consider using the word value instead of object when reporting for expression operands--but it's really the same error that we use for obj.foo where obj may be null or undefined. The downside would be error message searchability, but since the error is pretty obvious that may not be an issue.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
None yet
4 participants
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 improves our checking of nullable operands in expressions. Specifically, we now error in the following cases:
+
operator is nullable, and neither operand is of typeany
orstring
.-
,*
,**
,/
,%
,<<
,>>
,>>>
,&
,|
, or^
operator is nullable.<
,>
,<=
,>=
, orin
operator is nullable.instanceof
operator is nullable.+
,-
,~
,++
, or--
unary operator is nullable.An operand is considered nullable if the type of the operand is
null
orundefined
or a union type that includesnull
orundefined
. Note that the union type case only only occurs in--strictNullChecks
mode becausenull
andundefined
disappear from unions in classic type checking mode.Fixes #12795.