x/tools/gopls: stderr printout in init() from asmdecl analyser

[leitzler]

What version of Go are you using (go version)?

$ go version
go version devel go1.19-5ccd8e5133 Mon Mar 14 21:23:36 2022 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
N/A

What did you do?

Run gopls

What did you expect to see?

No printouts to stderr.

What did you see instead?

A printout about unknown architecture from the init() func in asmdecl analyser introduced via https://go-review.googlesource.com/c/tools/+/356089.

This causes problems for govim integration tests as they include explicit checks that there are no stderr printouts.

$ gopls version
2022/05/02 07:46:20 unknown architecture loong64
golang.org/x/tools/gopls master
    golang.org/x/tools/gopls@v0.0.0-20220429180640-aaffface24dc h1:6KDUj6aD2FUVfGHl0PWu/cOrY/09l/ReO5wT7CQcIW8=

[leitzler]

//cc @findleyr

[findleyr]

I believe this should have been fixed upstream in go/types by https://go.dev/cl/401576. Can you update your Go build to avoid the problem?

[leitzler]

Updating and rebuilding does in fact help, thanks!

In our CI we run against Go 1.17 & Go 1.18 so it won't really help us for older versions. I imagine that anything that imports asmdecl currently have the printout, right? (if it is built with a released Go version that is).

Would it be possible to guard it with a 1.19 build tag as workaround? I'm happy to mail a CL for it.

[findleyr]

@leitzler yes you're right that we should guard the new arch in the asmdecl analyzer with a build tag. If you don't mind mailing a CL, that would be great! Please send to me and @XiaodongLoong

[findleyr]

@leitzler just let us know if you don't think you'll be getting to this. I'd like to fix it before the v0.8.4 release next week. Absolutely no worries if you'd rather we take care of it.

[gopherbot]

Change https://go.dev/cl/403874 mentions this issue: go/analysis/passes/asmdecl: add build tag for loong64

[XiaodongLoong]

CC @golang/loong64