Skip to content

[Sema][CSApply] Be more conservative while emitting always true conversion diagnostic #34980

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 12 commits into from
Feb 10, 2021

Conversation

LucianoPAlmeida
Copy link
Contributor

Be more conservative on always true conversion diagnostics when functions are involved.

Resolves SR-13789.

@tbkka
Copy link
Contributor

tbkka commented Dec 7, 2020

@hborla -- Do you think this is the right approach? The question here is how to best deal with the fact that function casts behave differently in the runtime and compiler (the compiler can perform argument/return type conversions that the runtime cannot perform). The previous code emitted some inappropriate diagnostics because of this distinction.

@LucianoPAlmeida
Copy link
Contributor Author

@hborla -- Do you think this is the right approach? The question here is how to best deal with the fact that function casts behave differently in the runtime and compiler (the compiler can perform argument/return type conversions that the runtime cannot perform). The previous code emitted some inappropriate diagnostics because of this distinction.

@tbkka I don't have a deep understanding of the runtime, but from the tests I ran, the runtime couldn't perform any cast other than when the function types were equal, is that really the case? Or there are other situations when the runtime cast is possible?
Because if this always fails, I thought that maybe we can emit a tailored "runtime cannot perform, cast always fails" warning, but not sure, I end up being more conservative to avoid false positives.

@tbkka
Copy link
Contributor

tbkka commented Dec 9, 2020

The runtime can only cast functions when the arguments and return type are exactly identical. The only permitted difference is in throwing. You can read the details here:
https://github.com/apple/swift/blob/d5d9e48d37654054cd6fdcc834fd98c54e64a051/stdlib/public/runtime/DynamicCast.cpp#L1167

@LucianoPAlmeida
Copy link
Contributor Author

Awesome! Thanks for the reference :)
We can definitely detect those situations and otherwise emit a warning that the runtime cannot convert the types. WDYT?

Copy link
Contributor

@xedin xedin left a comment

Choose a reason for hiding this comment

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

I think makes sense to align solver with runtime but instead of CSApply do more checking simplifyCheckedCastConstraint instead and record an appropriate warning there.

@LucianoPAlmeida
Copy link
Contributor Author

This is not ready yet, as it still has a lot of things to fix as it requires some changes involving TypeChecker::typeCheckCheckedCast, I'll ping you as soon as I can make this work :)

@LucianoPAlmeida LucianoPAlmeida force-pushed the SR-13789 branch 17 times, most recently from f66a544 to cbabc8e Compare December 23, 2020 12:14
@LucianoPAlmeida
Copy link
Contributor Author

@swift-ci Please smoke test

@LucianoPAlmeida LucianoPAlmeida force-pushed the SR-13789 branch 2 times, most recently from 74140c6 to 9ddaa03 Compare December 25, 2020 19:23
Copy link
Contributor

@xedin xedin left a comment

Choose a reason for hiding this comment

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

I think we are almost there, just a couple more minor comments.

@LucianoPAlmeida
Copy link
Contributor Author

@xedin Thanks for the review! I think all points were addressed :)

@LucianoPAlmeida
Copy link
Contributor Author

@swift-ci Please smoke test

@LucianoPAlmeida LucianoPAlmeida requested a review from xedin February 9, 2021 11:05
@LucianoPAlmeida
Copy link
Contributor Author

@swift-ci Please smoke test

@LucianoPAlmeida
Copy link
Contributor Author

There is a lot of commits, I think will be a good idea just to squash this one. WDYT?

@xedin
Copy link
Contributor

xedin commented Feb 10, 2021

Sounds good to me!

@LucianoPAlmeida LucianoPAlmeida merged commit d55eed4 into swiftlang:main Feb 10, 2021
@LucianoPAlmeida LucianoPAlmeida deleted the SR-13789 branch February 10, 2021 11:31
@LucianoPAlmeida
Copy link
Contributor Author

Squashed! Thank you @xedin :)

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