Skip to content

[ConstraintSystem] Fix crash on function conversion reliant on conditional conformance #25721

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
merged 7 commits into from
Jun 24, 2019
Merged

[ConstraintSystem] Fix crash on function conversion reliant on conditional conformance #25721

merged 7 commits into from
Jun 24, 2019

Conversation

theblixguy
Copy link
Collaborator

This PR fixes a compiler crasher related to a function conversion reliant on conditional conformance. Example:

protocol P {}
struct S<T> {}
extension S : P where T : P {}

func foo(_ fn: (S<String>) -> Void) {}
func bar(_ fn: (P) -> Void) {
  foo(fn)
}

Resolves SR-10992.

@theblixguy
Copy link
Collaborator Author

theblixguy commented Jun 24, 2019

cc @xedin I have added a new overload for getConstraintLocator based on your suggestion!

@xedin xedin self-requested a review June 24, 2019 21:07
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.

@theblixguy Could you please convert example from validation test to the one which checks produces diagnostic? Also I think there are probably more places which could benefit from using this new method, at least CSDiagnostics probably should.

How about adding new getConstraintLocator method to FailureDiagnostic itself to avoid unnecessary indirection?

@theblixguy
Copy link
Collaborator Author

theblixguy commented Jun 24, 2019

@xedin Do you mean you want the exact same method in FailureDiagnostic as well (which would then internally call CS.getConstraintLocator(anchor, path, flags))?

I kept it in CS so the declaration stays in one place (instead of multiple copies).

@xedin
Copy link
Contributor

xedin commented Jun 24, 2019

@theblixguy Yes, I think it could be done separately but it would make sense to call it on FailureDiagnostic instead of current indirect way. At least it would be great to audit where summaryFlags is set to 0 at the moment and change that here.

@theblixguy
Copy link
Collaborator Author

@xedin Okay, I have added it to FailureDiagnostic! Found two more uses of summaryFlags being 0 which I removed.

@xedin
Copy link
Contributor

xedin commented Jun 24, 2019

@swift-ci please test

@theblixguy
Copy link
Collaborator Author

All tests have passed! I'll cherry pick this to 5.1 if that's okay?

@xedin xedin merged commit b72b3cb into swiftlang:master Jun 24, 2019
@xedin
Copy link
Contributor

xedin commented Jun 24, 2019

@theblixguy Sounds good, thanks!

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.

2 participants