Skip to content

Keywords like case cannot be used, unescaped, as expression macro names #66444

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.

Sign up for GitHub

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

Jump to bottom
Open
stephencelis opened this issue Jun 8, 2023 · 3 comments
Open

Keywords like case cannot be used, unescaped, as expression macro names #66444

stephencelis opened this issue Jun 8, 2023 · 3 comments
Labels
backticked identifiers Feature → identifiers: Backticked identifiers. Allows using reserved words as identifiers bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler itself expressions Feature: expressions identifiers Feature: Identifiers macro expansions Feature → expressions: Macro expansion expressions parser Area → compiler: The legacy C++ parser swift 5.9 unexpected error Bug: Unexpected error

Comments

@stephencelis
Copy link
Contributor

Description

I was hoping keywords like case could be used as expression macro names in an unescaped manner, like static functions and methods, but sadly that doesn't seem to be the case.

Steps to reproduce

extension Int {
  static let `case` = 1
}

let _: Int = .case   // ✅

@freestanding(expression)
public macro `case`(Int) -> Int = …

let _ = #case(42)    // 🛑
let _ = #`case`(42)  // ✅

Expected behavior

I expect #case(42) to compile OK.

Environment

  • Swift compiler version info 
    swift-driver version: 1.82.2 Apple Swift version 5.9 (swiftlang-5.9.0.114.6 clang-1500.0.27.1)
Target: arm64-apple-macosx13.0
  • Xcode version info 
    Xcode 15.0
Build version 15A5160n
@stephencelis stephencelis added bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. triage needed This issue needs more specific labels labels Jun 8, 2023
@AnthonyLatsis AnthonyLatsis added parser Area → compiler: The legacy C++ parser compiler The Swift compiler itself swift 5.9 swift macro Feature → declarations: Swift `macro` declarations expressions Feature: expressions backticked identifiers Feature → identifiers: Backticked identifiers. Allows using reserved words as identifiers identifiers Feature: Identifiers labels Jun 8, 2023
@AnthonyLatsis
Copy link
Collaborator

AnthonyLatsis commented Jun 8, 2023 •
edited
Loading

cc @ahoppen

In case this also applies to the new parser.

@ahoppen
Copy link
Member

ahoppen commented Jun 8, 2023

The new parser has the same issue

swift-parser-cli print-diags -s '#case'
=== stdin:1 ===
1 │ #case
  │  ╰─ error: keyword 'case' cannot be used as an identifier here

@ahoppen
Copy link
Member

ahoppen commented Jun 8, 2023

Tracked in Apple’s issue tracker as rdar://110472060.

@AnthonyLatsis AnthonyLatsis added macro expansions Feature → expressions: Macro expansion expressions unexpected error Bug: Unexpected error and removed swift macro Feature → declarations: Swift `macro` declarations triage needed This issue needs more specific labels labels Jun 8, 2023
ahoppen added a commit to ahoppen/swift-syntax that referenced this issue Jun 14, 2023
@ahoppen
Allow keywords after # in freestanding macro expansions
1d6f6cf 
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 `@`.

swiftlang/swift#66444
rdar://110472060
ahoppen added a commit to ahoppen/swift-syntax that referenced this issue Jun 14, 2023
@ahoppen
Allow keywords after # in freestanding macro expansions
e54d492 
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 `@`.

swiftlang/swift#66444
rdar://110472060
@ahoppen ahoppen mentioned this issue Jun 14, 2023
Merged
ahoppen added a commit to ahoppen/swift-syntax that referenced this issue Jun 14, 2023
@ahoppen
Allow keywords after # in freestanding macro expansions
b7b047f 
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 `@`.

swiftlang/swift#66444
rdar://110472060
ahoppen added a commit to ahoppen/swift that referenced this issue Jun 14, 2023
@ahoppen
[Macros] Allow keywords after # in freestanding macro expansions
4a48221 
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 `@`.

swiftlang#66444
rdar://110472060
@ahoppen ahoppen mentioned this issue Jun 14, 2023
Merged
ahoppen added a commit to ahoppen/swift that referenced this issue Jun 14, 2023
@ahoppen
[Macros] Allow keywords after # in freestanding macro expansions
afb7702 
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 `@`.

swiftlang#66444
rdar://110472060
ahoppen added a commit to ahoppen/swift that referenced this issue Jun 15, 2023
@ahoppen
[Macros] Allow keywords after # in freestanding macro expansions
fbbbd0d 
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 `@`.

swiftlang#66444
rdar://110472060
ahoppen added a commit to ahoppen/swift-syntax that referenced this issue Jun 16, 2023
@ahoppen
Allow keywords after # in freestanding macro expansions
152ad76 
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 `@`.

swiftlang/swift#66444
rdar://110472060
@ahoppen ahoppen mentioned this issue Jun 16, 2023
Merged
ahoppen added a commit to ahoppen/swift that referenced this issue Jun 16, 2023
@ahoppen
[Macros] Allow keywords after # in freestanding macro expansions
213465e 
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 `@`.

swiftlang#66444
rdar://110472060
@ahoppen ahoppen mentioned this issue Jun 16, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
backticked identifiers Feature → identifiers: Backticked identifiers. Allows using reserved words as identifiers bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler itself expressions Feature: expressions identifiers Feature: Identifiers macro expansions Feature → expressions: Macro expansion expressions parser Area → compiler: The legacy C++ parser swift 5.9 unexpected error Bug: Unexpected error
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@stephencelis @ahoppen @AnthonyLatsis