-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[SILGen] Always serialize witness tables in non-resilient modules #20390
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
[SILGen] Always serialize witness tables in non-resilient modules #20390
Conversation
@swift-ci Please test |
@swift-ci Please benchmark |
@swift-ci Please test source compatibility |
Build comment file:No performance and code size changesHow 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 regressions before you merge the PR. Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein). Hardware Overview
|
lib/AST/ProtocolConformance.cpp
Outdated
// FIXME: Looking at the type is not the right long-term solution. We need an | ||
// explicit mechanism for declaring conformances as 'fragile', or even | ||
// individual witnesses. | ||
if (!getType()->getAnyNominal()->isFormallyResilient()) |
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.
Why is this checking isFormallyResilient() and not isResilient()? It seems weird for a resilient module (one defining the conformance) to depend on a non-resilient module (the one defining the type).
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.
I was assuming that couldn't happen with a public type because everything would break, but I'll change it back if you want.
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, I think any change at the SIL level and below should use isResilient() and not isFormallyResilient().
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 isn't at the SIL level, though. I'm about to use it for an AST thing.
Build failed |
Failure seems unrelated. @swift-ci Please test macOS |
...even if the conforming nominal type is resilient. It's the owner of the conformance whose resilience matters. I also factored this part out into a separate check at the AST level so we can tweak it, and also so I can use it to (slightly) speed up compiling a resilient swiftinterface.
b51b1c8
to
8af5216
Compare
I'd still like to run the source compat suite, if it's fixed soon, but meanwhile… @swift-ci Please smoke test |
@swift-ci Please smoke test |
@swift-ci Please test source compatibility |
...even if the conforming nominal type is resilient. It's the owner of the conformance whose resilience matters.
I also factored this part out into a separate check at the AST level so we can tweak it, and also so I can use it to (slightly) speed up compiling a resilient swiftinterface.