[Macros] Only freestanding expression macros can have a non-Void result type #66504
Conversation
…lt type Fixes rdar://108871352.
|
@swift-ci please smoke test and merge |
| // If the macro has a (non-Void) result type, it must have the freestanding | ||
| // expression role. Other roles cannot have result types. | ||
| if (auto resultTypeRepr = MD->getResultTypeRepr()) { | ||
| if (!MD->getMacroRoles().contains(MacroRole::Expression) && |
There was a problem hiding this comment.
If a macro had multiple roles (including freestanding(expression)), should we reject non-void types in that case too?
@attached(accessor) @freestanding(expression)
macro Foo() -> IntBecause in this case the return type -> Int still doesn't make sense for the accessor role.
There was a problem hiding this comment.
No, I don't think we should. The result type only applies to the expression role, and it's fine for it to be ignored for any attached roles.
Note that we don't currently diagnose when a macro has multiple freestanding roles. I'm handling that (and related cleanup) via a separate pull request
| // expected-note@-3{{make this macro a freestanding expression macro}}{{1-1=@freestanding(expression)\n}} | ||
| // expected-note@-4{{remove the result type if the macro does not produce a value}}{{67-74=}} | ||
|
|
||
| @freestanding(declaration) macro nonExpressionReturnsVoid<T>(_: T) -> Void = #externalMacro(module: "A", type: "B") |
There was a problem hiding this comment.
I don’t think we should be allowing the declaration of any return type for non-freestanding-expression macros. Specifying Void here just doesn’t make any sense to me.
There was a problem hiding this comment.
Okay, I agree with that. #66526
Fixes rdar://108871352.