Sema: Narrow down the derivation of == for RawRepresentable enums to non-resilient modules #40382
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…non-resilient modules This change was originally introduced in swiftlang#36752. The problem occurs in the following scenario: - New compiler with this change is used to build a dylib and swiftinterface file for module A, which defines a RawRepresentable enum type E. - Module B imports module A and references == on two E instances. - The module B is run against a dylib of module A built with the old compiler. At this point, module B will not link (or run) because the symbol for E.== is not present in the old dylib for A. The only real solution here is to disable this new optimization when building a module for -enable-library-evolution, unfortunately. In the future, we could make the derived E.== symbol @_alwaysEmitIntoClient. However today, synthesized declarations cannot be @_alwaysEmitIntoClient because they do not have source text that can be emitted into the swiftinterface file. One day, we might gain the ability to print Exprs as source text that parses back in, at which point we could allow synthesized declarations to be @_alwaysEmitIntoClient. Fixes rdar://problem/84912735 and rdar://problem/82919247.
|
@swift-ci Please smoke test |
LucianoPAlmeida
approved these changes
Dec 3, 2021
There was a problem hiding this comment.
Thank you for fixing this and for the detailed explanation @slavapestov!
|
@swift-ci Please smoke test Linux Platform |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change was originally introduced in #36752.
The problem occurs in the following scenario:
New compiler with this change is used to build a dylib and swiftinterface
file for module A, which defines a RawRepresentable enum type E.
Module B imports module A and references == on two E instances.
The module B is run against a dylib of module A built with the old compiler.
At this point, module B will not link (or run) because the symbol for E.==
is not present in the old dylib for A.
The only real solution here is to disable this new optimization when
building a module for -enable-library-evolution, unfortunately.
In the future, we could make the derived E.== symbol @_alwaysEmitIntoClient.
However today, synthesized declarations cannot be @_alwaysEmitIntoClient
because they do not have source text that can be emitted into the
swiftinterface file. One day, we might gain the ability to print Exprs as
source text that parses back in, at which point we could allow synthesized
declarations to be @_alwaysEmitIntoClient.
Fixes rdar://problem/84912735 and rdar://problem/82919247.