vet: replace automatic vfmt fixes with v vet -fix

[Gladear]

Currently, vfmt does some automatic changes like if 1 in [1] => if 1 == 1 - after some quick research, it looks like it is the only one at the time.
I think this should be moved out of vfmt and added to a new vvet flag : -fix.

Why ?

vfmt will eventually be expected to be run at each file save or so.
As proposed by @medvednikov on discord, vfmt could automatically change the signature of a function if it has too many parameters. Having it change the source code that much is really bothering during development.
On a typical workflow, I expected vvet to be run mainly before a commit, and I think this is the right time to fix this things, especially if it is done automatically.

Side-note

I personally think that errors that are automatically solved by using vfmt should not be checked in vvet:

• Looks like you are using spaces for indentation
• Looks like you have trailing whitespace
• Looks like you are adding a space before/after (
• Use var == value instead of var in [value] (it is currently listed as a vfmt fix, but as written above, should be removed imo)

[serkonda7]

Hmm, that's a hard one.
How does go's vet work? (I never used go)

Your point that automatically performing such big changes may be an interruption while development is understandable but heavily depends on the user workflow.
Most of the time I use PRs to propose changes (to personal projects too). I implement all functionality first and after that make a commit where I format everything. CI has just to be green before merge.

Also most of the vfmt-related vet errors are to ensure vfmt works fine.
For example the trailing whitespace error was added by me to find cases where vfmt is still buggy (and I found some).
We might be able to remove them in the future when everything is more stable but definitely not yet.

[Gladear]

Go's vet doesn't have a -fix option, but it's fmt doesn't fix things automatically either. It has a -r flag to explicitly tell which changes to make (see go fmt your code).

I understand your point that it depends on the user workflow. This is the way I work with V too. However, for example, when I do web development I use VSCode and enable the "format on save" option, and I think that it's something pretty common, it cannot not be considered.

Indeed, this checks can be kept for now then 🙂

[dumblob]

Maybe just keep things as they are now and instead just introduce a new flag -dryrun for vfmt which would turn off automated fixing/rewriting of the code and instead behave as Go's vet - namely would produce an overview (e.g. a diff) of what everything would be overwritten and with what.

[JalonSolov]

Maybe just keep things as they are now and instead just introduce a new flag -dryrun for vfmt which would turn off automated fixing/rewriting of the code and instead behave as Go's vet - namely would produce an overview (e.g. a diff) of what everything would be overwritten and with what.

vfmt has these options now:

Options:
  -c      Check if a file is already formatted. If not, print the filepath and exit with code 2.
          Compared to -verify it is quicker but has a small trade-off in precision.

  -diff   Display the differences between the formatted source(s) and the original source(s).
          This will attempt to find a working `diff` command automatically unless you
          specify one with the VDIFF_TOOL environment variable.

  -l      List files whose formatting differs from vfmt.

  -w      Write result to (source) file(s) instead of to stdout.

  -debug  Print the kinds of encountered AST statements/expressions on stderr.

  -verify Make sure the provided file is already formatted. Useful for checking code contributions
          in CI for example.

So your suggestions are already covered. vfmt has never overwritten files by default.

[dumblob]

@JalonSolov oh, sorry for the fuss then and thanks for clarification!