cmd/vet: reevaluate `printf` check

[hyangah]

Recent work on #30436 improved the accuracy of the printf check greatly, and it started to uncover style issues previously undetected. For example, it detected problems like #49322, fmt.Println arg list ends with redundant new line.

Even though I agree that this is a useful information in general, I want us to think if this type of check is severe enough to justify breaking existing tests when users upgrade go to 1.18.

From @dmitshur's comment #49322 (comment)

It looks like it was added in the "initial commit" for vet in 2010, CL 3522041. Back then, it worked on *ast.BasicLit only. It's possible #30436 is a bigger improvement for other print checks like "possible formatting directive", and maybe it scales less well for the newline check.

Unlike in 2010, now vet is part of go test. Improved accuracy is great, but it looks to me some of the checks included in the initial commit may be more suitable for linters or gopls.

[thanm]

@matloob

[rsc]

I believe we should include it in the beta and see.
Improved precision in vet checks only breaks 'go test', not 'go build', which is exactly how it was designed to work.

[timothy-king]

IMO here are the 3 relevant cases of fmt.Println arg list ends with redundant new line to consider arising from #49322 :

1. fmt.Println("<loremipsum>\n")
2. const x = "<loremipsum>\n"; fmt.Println(x)
3. const p = "ipsum>\n"; fmt.Println("<lorem"+p)

[edited: the examples which previously used variables. I was wrong that these were involved.]

Thanks to @dmitshur's detective work it is clear case 1 is as old as govet. 2 should also have previously reported. #49322 was caused by changing 3 to being reported.

Going through vet's inclusion criteria. IIUC the reason for flagging any of these is that ending with "\n" in a "ln" function is considered to be a correctness problem as this is likely not what the programmer intended to output. So correctness box ticked. As yesterday indicates the Frequency box is clearly ticked. So we are really going to be debating vet's Precision criteria. Is each case getting the false positive to false negative ratio right for the programmer's intention of including the extra "\n" within Printlns?

Given the age of cases 1 and 2, those are probably are getting it right. (Right?) Evidence for case 3 would be helpful.

I am also inclined to wait and see in the beta.

[rsc]

Can you please clarify what has changed in Go 1.18?

It seems like case (1) should have been reported before. Why was it not?

Cases (2) and (3) seem like maybe an overreach:
were we doing anything involving variable assignment propagation before Go 1.18?

What about fmt.Println("<lorem" +"ipsum>\n")?
My undersatnding was that this was the case we were trying to fix, not (2) or (3).

[timothy-king]

@rsc My examples were bad. We are still not going through variables. Just "const x =". I've edited them. The only case I believe has changed in 1.18 was case 3.

[rsc]

It sounds like you are confirming that the only thing that changed in vet is handling of +'ed string constants.
I believe we should ship that. I've definitely had real Printf bugs in multiline formats in cmd/go.
Generally speaking, it is OK to add new checks to vet even though they break 'go test'.
(If we couldn't, we'd never be able to add a new check to vet ever again!)

[dmitshur]

I tested the vet change on all golang.org/x repos and it found issues in x/tools and x/exp, the rest were clean:

# golang.org/x/tools/cmd/cover
cmd/cover/cover.go:45:2: fmt.Fprintln arg list ends with redundant newline
# golang.org/x/tools/cmd/eg
cmd/eg/eg.go:62:3: fmt.Fprint call has possible formatting directive %s
# golang.org/x/tools/cmd/callgraph
cmd/callgraph/main.go:169:3: fmt.Fprintln arg list ends with redundant newline
# golang.org/x/tools/cmd/gomvpkg
cmd/gomvpkg/main.go:86:3: fmt.Println arg list ends with redundant newline
# golang.org/x/tools/cmd/gorename
cmd/gorename/main.go:49:3: fmt.Println arg list ends with redundant newline
# golang.org/x/tools/cmd/gotype
cmd/gotype/gotype.go:170:2: fmt.Fprintln arg list ends with redundant newline
# golang.org/x/tools/cmd/guru
cmd/guru/main.go:108:2: fmt.Fprintln arg list ends with redundant newline
# golang.org/x/exp/vulndb/govulncheck
govulncheck/main.go:84:24: fmt.Fprintln arg list ends with redundant newline
govulncheck/main.go:88:3: fmt.Fprintln arg list ends with redundant newline

(Source: https://storage.googleapis.com/go-build-log/624eb6f7/linux-amd64_f52d45a1.log and https://storage.googleapis.com/go-build-log/624eb6f7/linux-amd64_de3063d6.log from CL 361094 slowbots.)

Looking through the findings, they're almost all instances of CLI commands that print a usage string that happens to end with a newline, and rely on fmt.Fprintln to add a second newline. (Like cmd/cover and cmd/trace from #49322.)

The one "fmt.Fprint call has possible formatting directive %s" finding from x/tools/cmd/eg happens because its -help output implementation uses fmt.Fprint(os.Stderr, eg.Help) to print a help string, and that string is a constant that contains "%s":

const Help = `
This tool implements example-based refactoring of expressions.

[...]

The expression statement form is useful when the expression has no
result, for example:

 	func before(msg string) { log.Fatalf("%s", msg) }
 	func after(msg string)  { log.Fatal(msg) }

[...]
`

If we vendor the latest x/tools into gotip now so this is included in beta 1, it'll create red rows for x/tools and x/exp on build.golang.org, unless they're updated first. Please let me know how you'd like to proceed after considering this new information.