[5.9.0] Fix serialization and type-checking issues with extension macros that introduce conformances #68175
Conversation
This file contains hidden or 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
Fix two inter-related issues with extension macros that provide conformances to a protocol, the combined effect of which is that one cannot meaningfully provide extension macros that implement conformances to a protocol like Equatable or Hashable that also supports auto-synthesis. The first issue involves name lookup of operators provided by macro expansions. The logic for performing qualified lookup in addition to unqualified lookup (for operators) did not account for extension macros in the same manner as it did for member macros, so we would not find a macro-produced operator (such as operator==) in witness matching. The second issue is more fundamental, which is that the conformance lookup table would create `NormalProtocolConformance` instances for pre-macro-expansion conformance entries, even though these should always have been superseded by explicit conformances within the macro expansion buffers. The end result is that we could end up with two `NormalProtocolConformance` records for the same conformance. Some code was taught to ignore the pre-expansion placeholder conformances, other code was not. Instead, we now refuse to create a `NormalProtocolConformance` for the pre-expansion entries, and remove all of the special-case checks for this, so we always using the superseding explicit conformances produced by the macro expansions (or error if the macros don't produce them). Fixes rdar://113994346 / swiftlang#66348 (cherry picked from commit fa48076)
…nces Pre-macro-expansion conformances are introduced at the point where an attached extension macro is attached to a particular nominal type, and can imply other conformances. Once the macro is expanded, they are expected to be replaced by the real conformance from the extension produced by the macro. This includes any other conformances that are implied by that conformances. Ensure that the real conformance---and every conformances it implies---are considered "better" than the pre-expansion conformances. Fixes a bug where we would pick the wrong (pre-expansion) conformances, which would then fail to get fully type-checked prior to serialization. This could accept invalid code that then crashed the compiler, as in rdar://112916159. (cherry picked from commit ab576b3) (cherry picked from commit 5fb5a27)
|
@swift-ci please test |
hborla
approved these changes
Aug 28, 2023
|
@swift-ci please test macOS |
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.
Tracked by rdar://113994346 & rdar://112916159.