Adjust generator element type, cf. dart-lang/language#3148 #3218
Conversation
|
Visit the preview URL for this PR (updated for commit aa7f8c4): https://dart-specification--pr3218-specify-generator-el-xal6crwg.web.app (expires Tue, 01 Aug 2023 07:46:31 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 6941ecd630c4f067ff3d02708a45ae0f0a42b88a |
eernstg
force-pushed
the
specify_generator_element_type_jul23
branch
from
cf28fdd
to
ee8256c
Compare
|
Friendly ping. Note that the current specification is unsound (cf. #3148 (comment)). |
|
We will need a plan for making sure whatever specification we end up gets tested and implemented. |
|
Also, how does this interact with https://github.com/dart-lang/language/pull/3151/files ? |
|
[Edit: Corrected link]
There is a co19 task in the pipeline, cf. |
It's a dart-lang/co19#2139 |
If we do not introduce new compile-time errors (for declarations like |
…c change Calculation of element type for the value returned from async/async*/sync* functions was recently adjusted in the spec to address soundness issue (dart-lang/language#3218). This change adjusts Dart VM to conform to the new spec. TEST=language/async/regression_54311_test TEST=co19/Language/Functions/element_type_* Fixes #54316 Issue #54311 Issue #54159 Change-Id: I4c51e7cba704d034350519375210bdb2086c5432 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/342082 Reviewed-by: Alexander Aprelev <[email protected]> Reviewed-by: Erik Ernst <[email protected]> Commit-Queue: Alexander Markov <[email protected]>
In issue #3148, it is reported that there is a soundness issue with the computation of the element type of a generator function whose declared return type is
FutureOr<Iterable<int>?>, and similar issues with other union types.This PR changes the definition of this element type such that return types are simplified to
Iterable<...>orStream<...>before the element type is computed, if possible.Objectand top types still yield the element typedynamic.Moreover, this PR also adjusts the specification of the dynamic type of the returned iterable/stream accordingly.
NB: This PR introduces null-safety related material into the existing language specification. We have done this in other cases as well. In general, we're aiming to integrate all the null-safety related material into the language specification, piece by piece, so there is no violation of current practice in doing that with this PR as well.