[CS] Don't apply compatibility logic to collection literals #41315
Conversation
This file contains hidden or 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
hamishknight
force-pushed
the
shortsighted
branch
from
ba1e30c to
8a4b61a
Compare
Contributor
Author
|
@swift-ci please test |
Contributor
Author
|
@swift-ci please test source compatibility |
xedin
approved these changes
Feb 10, 2022
Remove the unused `choice` parameter.
We currently permit (but warn on) coercions of collections with unrelated element types in certain cases. This is done in an effort to preserve compatibility with pre-5.3 compilers that may have allowed such code to compile due to dropping constraints while solving. This is limited to collection coercions as we emit somewhat reasonable code for them that performs a force cast of the elements at runtime. However, it turns out that in the case of collection literals, we peephole the element conversions in CSApply, leading to codegen crashes. As such, narrow down the condition of this compatibility logic to not apply to collection literals, as this never would have compiled properly. rdar://88334481
This was only intended to preserve compatibility for cases where the constraint system may have previously accepted invalid code. Drop it in Swift 6 mode such that invalid collection coercions become errors.
hamishknight
force-pushed
the
shortsighted
branch
from
8a4b61a to
04b37ae
Compare
Contributor
Author
|
@swift-ci please smoke test |
Contributor
|
Can you disable the compatibility hack altogether in -swift-version 6 mode? |
Contributor
Author
|
@slavapestov Yup, 04b37ae does that. Let me add it to the PR description |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
We currently permit (but warn on) coercions of collections with unrelated element types in certain cases. This is done in an effort to preserve compatibility with pre-5.3 compilers that may have allowed such code to compile due to dropping constraints while solving (#30886).
This is limited to collection coercions as we emit somewhat reasonable code for them that performs a force cast of the elements at runtime. However, it turns out that in the case of collection literals, we peephole the element conversions in CSApply, leading to codegen crashes. As such, narrow down the condition of this compatibility logic to not apply to collection literals, as this never would have compiled properly.
Additionally, disable the compatability logic altogether in Swift 6 mode.
rdar://88334481