I agree that the change to run vet always changes what errors one sees, and after all the work put into getting excellent errors from the compiler, it's a shame to go back to the less precise ones from go/parser.

But: vet is running in parallel with the compiler, so I think it makes sense to hold off printing errors from vet until the compiler has completed. If the compile fails, drop the noise from vet. That way we only see vet errors if something actually builds.

That makes sense. That's the sort of thing I was suggesting as an alternative to having to improve go/parser's errors.

I'd like to see the new syntax package taking the place of go/parser, eventually. Then all tools (including the compiler) will use the same front-end code, with identical behavior and errors. But I don't want to rush this process because once package syntax is exposed (not internal) we cannot change its API anymore. Also, all other go/* packages would have to be adjusted which - while not hard - a time-consuming and error-prone process.

But it should be fairly straight-forward to port back this specific error message if need be But @r's suggestion is a better one and solves the more general problem.

Great - I'll give Rob's fix a try. Thank you both for your input.

@griesemer after repurposing this issue to be about the go command, do you want to open another issue about improving go/parser's error?

Actually, I was wrong - my particular case had nothing to do with vet. My problem was coming from go test using go/parser directly in loadTestFuncs. Skipping this error is a bit tricky, since this happens much earlier than the build action. I'm no longer sure that a change in test is the right fix.

@mvdan I'll assign this to me and will look at the parser's error message. But this is not urgent.

Indeed not urgent - also fine by me if it's not fixed at all, as long as go/parser is replaced eventually.

It occurred to me that this issue is likely relevant to @findleyr's recent work :)

Yes, @findleyr is actively working on the parser and I suspect sooner or later the go/parser will produce much better error messages.

It looks like the error has changed a bit, but is still inferior to the compiler's.

The fix here is still to improve go/parser.

(@matloob: moved to backlog)