-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[SR-13088] Fix false positive downcast unrelated of types that cannot be statically known #32592
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-13088] Fix false positive downcast unrelated of types that cannot be statically known #32592
Conversation
…t be determined statically were producing misleading warnings
6b9b934
to
47c1baa
Compare
@swift-ci please smoke test |
47c1baa
to
24d968a
Compare
24d968a
to
6bcb9a9
Compare
We need to manually re-run tests after force-pushing. 🙂 @swift-ci please smoke test |
59e81d1
to
43f1401
Compare
@varungandhi-apple I've adjusted the comment and add an extra test case, let me know what you think :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking this on!
… to stdlib collection type before emit an downcast warning
…nElement to be able to verify special cases within typeCheckCheckedCast for collection elements
3dc5437
to
8ea2a69
Compare
… check both subtype and supertype
3ad1bb1
to
ec3acbf
Compare
…de couldDynamicConform
82842b3
to
101a5c1
Compare
…Dynamically conform.
59dec49
to
31808e8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for wading through all my feedback, this looks good to me!
@hamishknight Thanks for the great help here! |
@swift-ci Please smoke test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great! Thank you, @LucianoPAlmeida!
Thanks @xedin :) |
@swift-ci Please smoke test Windows platform |
Seems like window build is not being triggered automatically ... |
@LucianoPAlmeida It was (https://ci-external.swift.org/view/Pull%20Request/job/swift-PR-windows/4769/), but I guess Github didn't update to show it. You can always check by going to https://ci-external.swift.org, and clicking "Pull Request" > "Swift Pull Request Windows". |
Ahh true, we've seen this in some other PRs |
@swift-ci Please smoke test Windows platform |
Thank you guys! I'll try to put up a follow up for the remaining two soon :) |
@LucianoPAlmeida Please don't forget to resolve all of the JIRAs :) |
Sure! Just resolved :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great overall. The Encodable
false-positive in the stdlib has been an eyesore during builds for a quite some time now!
@@ -3357,7 +3357,14 @@ CheckedCastKind TypeChecker::typeCheckCheckedCast(Type fromType, | |||
const auto &fromElt = fromTuple->getElement(i); | |||
const auto &toElt = toTuple->getElement(i); | |||
|
|||
if (fromElt.getName() != toElt.getName()) | |||
// We should only perform name validation if both element have a label, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- if both element
+ if both elements
|
||
ModuleDecl *M = DC->getParentModule(); | ||
// For standard library collection types such as Array, Set or Dictionary | ||
// which have custom casting machinery implemented in situations like: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"implemented in" sounds a bit off. How about "implemented for", just "for" or "used in"?
// archetypes of the destination type. Or, if it's possible to substitute | ||
// the generic arguments of the destination type with the generic archetypes | ||
// of the source type, we perform a downcast instead. | ||
if (toType->isBindableTo(fromType) || fromType->isBindableTo(toType)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- generic archetypes
+ archetypes
In regards to the comment, is it not the other way around with isBindableTo
– we are trying to bind the archetypes of one to the generic arguments of the other?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, if the (up/down)cast is possible
} | ||
if (auto *protocolDecl = | ||
dyn_cast_or_null<ProtocolDecl>(fromType->getAnyNominal())) { | ||
if (!couldDynamicallyConformToProtocol(toType, protocolDecl, dc)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you planning to cover existential types in general in a follow-up?
let foo: P & Q = ...
let mightSucceed = foo as? ToType
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We didn't think in that protocol composition case I think, I'm working on a followup ... will add this as well :)
bool | ||
TypeChecker::couldDynamicallyConformToProtocol(Type type, ProtocolDecl *Proto, | ||
DeclContext *DC) { | ||
// An existential may have a concrete underlying type with protocol conformances |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: // The dynamic type of an existential might conform to the protocol.
if (type->isExistentialType()) | ||
return true; | ||
|
||
// A generic archetype may have protocol conformances we cannot know |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: // The dynamic type of an archetype might conform to the protocol.
// } | ||
// we are skipping checking conditional requirements using lookupConformance, | ||
// as an intermediate collection cast can dynamically change if the conditions | ||
// are met or not. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion:
- // we are skipping checking conditional requirements using lookupConformance,
- // as an intermediate collection cast can dynamically change if the conditions
- // are met or not.
+ //
+ // We skip checking any conditional requirements using lookupConformance,
+ // because an intermediate collection cast can dynamically change depending on
+ // whether these conditions are met.
This adjusts rules around the diagnostics on unrelated types of edge cases for types that are erased or involve existential which may have conditional conformances.
It almost resolves SR-13088.
Resolves aggregates:
SR-13081
SR-13035
SR-11434
SR-12321
SR-13025
TODO:
SR-7187, SR-6112