Skip to content

Extend SILCombiner code to handle existential self concrete type propagation using ProtocolConformanceAnalysis #18109

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 1 commit into from
Aug 13, 2018

Conversation

rajbarik
Copy link
Contributor

Extend SILCombiner code to handle existential self concrete type propagation using ProtocolConformanceAnalysis.

Prior PR:

@rajbarik
Copy link
Contributor Author

@atrick Could you review this one now?

@rajbarik rajbarik force-pushed the raj-refactor branch 3 times, most recently from 0151185 to 7abdfbc Compare July 25, 2018 20:25
@rajbarik
Copy link
Contributor Author

@atrick @slavapestov Any possibility of getting this review done quicker? Thanks.

Copy link
Contributor

@atrick atrick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This look correct on its own, except for the couple comments above. I'm fine if this goes in and we can review the rest of the design elsewhere.

/// This routine replaces the old witness method inst with a new one.
void SILCombiner::replaceWitnessMethodInst(
FullApplySite Apply, WitnessMethodInst *WMI, SILBuilderContext &BuilderCtx,
const CanType &ConcreteType, ProtocolConformanceRef &ConformanceRef) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think ProtocolConformanceRef should be passed by value.

// Bail, if this existential has a sole conforming type. If there is a sole
// confirming type, we defer the determination of concrete type until cast
// instructions are added in SILCombiner.
if (hasSoleConformingType)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's strange that you would intentionally construct an invalid ConcreteExistentialInfo, presumably to "fill it in" later. I'll have to review the related patches to understand why you need to do this.

@rajbarik
Copy link
Contributor Author

rajbarik commented Aug 1, 2018

@atrick handled your concern, I think. Can you look at it again? Notably, I removed the InitExistential != null check in isValid(). This seems a redundant check given that we are checking everything else to be not null. Also, for using the same isValid() with SoleConformingType, we may not have an InitExistential. Please let me know more concerns soon. I will commit the other PR based on these changes.

@atrick
Copy link
Contributor

atrick commented Aug 2, 2018

LGTM

@slavapestov
Copy link
Contributor

@swift-ci Please smoke test

@rajbarik rajbarik merged commit 971772d into swiftlang:master Aug 13, 2018
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.

3 participants