x/tools/gopls: gopls drops stderr output from GOPACKAGESDRIVER

[jmhodges]

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

go version go1.13 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

darwin/amd64

go env Output

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/jeffhodges/Library/Caches/go-build"
GOENV="/Users/jeffhodges/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/jeffhodges"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/vg/32jn4gdd1x3f_r9dwcryw4y00000gn/T/go-build262498199=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

What did you expect to see?

A way to access the stderr output emitted from the $GOPACKAGESDRIVER binary. gopls drops any stderr output the driver binary prints and doesn't seem to have a way to log it to another file.

What did you see instead?

No stderr output from the driver binary.

[stamblerre]

I think that if you want read the stderr from your go/packages driver, you will have to handle or log it through the driver. As an example, the built-in go list driver explicitly drops stderr here.

[jmhodges]

Yeah, I saw that and I was hoping we could, on -v or some such, get stderr copied over (perhaps with a prefix on each line, but not required). The file.Open to log.SetOutput chain is long and means I have to maintain a tail -f somewhere.

It’s also something I have to warn contributors who make changes to the driver code after me, too.

[jmhodges]

I'd be up for writing that patch if y'all are interested!

[stamblerre]

@matloob is probably the right person to loop in here, as I think these changes would need to be made in go/packages, not gopls.

[matloob]

I think what we'd want to do here is to maybe log the STDERR if the user specifies a debug environment variable, similar to what we do here: https://github.com/golang/tools/blob/7178990c25039b756510e51a36380458e3a96487/go/packages/golist.go#L1105

[stamblerre]

Would it be sufficient to move that check to the beginning of the function?

[matloob]

I think we'd have to move it to the code that calls the gopackagesdriver in go/packages/external.go

…

On Mon, Oct 28, 2019 at 12:41 PM Rebecca Stambler ***@***.***> wrote: Would it be sufficient to move that check to the beginning of the function? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#34649?email_source=notifications&email_token=AD5VAJINFPSCTUEN4SEAW7DQQ4I4LA5CNFSM4I4PRFYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECNROBY#issuecomment-547034887>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD5VAJNDW35AGX62GGJNJF3QQ4I4LANCNFSM4I4PRFYA> .

[gopherbot]

Change https://golang.org/cl/204201 mentions this issue: go/packages: print gopackagesdriver errors when GOPACKAGESPRINTDRIVERERRORS is set

[jmhodges]

Thank you! This will make my work much easier