mirror of
https://github.com/apple/swift.git
synced 2025-12-14 20:36:38 +01:00
fbbbd0d08a
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
52 lines
769 B
Swift
52 lines
769 B
Swift
// RUN: %target-swift-frontend -parse -verify %s
|
|
|
|
#macro
|
|
|
|
#macro(1)
|
|
|
|
#macro(1, 2)
|
|
|
|
_ = #macro(1, 2, 3)
|
|
|
|
_ = #trailing {
|
|
1
|
|
}
|
|
|
|
_ = #trailing() {
|
|
1
|
|
}
|
|
|
|
_ = #trailing(x) {
|
|
1
|
|
}
|
|
|
|
_ = #trailing(x, y, z) {
|
|
1
|
|
} again: {
|
|
2
|
|
} yetAgain: {
|
|
3
|
|
}
|
|
|
|
_ = #another {
|
|
// expected-error @+1 {{expected a macro identifier}}
|
|
#-
|
|
}
|
|
|
|
// expected-error @+1 {{expected a macro identifier for a pound literal expression}}
|
|
_ = #()
|
|
|
|
do {
|
|
_ = # // expected-error {{expected a macro identifier for a pound literal expression}}
|
|
name()
|
|
}
|
|
do {
|
|
_ = # macro() // expected-error {{extraneous whitespace between '#' and macro name is not permitted}} {{8-9=}}
|
|
}
|
|
do {
|
|
_ = #public()
|
|
}
|
|
do {
|
|
_ = # public() // expected-error {{expected a macro identifier for a pound literal expression}}
|
|
}
|