-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[front_end] Fix type of synthetic variables used in lowering of null-…
…aware accesses. Consider the following null-aware expression (taken from `pkg/front_end/testcases/nnbd/null_shorting.dart`): n1?.nonNullable1Method()?.nonNullable1Method(); Where `n1` has type `Class1?` and `Class1.nonNullable1Method` has return type `Class1`. Note that the second `?.` is not necessary, and should, in principle, be possible to optimize to `.` during compilation. Prior to this fix, this expression was lowered to the following kernel (line breaks inserted for clarity): let final self::Class1? #t80 = n1 in #t80 == null ?{self::Class1?} null : let final self::Class1? #t81 = #t80{self::Class1}.{self::Class1::nonNullable1Method} (){() → self::Class1} in #t81 == null ?{self::Class1?} null : #t81{self::Class1}.{self::Class1::nonNullable1Method} (){() → self::Class1}; Note that the type of #t81 is `self::Class1?`, which is nullable. But it doesn't need to be, since the initializer is the value returned by `nonNullable1Method()`, which returns a non-nullable type. The reason this was happening was because `InferenceVisitorImpl.inferSyntheticVariableNullAware` was incorrectly using `result.inferredType` as the type for the synthetic variable; when the target of the null-aware invocation is itself a null-aware invocation, this is the type that the target would have in the _absence_ of null shorting. But since null shorting is in effect, the correct type is `result.nullAwareActionType` (which in this example is non-nullable). With the fix, the expression is lowered to: let final self::Class1? #t80 = n1 in #t80 == null ?{self::Class1?} null : let final self::Class1 #t81 = #t80{self::Class1}.{self::Class1::nonNullable1Method} (){() → self::Class1} in #t81 == null ?{self::Class1?} null : #t81.{self::Class1::nonNullable1Method}(){() → self::Class1}; The runtime behavior of both lowerings is the same, but with the fix, it should be easier for back-end optimizations to determine that the null check `#t81 == null` is unnecessary. Fixes #59636. Bug: #59636 Change-Id: I3b426603c867bb586d57a0e323caba072bf05045 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/398121 Reviewed-by: Chloe Stefantsova <[email protected]> Auto-Submit: Paul Berry <[email protected]> Commit-Queue: Johnni Winther <[email protected]> Reviewed-by: Johnni Winther <[email protected]>
- Loading branch information
1 parent
bb1de17
commit a6cd285
Showing
10 changed files
with
20 additions
and
20 deletions.
There are no files selected for viewing
This file contains 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 file contains 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 file contains 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 file contains 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 file contains 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
Oops, something went wrong.