cmd/vet: reject flag.Parse during func init

[rsc]

In #31859, @cespare suggested rejecting flag.Parse during func init, which is always incorrect (other packages not yet initialized may want to define flags).

We could add a special runtime hook of some kind to allow flag to see whether main.main has started, but that would be unfortunate.
There also may be lots of code in the wild that does parse flags during init and kind of works out OK, and if it's working well enough we don't want to break it unnecessarily.

A vet check, on by default during go test, seems like the perfect compromise to me.

[gbbr]

A vet check would be very helpful, if it’s accomplishable, as the current output is confusing and misleading. Example:

$ go test ./pkg/trace/api
flag provided but not defined: -test.testlogfile
Usage of /var/folders/02/23s7r95n6t1739kdh0zc3trr0000gn/T/go-build397748628/b001/api.test:
  ...

I'm honestly a bit shocked that such a change went through. This (IMHO) is worse than the original problem being fixed.

[jespino]

I can work on this

[gopherbot]

Change https://golang.org/cl/218757 mentions this issue: go/analysis/passes/initflagparse: add check for avoid flag.Parse at init

[Deleplace]

Reviving this issue: the suggested fix would be very useful IMO (I was going to open an identical issue)

Additionally, the documentation of flag.Parse itself could warn more explicitly about the init pitfall:

Parse parses the command-line flags from os.Args[1:]. Must be called after all flags are defined and before flags are accessed by the program.

When following this guidance, calling flag.Parse() at the end of init looks like a right thing to do, but it's not.