Skip to content

[ConstraintGraph] Disallow subtype constraint contractions #11855

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
Sep 12, 2017

Conversation

xedin
Copy link
Contributor

@xedin xedin commented Sep 11, 2017

Presently subtype constraint is considered a candidate for contraction
via shouldContractEdge when left-hand side of the subtype constraint
is an inout type with type variable inside. Although it's intended to
be used only in combination with BindParam constraint assigned to the
same variable, that is actually never checked and contraction of subtype
constraint like that is invalid.

Resolves: rdar://problem/34333874

@xedin xedin requested a review from rudkx September 11, 2017 21:06
@xedin xedin force-pushed the disallow-subtype-contractions branch from 2f1330e to ac311a0 Compare September 11, 2017 21:09
@xedin
Copy link
Contributor Author

xedin commented Sep 11, 2017

@swift-ci please smoke test

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.

Otherwise LGTM.

$0.b = 0
}

print(rdar34333874)
Copy link
Contributor

Choose a reason for hiding this comment

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

newline

}

let rdar34333874 = foo(C()) {
$0.a = 42
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this really testing the same thing as the reported bug? This actually is mutating the input whereas the bug report wasn't.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Example from the rdar does modify fields of $0

Copy link
Contributor

Choose a reason for hiding this comment

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

The actual original code did mutate input inside the closure. I'd suggest testing both cases to be on the safe side.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, sounds good, I'll add one which doesn't mutate the fields.

// RUN: rm -rf %t
// RUN: mkdir -p %t
// RUN: %target-build-swift %s -o %t/a.out
// RUN: %target-run %t/a.out
Copy link
Contributor

Choose a reason for hiding this comment

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

Drive-by comment: This should be %target-run-simple-swift, which gets run in more situations.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, @jrose-apple ! I didn't know that existed...

@xedin xedin force-pushed the disallow-subtype-contractions branch from ac311a0 to f7960bc Compare September 11, 2017 21:25
@xedin
Copy link
Contributor Author

xedin commented Sep 11, 2017

@swift-ci please smoke test

return this
}

let rdar34333874 = foo(C()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, apparently I didn't submit my comment about the test. Are you sure this is testing the same thing as the original report? This appears to actually be mutating something whereas the original report wasn't.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Both me and @swiftix replied to that one and I've added one more test in addition to the mutating one from SR-5861 which does mutate the fields of the argument.

Presently subtype constraint is considered a candidate for contraction
via `shouldContractEdge` when left-hand side of the subtype constraint
is an inout type with type variable inside. Although it's intended to
be used only in combination with BindParam constraint assigned to the
same variable, that is actually never checked and contraction of subtype
constraint like that is invalid.

Resolves: rdar://problem/34333874
@xedin xedin force-pushed the disallow-subtype-contractions branch from f7960bc to 0a178fd Compare September 11, 2017 22:13
@xedin
Copy link
Contributor Author

xedin commented Sep 11, 2017

I've fixed a problem in isStrictInoutSubtypeConstraint which returned true only if the left-hand side of the subtype with inout is not a type-variable, which allowed bind params to contracted incorrectly and added one more test with a single statement closure.

@xedin
Copy link
Contributor Author

xedin commented Sep 11, 2017

@swift-ci please smoke test

@xedin
Copy link
Contributor Author

xedin commented Sep 11, 2017

@swift-ci please test source compatibility

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