Note that this can lead to false positives when the os.Exit call is in a helper function, possibly in another package.

Though of course that can be greatly reduced by checking that m.Run is called directly in TestMain and whether its return value is discarded or not.

Do we need to check if the method is in TestMain?

I'm creating a CL which only checks that the return value is used. This will detect most common issues (but not fmt.Println(m.Run())), and it can be reused for other methods, by using the syntax (type).Method, for example:

go tool vet -unusedmethods='(database/sql.Tx).Commit,(*testing.M).Run'

I skimmed parts of stdlib but didn't find any obvious other candidates as serious as (*testing.M).Run

* before type names are ignored when matching methods

CL https://golang.org/cl/37968 mentions this issue.

The unusedresults module in vet is not well designed. I'd prefer to see a redesign that generalizes better, rather than adding special features for every function we can think of that needs its results used.

@robpike OK, I'm not sure what you're after. Just to play around, I added interface support and moved everything to a single argument, but I do not know types package, so I guess there are issues with the code, besides requiring cleanup.

errors.New,fmt.Errorf,...,sort.Reverse,(testing.M).Run,(error).Error,(fmt.Stringer).String

Are there any other classes of unused results you think it should catch?

Since #34129 is an accepted proposal, I believe this can be closed.

cc @rsc @robpike @ianlancetaylor

Thanks.