Sema: Explicitly allow Optional-to-IUO when converting functions #7168
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
Contributor
jrose-apple
commented
Jan 31, 2017
jrose-apple
commented
- Explanation: A type checker rule preventing accidental Optional-to-ImplicitlyUnwrappedOptional conversions interacts poorly with deciding which function type conversions are allowed. This wouldn't be a problem except that an unrelated bug allowed a certain class of these conversions in Swift 3.0. Rather than try to emulate Swift 3.0's behavior, just allow Optional-to-IUO conversions when they appear as part of a function type conversion.
- Scope: Only affects function type conversions that involve IUO.
- Issue: SR-3758 / rdar://problem/30235814
- Reviewed by: @DougGregor, @rudkx
- Risk: Low, scope is very limited.
- Testing: Added compiler regression tests.
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
…iftlang#7153) We limit Optional-to-IUO as an implicit conversion to avoid making common expressions ambiguous. However, this runs into trouble with function-to-function conversions, which always look for a "Subtype" relationship for their inputs and outputs. This is a conservative way for Sema to avoid emitting conversions that SILGen cannot handle. The problem case here is converting a closure with type '(Any!) -> Void' to a value of type '(Any?) -> Void': let f: ((Any?) -> Void) = { (arg: Any!) in } This is clearly a safe conversion, since 'Any!' and 'Any?' have the same representation at run time, but historically we've disallowed it because of the above rules. However, in Swift 3.0 this particular case was permitted, with the type checker deciding that the 'Any?' argument to 'f' could first itself be put into an 'Any', then /that/ value could go through a value-to-optional conversion to make 'Any!'. Fortunately the emitted code didn't follow this incorrect conversion path. This patch doesn't even try to emulate the old behavior. Instead, it just weakens the restriction on Optional-to-IUO via a new type matching flag that only applies within the context of matching function types. We can consider opening up function conversions in Swift 4 to anything that supports conversion---not just subtyping---now that SILGen knows how to automatically reabstract most such things. But whether we do or not, Optional/IUO is a special case. https://bugs.swift.org/browse/SR-3758
jrose-apple
force-pushed
the
3.1-Optional-to-IUO
branch
from
b182595 to
b34a995
Compare
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
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.