Fix records type inference rules to match implementations. #3613
Conversation
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
If the context of a record literal is the same shape as the record
literal, but the actual type of one or more fields is not a subtype of
the corresponding field in the context type, and no coercion is
possible, then the implementations do not necessarily issue an
error. They only issue an error if the type mismatch leads to an
assignability error during subsequent analysis.
An example of a circumstance where the type mismatch doesn't lead to
an assignability error is if the context resulted from assignment to a
previously promoted local variable. For example:
f(Object o) {
if (o is (int,)) {
o = ('',); // OK; demotes `o` back to `Object`.
}
}
This change adjusts the spec to agree with what was implemented.
|
This change looks good to me, but @leafpetersen wrote the inference section for records and he'll understand much better than I would if there are complications here that I'm not seeing. |
munificent
approved these changes
Feb 13, 2024
copybara-service bot
pushed a commit
to dart-lang/sdk
that referenced
this pull request
Feb 13, 2024
When a local variable is promoted to a record type, and then an assignment statement is used to assign a record literal to that local variable, if the fields of the new record literal are not assignable to the fields of the promoted record type, that's not a problem; both the analyzer and front end agree that the local variable is simply demoted. But the spec implies that if the old and new record _shapes_ are the same, then a compile-time error will occur instead of a demotion. I've created dart-lang/language#3613 to bring the spec in line with the implementations. This test demonstrates the current behavior of the implementations, and makes sure that it doesn't regress. Change-Id: I0eacd7ca7f6579a35dbc34687113a2112418f368 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352462 Reviewed-by: Bob Nystrom <rnystrom@google.com> Commit-Queue: Paul Berry <paulberry@google.com>
leafpetersen
approved these changes
Feb 14, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the context of a record literal is the same shape as the record literal, but the actual type of one or more fields is not a subtype of the corresponding field in the context type, and no coercion is possible, then the implementations do not necessarily issue an error. They only issue an error if the type mismatch leads to an assignability error during subsequent analysis.
An example of a circumstance where the type mismatch doesn't lead to an assignability error is if the context resulted from assignment to a previously promoted local variable. For example:
This change adjusts the spec to agree with what was implemented.
Contribution guidelines:
dart format.Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.