[5.9] [Macros] Tighten declaration semantics and improve expansion of freestanding macros - #66527
Merged
DougGregor merged 6 commits intoJun 10, 2023
Conversation
DougGregor
commented
Jun 10, 2023
DougGregor
commented
Member
- Explanation: Implement missing-but-required declaration semantics for macro declarations, including diagnosing the presence of a result type on a macro that isn't a freestanding expression macro (it can't be used) and diagnosing multiple freestanding roles on a given macro declaration (SE-0397 requires this). While here, thread the intended freestanding macro role through to the macro expansion code, providing better diagnostics when there is a mismatch between the macro declaration and its implementations (previously, we would crash).
- Scope: Narrow; only affects validation of freestanding macro declarations and expansions.
- Risk: Low; narrow change to perform better validation when declaring and expanding freestanding macros.
- Reviewed by: @rintaro , @ahoppen
- Issue: rdar://108871352, rdar://110418969, rdar://110178899
- Original pull request: [Macros] Only freestanding expression macros can have a non-Void result type #66504, [Macros] Provide the freestanding macro role for expansion operations. #66509, [Macros] Tighten restriction on non-expression macros not having return types #66526
…lt type Fixes rdar://108871352. (cherry picked from commit 759f520)
The compiler knows (from a macro declaration) what freestanding macro role a macro implementation is expected to implement. Pass that through to the macro expansion code itself, rather than guessing based on the protocol conformances of the implementation type. We already use this approach with attached macros, so this is more of the same. Eliminates a crash and improves diagnostics when the freestanding macro role and its implementation are out of sync, fixing rdar://110418969. (cherry picked from commit 3c04cff)
Per SE-0397, a macro may only have a single freestanding macro role, otherwise we would have an ambiguity in how a particular freestanding macro would be expanded. Produce an error on such macro declarations. Fixes rdar://110178899. (cherry picked from commit c5ec389)
Member
Author
|
@swift-ci please test |
hborla
approved these changes
Jun 10, 2023
…rn types There is no reason to special-case `Void` to permit it. Rather, make this a syntactic rule. Thanks to Alex Hoppen for the suggestion.
…terfaces This allows us to continue to accept Swift interface files created with older versions of the Swift 5.9 compiler that emitted a spurious `-> ()` on non-expression macro declarations.
DougGregor
force-pushed
the
freestanding-macro-cleanups-5.9
branch
from
June 10, 2023 06:27
6ab34fb to
c72f379
Compare
Member
Author
|
@swift-ci please test |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.