Add automatic colons or paranthesis to nodes when needed

[natikgadzhi]

This pull request adds a convenience init to EnumCaseParameterSyntax so that when you're initializing it with a firstName, it adds colon automatically.

It's the first step in #1984.

Changes

• SwiftSyntax already had a Convenience.swift, so I'm adding an extension there for now. The file is small and readable.
• I've added a unit test to SwiftSyntaxTest/SyntaxTest.swift, however as we progress in Add initializer to LabeledExprSyntax that automatically adds a colon if the label exists #1984, I'll perhaps extract them into a ConvenienceInitTests.swift.

How to review this

• I love tinkering with this, but I do feel like Alice in Wonderland. @ahoppen, did I capture your idea well, does this approach seem right?
• I've used let firstName: TokenSyntax? = firstName to trick Swift into using the right overload with an optional firstName so that the underlying generated init will be called, instead of copying it over.
• While this PR might be self-sufficient, we should probably add the rest of the todos to this as well?

TODO

Copying over from the issue:
And the same strategy can also be applied

• Other nodes that have an optional colon
• ClosureCaptureSyntax.equal
• Automatically add parentheses for the following nodes if arguments are present:
  • AttributeSyntax
  • MacroExpansionDeclSyntax
  • ClosureCaptureModifierSyntax
  • FunctionCallExprSyntax
  • FreestandingMacroExpansionSyntax

[Matejkob]

Great work on this! I took the liberty of adding a few questions and suggestions—I hope that's alright with you.

I saw in the description that you're still considering whether this will be the final PR or if additional initializers are coming. If you're leaning towards making this the final one, don't forget to run swift-format after your latest changes.

[natikgadzhi]

@Matejkob HUGE thank you for the review!

• Committed your suggestions
• Formatted with swift-format from brew.
• I think swift-format@main is broken, filing an issue and will do some yak shaving tomorrow.

Formatting aside, I will try and work on a few more items on the list above. I'll try to keep this PR small — if you'd prefer to merge this work in small chunks, I would love that as well.

[ahoppen]

• I think swift-format@main is broken, filing an issue and will do some yak shaving tomorrow.

Which error are you seeing? Running ./format.py should work.

[ahoppen]

Thank you. That looks very good to me. Just some minor comments. And thanks for the review @Matejkob.

[ahoppen]

Could you order these extensions alphabetically and add the following section at the end of the file, similar to what we have in other parts of the codebase.

//==========================================================================//
// IMPORTANT: If you are tempted to add an extension here, please insert    //
// it in alphabetical order above                                           //
//==========================================================================//

[natikgadzhi]

I think that writing a script that does this automatically for an arbitrary file would be a nice exercise and an example of how to use SwiftSyntax!

How would you feel about having an additional script that ./format.py would invoke? It could live as an executable target in swift-format as well, perhaps?

Or.. maybe that could be a part of swift-format that would only trigger on files with paths matching a setting? I.e.

{
  // ...
  "rules" : {
    "AllPublicDeclarationsHaveDocumentation" : false,
    "AlwaysUseLowerCamelCase" : true,
    
    // What if a rule would support not only a Boolean value, but an array of paths for which the value is true (or different from a default value)
    "AlphabetizeDeclarations": [ "Sources/SwiftSyntax/generated/Convenience.swift", "**/Convenience.swift"]
    // ...
  },
  // ... 
}

I could start with a little experiment as an example to learn to use SwiftSyntax, and if I can get a prototype, I could write a proposal on Swift Forums to make the settings support path arrays?

[Matejkob]

We discussed a similar idea here. At the time, we concluded that it wouldn't be a trivial task, so the subject was put on the back burner. However, the fact that the idea has resurfaced suggests there might be a real need for such a tool, and it could be beneficial to revisit the discussion.

How about we move this discussion to a separate issue? @natikgadzhi, would you like to do the honors and open one? ☺️

[ahoppen]

If you have an idea of how to implement it, I’d be happy to take it. But as I mentioned in the other discussion, I think it’s far from a trivial task, if not even (nearly) impossible.

And so far, we have been good with these comments so at least as far as I’m concerned there’s no immediate need for action.

[natikgadzhi]

Which error are you seeing? Running ./format.py should work.

I cooked SwiftPM wrong, and it couldn't reset Package.resolved, so it tried to build a fresh swift-format with older swift-syntax. Fixed now.

@Matejkob @ahoppen thank you both for reviewing, and for your feedback! I'm learning the pieces, and it starts to make more sense with every hour 🙃 I worked through the feedback and suggestions.

Since we're not squashing commits, I've amended the original one, so it looks clean in the repo history. I will add the next items on the list as separate commits.

I have a suggestion: @ahoppen, @Matejkob, how do you feel about splitting the work into three pull requests:

1. This one, that will include the other nodes that have an optional colon (um, I will search through the codebase and try to actually use my brain to come up with a list, but may need help).
2. Another small pull request that will add an init for ClosureCaptureSyntax that adds equal token. It should be small and easy.
3. The third pull request that will include parentheses for a bunch of nodes.

That way, I can make progress on them and ship them one by one faster than holding a bigger PR. Hopefully, it will be easier to review as well.

[ahoppen]

Nice. Thanks a lot. Do you also want to cover the other cases mentioned in the issue in follow-up PRs?

[ahoppen]

@swift-ci Please test

[ahoppen]

I have a suggestion: @ahoppen, @Matejkob, how do you feel about splitting the work into three pull requests:

1. This one, that will include the other nodes that have an optional colon (um, I will search through the codebase and try to actually use my brain to come up with a list, but may need help).
2. Another small pull request that will add an init for ClosureCaptureSyntax that adds equal token. It should be small and easy.
3. The third pull request that will include parentheses for a bunch of nodes.

That way, I can make progress on them and ship them one by one faster than holding a bigger PR. Hopefully, it will be easier to review as well.

I’m also happy to merge this one as-is as a proof of concept and then make any similar changes to other nodes in follow-up PRs. But you can also keep amending this PR, whatever you prefer.

[ahoppen]

@swift-ci Please test Windows

[natikgadzhi]

Nice. Thanks a lot. Do you also want to cover the other cases mentioned in the issue in follow-up PRs?

Yep, makes sense — happy to work on the rest of it.

[ahoppen]

Great. Thanks