-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Sema] Omit recording some conversion restrictions in constraint solutions #18494
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
Conversation
…ust as easily figure out itself from the shape of the types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems reasonable to me. For posterity - the reason why we can avoid recording these restriction types is because coerceToType
already detects and handles them after the restriction switch so this is effectively a code deduplication.
@gregomni I guess alternative approach might be to keep restrictions but remove follow up code in Looks like source compatibility testing is broken at the moment so let's wait a bit before merging this, just in case we've missed something. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this seems totally reasonable.
@swift-ci please test source compatibility |
@swift-ci please test |
@swift-ci please smoke test compiler performance |
Omit recording conversion restrictions in a solution that apply can just as easily figure out itself from the shape of the types. This is an implementation discussed in #18345.
Helps resolve SR-8314.
Recording and simplifying these types of restrictions takes almost 75% of the total compilation time in the test file in SR-8314, and by inspection, the coercion code executed in CSApply is exactly the same with or without.