-
Notifications
You must be signed in to change notification settings - Fork 10.5k
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
[Macros] Implement support for function body macros on closures. #79980
Conversation
@swift-ci please smoke test |
34715fe
to
1a93808
Compare
@swift-ci please smoke test |
… and up to `}` The macro is not allowed to write explicit type or `in` keyword.
…lkToClosureExprPre` If closure body is expanded in expression context we need to do some special handling to make sure that source ranges are not completely broken.
The closures are type-checked after macros are expanded which means that macro cannot reference any declarations from inner or outer closures as its arguments. For example: `_: (Int) -> Void = { x in { @macro(x) in ... }() }` `x` is not going to be type-checked at macro expansion time and cannot be referenced by `@Macro`. Let's walk up declaration contexts until we find first non-closure one. This means that we can support a local declaration that is defined inside of a closure because they are separately checked after outer ones are already processed.
expanding an attached macro. This fixes a crash in one of the attached macro tests.
1a93808
to
ab19ad2
Compare
@swift-ci please smoke test |
@@ -1568,6 +1581,142 @@ static SourceFile *evaluateAttachedMacro(MacroDecl *macro, Decl *attachedTo, | |||
return macroSourceFile; | |||
} | |||
|
|||
static SourceFile *evaluateAttachedMacro(MacroDecl *macro, | |||
ClosureExpr *attachedTo, |
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.
Much of this code is duplicated from the other overload of evaluateAttachedMacro
that accepts a Decl *
, but it's probably not hard to generalize using ASTNode
instead.
Test failures
are due to extra outputs were detected, e.g.
This is from |
@rintaro ah, thank you! I think those print statements are problematic, because no matter what I check first, it's expected for the result to be |
@swift-ci please smoke test |
This code path isn't on an error path, and the print statement causes unnecessary build output, which also causes test failures.
6e5c924
to
e2aed1f
Compare
@swift-ci please smoke test |
a predicate. The new overload is used during macro expansion to find the nearest syntax node that is either a `DeclSyntax` or a `ClosureExprSyntax`. This avoids an issue where calling the overload that accepts a specific type may find an outer, unrelated declaration or closure.
@swift-ci please smoke test |
@swift-ci please smoke test Linux |
@swift-ci please test Windows |
This change adds support for function body macros on closure expressions, gated behind the
ClosureBodyMacro
experimental feature.This is pitched at https://forums.swift.org/t/pre-pitch-closure-body-macros/78534. The implementation does not match the current pitch for type checking behavior of macro arguments and expansions; I'll make that change in a follow up PR.