Skip to content

[ConstraintSystem] Replace curry level with a boolean flag #19947

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 4 commits into from
Oct 20, 2018

Conversation

xedin
Copy link
Contributor

@xedin xedin commented Oct 18, 2018

Arbitrary currying is no longer allowed so level could be switched
to a boolean flag for methods like computeDefaultMap to identify
if they need to look through curried self type or not.

Since arbitrary currying is no longer allowed `level` could
be replaced with the boolean flag which identifies if curried
`self` should be skipped or not.
@xedin xedin requested a review from rudkx October 18, 2018 23:49
@xedin
Copy link
Contributor Author

xedin commented Oct 18, 2018

Follow-up to #19934 as suggested by @rudkx

@xedin xedin force-pushed the replace-curry-level-with-flag branch 2 times, most recently from 8db4762 to 0baff82 Compare October 18, 2018 23:53
Copy link
Contributor

@slavapestov slavapestov left a comment

Choose a reason for hiding this comment

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

Looks great, thanks!

@@ -59,7 +59,7 @@ namespace swift {
///
struct UncurriedCandidate {
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps worth renaming this too :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Are you thinking just to Candidate? :)

Copy link
Contributor

Choose a reason for hiding this comment

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

OverloadCandidate maybe

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good! I'll do that in this PR and cleanup documentation around this.

@@ -587,13 +587,13 @@ getCalleeDeclAndArgs(ConstraintSystem &cs,
SmallVector<LocatorPathElt, 2> path;
auto callExpr = callLocator.getLocatorParts(path);
if (!callExpr)
return std::make_tuple(nullptr, 0, argLabels, hasTrailingClosure);
return std::make_tuple(nullptr, false, argLabels, hasTrailingClosure);
Copy link
Contributor

Choose a reason for hiding this comment

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

When passing ‘false’ as an argument like this it might be more readable if it said: /*hasCurriedSelf=*/false

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, sure, makes sense!

Arbitrary currying is no longer allowed so level could be switched
to a boolean flag for methods like `computeDefaultMap` to identify
if they need to look through curried self type or not.
Copy link
Contributor

@rudkx rudkx left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!

@xedin
Copy link
Contributor Author

xedin commented Oct 19, 2018

@swift-ci please test

@swift-ci

This comment has been minimized.

@swift-ci

This comment has been minimized.

@xedin
Copy link
Contributor Author

xedin commented Oct 19, 2018

@swift-ci please test source compatibility

1 similar comment
@xedin
Copy link
Contributor Author

xedin commented Oct 19, 2018

@swift-ci please test source compatibility

@xedin
Copy link
Contributor Author

xedin commented Oct 20, 2018

Deserialization failures in debug source compatibility suite are unrelated to my changes.

@xedin xedin merged commit 7ca0f46 into swiftlang:master Oct 20, 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.

4 participants