commit 59463fab90807f512ce816b87f10469272547c47
author Paul Berry <paulberry@google.com> Mon Dec 02 06:55:08 2024 +0000
committer dart-internal-monorepo <dart-internal-monorepo@dart-ci-internal.iam.gserviceaccount.com> Sun Dec 01 23:14:22 2024 -0800
tree a545f68397ed4c0e48e4d6e1d1c317a83b36db1c
parent 6bbe9579d59c422d2ade551416f395faa3c43877

[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 https://github.com/dart-lang/sdk/issues/59636.

Bug: https://github.com/dart-lang/sdk/issues/59636
Change-Id: I3b426603c867bb586d57a0e323caba072bf05045
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/398121
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>

https://dart.googlesource.com/sdk/+/a6cd285dad397fe665c896c71e301866e32f0158