Skip to content

[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

Merged

Conversation

LucianoPAlmeida
Copy link
Contributor

@LucianoPAlmeida LucianoPAlmeida commented Jun 28, 2020

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

…t be determined statically were producing misleading warnings
@LucianoPAlmeida LucianoPAlmeida force-pushed the SR-13081-cast-unrelated branch from 6b9b934 to 47c1baa Compare June 28, 2020 21:33
@LucianoPAlmeida
Copy link
Contributor Author

@swift-ci please smoke test

@LucianoPAlmeida LucianoPAlmeida force-pushed the SR-13081-cast-unrelated branch from 47c1baa to 24d968a Compare June 28, 2020 22:56
@LucianoPAlmeida LucianoPAlmeida force-pushed the SR-13081-cast-unrelated branch from 24d968a to 6bcb9a9 Compare June 28, 2020 22:58
@varungandhi-apple
Copy link
Contributor

varungandhi-apple commented Jun 28, 2020

We need to manually re-run tests after force-pushing. 🙂

@swift-ci please smoke test

@LucianoPAlmeida LucianoPAlmeida force-pushed the SR-13081-cast-unrelated branch from 59e81d1 to 43f1401 Compare June 29, 2020 02:08
@LucianoPAlmeida
Copy link
Contributor Author

@varungandhi-apple I've adjusted the comment and add an extra test case, let me know what you think :)

Copy link
Contributor

@hamishknight hamishknight left a 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
@LucianoPAlmeida LucianoPAlmeida force-pushed the SR-13081-cast-unrelated branch from 3dc5437 to 8ea2a69 Compare June 30, 2020 00:41
@LucianoPAlmeida LucianoPAlmeida force-pushed the SR-13081-cast-unrelated branch from 3ad1bb1 to ec3acbf Compare June 30, 2020 02:18
@LucianoPAlmeida LucianoPAlmeida force-pushed the SR-13081-cast-unrelated branch from 82842b3 to 101a5c1 Compare July 2, 2020 12:54
Copy link
Contributor

@hamishknight hamishknight left a 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!

@LucianoPAlmeida
Copy link
Contributor Author

@hamishknight Thanks for the great help here!

@LucianoPAlmeida
Copy link
Contributor Author

@swift-ci Please smoke test

Copy link
Contributor

@xedin xedin left a 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!

@LucianoPAlmeida
Copy link
Contributor Author

Thanks @xedin :)

@LucianoPAlmeida
Copy link
Contributor Author

@swift-ci Please smoke test Windows platform

@LucianoPAlmeida
Copy link
Contributor Author

Seems like window build is not being triggered automatically ...

@hamishknight
Copy link
Contributor

@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".

@LucianoPAlmeida
Copy link
Contributor Author

but I guess Github didn't update to show it

Ahh true, we've seen this in some other PRs

@LucianoPAlmeida
Copy link
Contributor Author

@swift-ci Please smoke test Windows platform

@LucianoPAlmeida LucianoPAlmeida merged commit 28fb66c into swiftlang:master Jul 3, 2020
@LucianoPAlmeida
Copy link
Contributor Author

Thank you guys! I'll try to put up a follow up for the remaining two soon :)

@LucianoPAlmeida LucianoPAlmeida deleted the SR-13081-cast-unrelated branch July 3, 2020 01:08
@xedin
Copy link
Contributor

xedin commented Jul 3, 2020

@LucianoPAlmeida Please don't forget to resolve all of the JIRAs :)

@LucianoPAlmeida
Copy link
Contributor Author

Sure! Just resolved :)

Copy link
Collaborator

@AnthonyLatsis AnthonyLatsis left a 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,
Copy link
Collaborator

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:
Copy link
Collaborator

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))
Copy link
Collaborator

@AnthonyLatsis AnthonyLatsis Jul 4, 2020

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?

Copy link
Contributor Author

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)) {
Copy link
Collaborator

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

Copy link
Contributor Author

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
Copy link
Collaborator

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
Copy link
Collaborator

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.
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants