Skip to content

[Macros] Introduce SwiftSyntaxMacroExpansion module #1654

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

Merged
merged 1 commit into from
May 12, 2023

Conversation

rintaro
Copy link
Member

@rintaro rintaro commented May 12, 2023

This module is a unified macro expansion logic shared between 'swift' ASTGen and SwiftCompilerPluginMessageHandling

@rintaro rintaro requested a review from ahoppen as a code owner May 12, 2023 02:57
@rintaro
Copy link
Member Author

rintaro commented May 12, 2023

@swift-ci Please test

This module is a unified macro expansion logic shared between 'swift'
ASTGen and SwiftCompilerPluginMessageHandling
@rintaro rintaro force-pushed the macro-expansion-module branch from 76aa581 to c57b410 Compare May 12, 2023 06:31
@rintaro
Copy link
Member Author

rintaro commented May 12, 2023

@swift-ci Please test

@rintaro
Copy link
Member Author

rintaro commented May 12, 2023

swiftlang/swift#65882
@swift-ci Please test

@rintaro rintaro merged commit cde664b into swiftlang:main May 12, 2023
Comment on lines +182 to +187
.target(
name: "SwiftSyntaxMacroExpansion",
dependencies: ["SwiftSyntax", "SwiftSyntaxMacros"],
exclude: ["CMakeLists.txt"]
),

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is a new target, could you add a new MARK section for it? Each MARK section only contains the target + its test target right now

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, I didn't realize that, thank you, will do.

declarationNode: DeclSyntax,
parentDeclNode: DeclSyntax?,
in context: Context
) -> [String]? {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it maybe be cleaner to make this method throw instead of returning an optional? I think requiring callers to add the error message to the context’s diagnostics isn’t too much to ask.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's no reason not to catch exceptions, turn it to a diagnostic and emit it to the context in this function. The whole point of this PR is to minimize the duplicated logic. Why do you think making it throws is cleaner?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I just have a disliking of making nil indicate the error case because it doesn’t allow the client to check what went wrong. Since this is public anyone could call it to try expanding a macro node and for their use case, it might be useful to know what went wrong, even though for our use cases it doesn’t matter.

That being said, I think I’m fine with the current approach if we add a comment saying that upon failure (aka. if this returns nil) a diagnostic is guaranteed to be added to context.

}
}

/// Expand `@attached(XXX)` macros.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to also document all the parameters.

let parentDeclGroup = parentDeclNode?.asProtocol(DeclGroupSyntax.self)
else {
// Compiler error: 'parentDecl' is mandatory for MemberAttributeMacro.
throw MacroExpansionError(description: "parent decl group is nil")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason why you went to string-based error messages instead of enum cases. I personally prefer enums cases because it doesn’t bury the message somewhere in the source code and enum’s you can actually check programmatically if you want.

rintaro added a commit to rintaro/swift-syntax that referenced this pull request May 16, 2023
rintaro added a commit to rintaro/swift-syntax that referenced this pull request May 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants