[CP] Implement error about awaiting a type that is incompatible with await

[stereotype441]

Commit(s) to merge

bf17088, 1672177, a5bbbe8, adee0a2, 690d49c

Target

Stable

Prepared changelist for beta/stable

https://dart-review.googlesource.com/c/sdk/+/355542

Issue Description

The new extension types feature contains a rule preventing an extension type from being used as the operand of an await, unless the extension type implements Future. However, the logic that was released in Dart 3.3.0 has a loophole in that it allows some types based on an extension type to be used as the operand of an await, such as:

• A nullable extension type where the extension type doesn't implement future.
• A promoted type variable, where the promoted type is incompatible with await.
• A type variable with a bound that is incompatible with await.

The loophole was fixed in the specification on Jan 17 (dart-lang/language#3560) and Jan 31 (dart-lang/language#3598). However, the implementation of this fix didn't land until after the release cutoff for Dart 3.3. This cherry-pick closes the loophole for the stable release.

What is the fix

• bf17088 contains the test cases that validate the implementation against the specification.
• 1672177 contains the initial CFE implementation of the new error.
• a5bbbe8 contains a refinement of the CFE implementation of the new error, based on Adjust incompatible-with-await to be more strict on intersections language#3598.
• adee0a2 contains the initial analyzer implementation of the new error.
• 690d49c contains a refinement of the analyzer implementation of the new error, based on Adjust incompatible-with-await to be more strict on intersections language#3598.

Why cherry-pick

Since the extension types feature is so new, it's highly unlikely that it's seen enough widespread usage for anyone to have run into the loophole described above. It's far better to cherry-pick a fix to the loophole now, than to defer the fix until Dart 3.4.0 (at which point, use of the feature will probably be much more widespread).

Risk

low

Issue link(s)

#54647

Extra Info

No response

[itsjustkevin]

@johnniwinther and @mraleph can you take a look at this cherry-pick request.

[mraleph]

LGTM based on the following:

• Change localized to a newly released feature;
• Good test overage;
• Desire to prevent subsequent breaking change in the next release;

[johnniwinther]

LGTM