Skip to content

Improvements to MacroSystemTests #2113

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 2 commits into from
Aug 30, 2023

Conversation

ahoppen
Copy link
Member

@ahoppen ahoppen commented Aug 29, 2023

  • Refactor MacroSystemTests to make most macro definitions local to their test case: Most of the macro definitions were only used in a single test case. Achieve a higher locality of functionality by moving the macro definitions inside these test cases.
  • Some general improvements to the usage of SwiftSyntax in the macros in MacroSystemTests
  • Removal of trivia handling in these macros because trivia is being added by MacroSystem now.

…ir test case

Most of the macro definitions were only used in a single test case. Achieve a higher locality of functionality by moving the macro definitions inside these test cases.
Some general improvements to the usage of SwiftSyntax in the macros in MacroSystemTests and removal of trivia handling in these macros because trivia is being added by MacroSystem now.
@ahoppen ahoppen requested review from bnbarham and DougGregor August 29, 2023 16:21
@ahoppen
Copy link
Member Author

ahoppen commented Aug 29, 2023

@swift-ci Please test

Copy link
Contributor

@Matejkob Matejkob left a comment

Choose a reason for hiding this comment

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

Great idea to move the macro definitions closer to where they're actually used!

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm wondering if it would be beneficial to split these tests into smaller files. This file already has over 1,600 lines, and with perspective on future macros (like the body macro, for instance), it's going to keep growing. I personally prefer to break code into smaller chunks—it makes it easier to read and maintain, I'm not sure yet what is the chosen aproceh there.

A reasonable approach might be to divide the tests by macro type. However, we do have a few test cases that involve multiple macros of different types simultaneously. So, I'm not quite sure how to handle that situation.

I'm mainly thinking out loud here. Let me know what you think.

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 was thinking about that as well but then just stopped after moving the macro definitions.

I think having one test file for each macro type and maybe one file that tests the integration of multiple macro types would make sense.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think having one test file for each macro type and maybe one file that tests the integration of multiple macro types would make sense.

Oh yeah, I agree

@ahoppen ahoppen merged commit 0d6a210 into swiftlang:main Aug 30, 2023
@ahoppen ahoppen deleted the ahoppen/refactor-macro-system-tests branch August 30, 2023 22:01
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