[Tracking] `swayfmt-v2` MVP

[eureka-cpu]

Tracking for the new formatter:

The design of rustfmt is to leave code functionality in tact, but also do more than just move white space. For instance,
long generic parameters can be cleaned up with a where clause addition and formatting of those parameters after it. I
think that's a really great characteristic that keeps code uniform and even teaches users the standard practices.

It uses an AST for most of the formatting, but for macros it uses tokens or otherwise leaves them untouched. Most macros aren't formatted, unless necessary like the format! macro since it takes in variables that result in a String.

rustfmt can recognize when something won't benefit from being formatted and opts that portion of the code out of the formatting process. If code doesn't fit the conditions of what would need formatting, e.g. a user created diagram, then it will
just leave it alone.

Please feel free to hop in and take on some of this if it interests you:

• husk of the formatter, config settings & swayfmt.toml Added foundation for sway-fmt v2 #1425 Adds forc-fmt-v2 plugin #1803 @eureka-cpu
• imports Adds ItemUse to sway-fmt-v2 #2295 @eureka-cpu
• literals @eureka-cpu
• whitespace sway-fmt-v2 should be able to handle indentations correctly. #1888 Adds associated functions for NewlineStyle #1894 Adds associated functions for handling of indentation #1911 @eureka-cpu
• expressions Add expr formatting to sway-fmt-v2 #2338 @eureka-cpu
• collections @eureka-cpu
• user defined @kayagokalp
• items
  • abi Add abi handling to sway-fmt-v2 #2043 Add abi handling to sway-fmt-v2 #2044 @eureka-cpu
  • const sway-fmt-v2 should be able to format consts #2005 @kayagokalp
  • enum swayfmt v2 should be able to format enums #1873 @kayagokalp
  • fn Adds ItemFn formatting to sway-fmt-v2 #2173 @eureka-cpu
  • impl Adds impl formatting to sfv2 #2403 @eureka-cpu
  • storage Add storage formatting to sway-fmt-v2 #2069 @kayagokalp
  • struct sway-fmt-v2 should be able to format structs #2053 @kayagokalp
  • trait Adds ItemTrait to sway-fmt-v2 #2294 @eureka-cpu
  • use Adds ItemUse to sway-fmt-v2 #2295 @eureka-cpu
  • comments ( blocker: sway-parse only lexes comments, and doesn't give spans #1517 ) @mitchmindtree & @kayagokalp (Add means of comment formatting to sway-fmt-v2 #2229, Inserting Comments #2311)
  • break and continue Handle break and continue in sway-fmt-v2 #2118 (pending break and continue #2112) @eureka-cpu
• attributes Add attribute handling to sway-fmt-v2 #2012 Adds attribute handling to sway-fmt-v2 #2061 @eureka-cpu
• Contract call arguments: Formatting contract call arguments #992 Add expr formatting to sway-fmt-v2 #2338 @eureka-cpu
• long conditionals Adds formatting for long conditional statements #2597 @eureka-cpu

swayfmt's goal is to be somewhat transparent. It should format Sway code to our standards, and if the user so decides it, they can add a swayfmt.toml to their root dir and it will assume only the changes present, and leave the rest to default.

Once completed add to CI documentor: #1806

[mitchmindtree]

Excited for this work @eureka-cpu !

I'll just add that we should really avoid emphasizing that swayfmt.toml exists at all until it gets pulled out of us.

I think it will be useful for development of the formatter (e.g. trying different combinations of configuration while we bikeshed over "the way" to do things), but we should avoid having users use or depend on swayfmt.toml at all until we're really sure we want to support the can of worms that is custom code formatting, especally when we likely want to encourage uniformity in styling across all sway projects.

This was discussed briefly in #605.

[eureka-cpu]

Excited for this work @eureka-cpu !

I'll just add that we should really avoid emphasizing that swayfmt.toml exists at all until it gets pulled out of us.

I think it will be useful for development of the formatter (e.g. trying different combinations of configuration while we bikeshed over "the way" to do things), but we should avoid having users use or depend on swayfmt.toml at all until we're really sure we want to support the can of worms that is custom code formatting, especally when we likely want to encourage uniformity in styling across all sway projects.

This was discussed briefly in #605.

Absolutely agree, currently what is on the branch is exactly in this vein ! The toml doesn't get created automatically, but you can optionally include one and it will replace values if they exist.

[kayagokalp]

I started to work on handling enums (#1873).