-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Sema: Clean up handling of protocol operators with concrete operands #28788
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
Sema: Clean up handling of protocol operators with concrete operands #28788
Conversation
@DougGregor @xedin This eliminates the second-to-last typeCheckExpression() call from inside CSApply. The last one is in the handling of EditorPlaceholderExpr. |
15beef8
to
d13f603
Compare
In this case we would "devirtualize" the protocol requirement call by building the AST to model a direct reference to the witness. Previously this was done by recursively calling typeCheckExpression(), but the only thing this did was recover the correct substitutions for the call. Instead, we can just build the right SubstitutionMap directly. Unfortunately, while we serialize enough information in the AST to devirtualize calls at the SIL level, we do not for AST Exprs. This is because SIL devirtualization builds a reference to the witness thunk signature, which is an intermediate step between the protocol requirement and the witness. I get around this by deriving the substitutions from walking in parallel over the interface type of the witness, together with the inferred type of the call expression.
d13f603
to
594044a
Compare
@swift-ci Please smoke test |
@swift-ci Please test source compatibility |
@swift-ci Please test source compatibility Release |
@swift-ci Please benchmark |
@swift-ci Please test source compatibility Release |
Performance: -OCode size: -OPerformance: -Osize
Code size: -OsizePerformance: -OnoneCode size: -swiftlibsHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
More peeling off refactorings from #28698.
In this case we would "devirtualize" the protocol requirement call
by building the AST to model a direct reference to the witness.
Previously this was done by recursively calling typeCheckExpression(),
but the only thing this did was recover the correct substitutions
for the call.
Instead, we can just build the right SubstitutionMap directly.
Unfortunately, while we serialize enough information in the AST
to devirtualize calls at the SIL level, we do not for AST Exprs.
This is because SIL devirtualization builds a reference to the
witness thunk signature, which is an intermediate step between
the protocol requirement and the witness. I get around this by
deriving the substitutions from walking in parallel over the
interface type of the witness, together with the inferred type
of the call expression.