[Sema] Don't treat archetypes as non-optional when casting to them #13910
Conversation
|
It's worth noting that this PR doesn't fully fix this FIXME: Currently attempting to cast to an optional type from a (less-optional) archetype is a compiler error:
I would like a little clarification on the intended rules behind this error though; is the intention to permit such casts for archetype and existential operands, as they could hold optional values at runtime? |
|
cc. @rjmccall – would you be available to review this? |
lib/Sema/CSApply.cpp
Outdated
| // bridging operation, or if the destination value type is an | ||
| // archetype (and could therefore be an Optional type at runtime), | ||
| // leave any extra optionals on the source in place. | ||
| if (isBridgeToAnyObject || destValueType->is<ArchetypeType>()) { |
There was a problem hiding this comment.
You should disallow class-archetypes. We have a function in DynamicCasts.cpp, canDynamicallyBeOptionalType(). It's not quite what you want because it allows existentials, but please extract something in common that can be used by both places. Having a parameter indicating whether we're asking whether the type could be an optional type (what you're asking here) or store an optional type (what DynamicCasts.cpp is asking) would be sensible.
There was a problem hiding this comment.
Very helpful, thanks @rjmccall! I've gone ahead and made those changes, let me know if they're what you had in mind.
hamishknight
force-pushed
the
dont-treat-archetype-as-nonoptional
branch
from
08760e2 to
d6b6969
Compare
|
Thanks, that looks good. |
|
@swift-ci Please test. |
|
Any news on this @rjmccall? |
|
Yes, that's fine, thanks. |
hamishknight
force-pushed
the
dont-treat-archetype-as-nonoptional
branch
from
d6b6969 to
ab82049
Compare
|
@swift-ci Please test. |
|
Build failed |
|
Build failed |
|
Thanks! |
…5 mode In swiftlang#13910, the behaviour of optional-to-archetype casts changed such that we're now more conservative with the unwrapping of the operand at compile time in order to account for the fact that an optional type could be substituted at runtime. This brought such casting behaviour inline with that in a non-generic context, however it wasn't properly gated by Swift version, leading to compatibility issues. This commit restricts the new behaviour to Swift 5 mode and above. Resolves SR-8704.
…5 mode In swiftlang#13910, the behaviour of optional-to-archetype casts changed such that we're now more conservative with the unwrapping of the operand at compile time in order to account for the fact that an optional type could be substituted at runtime. This brought such casting behaviour inline with that in a non-generic context, however it wasn't properly gated by Swift version, leading to compatibility issues. This commit restricts the new behaviour to Swift 5 mode and above. Resolves SR-8704.
When casting an optional value to a (less-optional) archetype, don't dig into the optional as the archetype could be an optional type at runtime.
Resolves SR-4248.