Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjust the rule about await e where the type of e is an extension type #3560

Merged
merged 7 commits into from
Jan 17, 2024

Conversation

eernstg
Copy link
Member

@eernstg eernstg commented Jan 15, 2024

See the discussion in #2710.

This PR introduces the notion of a type which is incompatible with await and uses that to specify the compile-time error which occurs in the case where await e is encountered, and the static type of e is incompatible with await. The main case is when said static type is an extension type that does not implement Future (that's the case that we had already), but this new rule includes more cases, e.g., the case where the static type is E? where E is an extension type that does not implement Future.

@eernstg eernstg requested a review from lrhn January 15, 2024 13:20
@eernstg
Copy link
Member Author

eernstg commented Jan 15, 2024

NB: The rule about being incompatible with await is intended to be evolvable over time, covering the case where we want to make more types incompatible with await (that is, if we wish to make all or part of await_only_futures a compile-time error). We'd simply add more atomic cases to this rule, similar to the first case (about implementing an extension type that doesn't implement Future).

Copy link
Member

@lrhn lrhn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still prefer the phrasing without "T is S bounded".

@eernstg eernstg merged commit c71b621 into main Jan 17, 2024
3 checks passed
@eernstg eernstg deleted the spec_exttype_await_error_jan24 branch January 17, 2024 09:43
copybara-service bot pushed a commit to dart-lang/sdk that referenced this pull request Feb 20, 2024
PR dart-lang/language#3560 and
dart-lang/language#3598 updated the feature
specification of extension types to define a notion of types being
'incompatible with await'. This CL adds a test to verify that various
types are being classified correctly, and errors are hence reported
as expected for expressions of the form `await e`.

Change-Id: I39e992b4317ef49fbc2267819481d71d87b56aca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351143
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
copybara-service bot pushed a commit to dart-lang/sdk that referenced this pull request Mar 5, 2024
…ith await

This is a cherry-pick of the following 5 commits from the main branch:

- Add test about types being incompatible with await
  (https://dart-review.googlesource.com/c/sdk/+/351143)

- [cfe] Report errors on awaiting types incompatible with await
  (https://dart-review.googlesource.com/c/sdk/+/348640)

- [cfe] Implement the update of "incompatible with await"
  (https://dart-review.googlesource.com/c/sdk/+/350986)

- Extension type. Implement isIncompatibleWithAwait() predicate,
  report AWAIT_OF_INCOMPATIBLE_TYPE.
  (https://dart-review.googlesource.com/c/sdk/+/350986)

- Extension type. Issue 54648. Fix 'incompatible with await'
  predicate. (https://dart-review.googlesource.com/c/sdk/+/355500)

Collectively, these 5 commits implement the new "incompatible with
await" error that was specified in
dart-lang/language#3560 and then refined in
dart-lang/language#3598.

Cherry-pick: https://dart-review.googlesource.com/c/sdk/+/348640
Cherry-pick-request: #55095
Change-Id: I84a79ffccce89c4d91c99a09ab7f5107a96e9844
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/355542
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants