sway

sway copied to clipboard

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 #1425 #1803 @eureka-cpu
• imports @eureka-cpu
• lists
• literals @eureka-cpu
• ordering
• whitespace #1888 #1894 #1911 @eureka-cpu
• expressions #2338 @eureka-cpu
• collections @eureka-cpu
• user defined @kayagokalp
• items
  • abi #2043 #2044 @eureka-cpu
  • const #2005 @kayagokalp
  • enum #1873 @kayagokalp
  • fn #2173 @eureka-cpu
  • impl #2403 @eureka-cpu
  • storage #2069 @kayagokalp
  • struct #2053 @kayagokalp
  • trait #2294 @eureka-cpu
  • use #2295 @eureka-cpu
  • comments ( blocker: #1517 ) @mitchmindtree & @kayagokalp (#2229, #2311)
  • break and continue https://github.com/FuelLabs/sway/issues/2118 (pending https://github.com/FuelLabs/sway/pull/2112)
• attributes #2012 #2061 @eureka-cpu
• Contract call arguments: https://github.com/FuelLabs/sway/issues/992

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

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 https://github.com/FuelLabs/sway/issues/605.

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.

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