Skip to content

[Serialization] Deal with ErrorTypes in specialized conformances #17523

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Jun 28, 2018
Merged

[Serialization] Deal with ErrorTypes in specialized conformances #17523

merged 1 commit into from
Jun 28, 2018

Conversation

jrose-apple
Copy link
Contributor

This can represent a conformance that can never actually be used, such as an inherited conditional conformance where the subclass has provided a concrete generic parameter. (See the test case.)

We probably shouldn't be forming these conformances at all, but for now this lets us build without errors. Alternate solution compared to #17406.

SR-7337 / rdar://problem/39142121

@jrose-apple jrose-apple requested review from slavapestov and huonw June 26, 2018 20:08
@jrose-apple
Copy link
Contributor Author

Note that this is going straight to the 4.2 branch, since we don't serialize Substitutions like this at all on master.

@swift-ci Please test

@jrose-apple
Copy link
Contributor Author

@swift-ci Please test source compatibility

DougGregor
DougGregor approved these changes Jun 26, 2018
View reviewed changes
Copy link
Member

@DougGregor DougGregor 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 doing this. I had thought we'd addressed this issues well-enough to get through 4.2, but tolerating error types seems reasonable.

This was referenced Jun 26, 2018
Closed
Merged
@jrose-apple
Copy link
Contributor Author

Oops, a bit of another change slipped in. Will fix. Source compatibility test here.

@jrose-apple
[Serialization] Deal with ErrorTypes in specialized conformances
04cfdbf 
This can represent a conformance that can never actually be used, such
as an inherited conditional conformance where the subclass has
provided a concrete generic parameter. (See the test case.)

We probably shouldn't be forming these conformances at all, but for now
this lets us build without errors.

https://bugs.swift.org/browse/SR-7337
@jrose-apple
Copy link
Contributor Author

@swift-ci Please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 834da5fc0625017e8fb6567b8f268babaa18c8ba

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - 834da5fc0625017e8fb6567b8f268babaa18c8ba

@jrose-apple
Copy link
Contributor Author

Hm, there was a failure building CoreStore that doesn't seem to be present normally. Need to look into this before merging.

@jrose-apple
Copy link
Contributor Author

Reproduced.

@jrose-apple
Copy link
Contributor Author

After a day's worth of investigation, it looks like the CoreStore problem wasn't due to this change. Let's try again.

@swift-ci Please test source compatibility

@jrose-apple
Copy link
Contributor Author

@swift-ci Please test source compatibility

@jrose-apple jrose-apple merged commit 5e45c5f into swiftlang:swift-4.2-branch Jun 28, 2018
@jrose-apple jrose-apple deleted the just-deal-with-it branch June 28, 2018 00:21
@belkadan belkadan mentioned this pull request Jun 26, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@DougGregor DougGregor DougGregor approved these changes

@slavapestov slavapestov Awaiting requested review from slavapestov

@huonw huonw Awaiting requested review from huonw

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@jrose-apple @swift-ci @DougGregor