Allow keywords after `#` in freestanding macro expansions
There is no reason why we shouldn’t allow keywords here.
I also thought about allowing keywords after `@` but things become tricky here for two reasons:
- In the parser, we parse a type after the `@`, which could start with a keyword itself (e.g. `any`). If we want to keep the parser logic to parse a type after `@` (which I think we should), then it becomes unclear what `@any T` should parse as.
- We allow a space between `@` and the type name. This makes it very hard for recovery to tell whether `@ struct` refers to an attribute with name `struct` or if the user forgot to write the attribute name after `@`.
Since almost all keywords are lowercase and attached member macros are usually spelled with an uppercase name, there are a lot fewer chances for clashes here, so I don’t think it’s worth allowing keywords after `@`.
https://github.com/apple/swift/issues/66444
rdar://110472060
* Unify macro expansion parsing logic between MacroExpansionExpr and
MacroExpansionDecl
* Diagnose whitespace between '#' and the macro name
* Diagnose keyword as a macro name
* Parse `#<identifier>` attribute list as a `MacroExpansionDecl`
regardless of the position
* Diagnose whitespaces between `#` and the macro name.
* Correctly attach attributes to `MacroExpansionDecl`
* Fix `OrigDeclAttributes` to handle modifiers (use `getLocation()`
instead of `AtLoc`.)
Type checking is a TODO
rdar://107386648
Introduce `MacroExpansionExpr` and `MacroExpansionDecl` and plumb it through. Parse them in roughly the same way we parse `ObjectLiteralExpr`.
The syntax is gated under `-enable-experimental-feature Macros`.
