Skip to content

Fix an issue with the constraint favoring code in the constraint opti… #14584

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
Feb 13, 2018
Merged

Fix an issue with the constraint favoring code in the constraint opti… #14584

merged 1 commit into from
Feb 13, 2018

Conversation

rudkx
Copy link
Contributor

@rudkx rudkx commented Feb 13, 2018

…mizer.

The code was favoring overloads where either argument matched its
parameter type and where both parameter types were the same. This
is really overly broad and can result in bugs like the one here, where
we only attempt the

  (Int, Int) -> Bool

overload of '!=' despite the fact that it means forcing an
optional. We should select the

  <T>(T?, T?) -> Bool

overload instead, and inject the non-optional operand into an optional.

Fixes rdar://problem/37073401.

@rudkx
Copy link
Contributor Author

rudkx commented Feb 13, 2018

@swift-ci Please smoke test

@rudkx
Copy link
Contributor Author

rudkx commented Feb 13, 2018

@swift-ci Please test source compatibility

@rudkx
Copy link
Contributor Author

rudkx commented Feb 13, 2018

@swift-ci Please smoke test

@rudkx
Copy link
Contributor Author

rudkx commented Feb 13, 2018

@swift-ci Please test source compatibility

…mizer.

The code was favoring overloads where *either* argument matched its
parameter type and where both parameter types were the same. This
is really overly broad and can result in bugs like the one here, where
we only attempt the
  (Int, Int) -> Bool
overload of '!=' despite the fact that it means forcing an
optional. We should select the
  <T>(T?, T?) -> Bool
overload instead, and inject the non-optional operand into an optional.

Making this require *both* arguments to match mostly disables this
optimization, though, since for somethin like "a"+"b"+"c" the second
add has a type variable and string literal as arugments.

So instead, we'll just disable this in cases where one argument is the
optional of the other, to ensure we never try forcing one side. This
also means we'll disable the optimization in cases where we would
inject one operand into an optional, but that's likely find as we
don't have long chains of expressions where that happens.

Fixes rdar://problem/37073401.
@rudkx
Copy link
Contributor Author

rudkx commented Feb 13, 2018

@swift-ci Please smoke test

@rudkx
Copy link
Contributor Author

rudkx commented Feb 13, 2018

@swift-ci Please test source compatibility

1 similar comment
@rudkx
Copy link
Contributor Author

rudkx commented Feb 13, 2018

@swift-ci Please test source compatibility

@rudkx rudkx merged commit cfca329 into swiftlang:master Feb 13, 2018
@rudkx rudkx deleted the rdar37073401 branch February 13, 2018 23:34
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.

1 participant