profile
viewpoint
Bryan C. Mills bcmills Google Pittsburgh, PA

google/go-cmp 1526

Package for comparing Go values in tests

bcmills/k8s-mods 5

go.mod files specifying consistent versions of k8s.io dependencies

bcmills/go-experience-reports 1

Experience reports for the Go programming languange (http://golang.org/wiki/ExperienceReports)

bcmills/goissues 1

utility to export golang/go issues to CSV

bcmills/cespare-misc 0

Experiments and bad ideas

bcmills/extra-keyboards-for-chrome-os 0

Extra keyboard layouts and input methods for Chrome OS

bcmills/go-misc 0

Miscellaneous Go hacks

bcmills/issue29268 0

example repository for golang.org/issue/29268

bcmills/scaleway-cli 0

:computer: Manage BareMetal Servers from Command Line (as easily as with Docker)

bcmills/uuid61 0

example repository for github.com/gofrs/uuid/issues/61

issue commentgolang/go

x/tools/internal/lsp/regtest: TestGoTo*Definition is flaky

Possibly the same failure mode in TestDiagnosticErrorInNewFile/forwarded?

2020/02/28 00:40:12 diagnose: could not generate diagnostics for go.mod file: err: exit status 1: stderr: 2020/02/28 00:40:12 cannot determine current directory: getwd: no such file or directory

2020/02/28 00:40:18 diagnose: could not generate diagnostics for go.mod file: err: exit status 1: stderr: 2020/02/28 00:40:18 cannot determine current directory: getwd: no such file or directory

2020/02/28 00:40:25 closed a connection with error: disconnected
2020/02/28 00:40:37 closed a connection with error: disconnected
--- FAIL: TestDiagnosticErrorInNewFile (91.72s)
    --- FAIL: TestDiagnosticErrorInNewFile/forwarded (60.01s)
        diagnostics_test.go:47: waiting on (diagnostic in "broken.go" at (line:2, column:12)):
            err:context deadline exceeded
            diagnostics:
panic: Shutdown: context deadline exceeded [recovered]
	panic: Shutdown: context deadline exceeded
bcmills

comment created time in 8 hours

issue commentgolang/go

Not able to get private go module while having port number in url

We no longer use the Go issue tracker for questions about usage: our experiment to allow questions on the issue tracker did not have the outcome we desired.

There are many other methods to get help if you're still looking for answers:

Thanks

yhjhoo

comment created time in 8 hours

issue closedgolang/go

Not able to get private go module while having port number in url

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

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

<pre> go1.14 windows/amd64

</pre>

Does this issue reproduce with the latest release?

Yes

</pre></details>

What did you do?

$ go get -u bitbucket.mycompany.com:8443/test/go-lib

What did you expect to see?

download the go-lib library

What did you see instead?

invalid char ':'

closed time in 8 hours

yhjhoo

issue commentgolang/go

Not able to get private go module while having port number in url

go get accepts a package list, not a list of URLs. Package paths do not contain port numbers.

(See https://tip.golang.org/cmd/go/#hdr-Remote_import_paths for a description of the protocol that the go command uses to resolve package paths to repo URLs.)

yhjhoo

comment created time in 8 hours

issue commentgolang/go

proposal: cmd/go: deprecate -insecure on go get

I think we probably need to keep -insecure around long enough for folks to start using GOINSECURE (and report and work out any deficiencies with it), but I'd be happy to remove -insecure after that point — say, in Go 1.16 (when every still-supported version of the Go toolchain will have GOINSECURE).

witchard

comment created time in 8 hours

issue commentgolang/go

proposal: cmd/go: deprecate -insecure on go get

CC @jayconrod @matloob @FiloSottile @katiehockman

witchard

comment created time in 8 hours

issue commentgolang/go

cmd/go: build ./... tries to traverse the entire filesystem when outside a module but with a potential config file to convert to go.mod

It also reproduces with go1.13 but not with go1.12.

I'm also seeing a very slow go build ./... with go1.12 when in GOPATH mode. So I suspect that what's happening here is that somehow the module-mode go build is trying to resolve ./... before it realizes that it isn't even in a module.

perillo

comment created time in 9 hours

issue commentgolang/go

cmd/go: build ./... tries to traverse the entire filesystem when outside a module but with a potential config file to convert to go.mod

Heh, that's odd. I can reproduce it as well. Thanks for the report!

perillo

comment created time in 9 hours

issue closedgolang/go

go.mod seems to have a problem with changing length of version strings

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

<pre> $ go version go version go1.14 windows/amd64 </pre>

Does this issue reproduce with the latest release?

yes

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

<details><summary><code>go env</code> Output</summary><br><pre> $ go env set GO111MODULE= set GOARCH=amd64 set GOBIN= set GOCACHE=C:\Users\admin\AppData\Local\go-build set GOENV=C:\Users\admin\AppData\Roaming\go\env set GOEXE=.exe set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOINSECURE= set GONOPROXY= set GONOSUMDB= set GOOS=windows set GOPATH=i:\go set GOPRIVATE= set GOPROXY=https://proxy.golang.org,direct set GOROOT=C:\Go set GOSUMDB=sum.golang.org set GOTMPDIR= set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set AR=ar set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD=i:\git\apache_download\go.mod set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\admin\AppData\Local\Temp\go-build612841182=/tmp/go-build -gno-record-gcc-switches </pre></details>

What did you do?

I followed the module docs.

  • add import "github.com/anaskhan96/soup"
  • go test
  • this finds and adds v1.1.1 to go.mod
  • because v1.2 is available (https://github.com/anaskhan96/soup/releases/tag/v1.2) I tried to change it and got <pre>go.mod:6: no matching versions for query "v1.2"</pre>
  • on a hunch after some tries I forked it and "released" a v1.2.0
  • go get did find my v1.2.0

What did you expect to see?

go downloading v1.2

What did you see instead?

go downloading v1.1.1 and refusing v1.2

closed time in 9 hours

d-schmidt

issue commentgolang/go

go.mod seems to have a problem with changing length of version strings

1.2 is not a well-formed semantic version.

The go get command supports a small set of version queries beyond just canonical semantic versions, but in general it requires tags to be the character v plus a canonical, well-formed semantic version.

For more detail, see https://blog.golang.org/publishing-go-modules.

d-schmidt

comment created time in 9 hours

issue commentgolang/go

cmd/go: 'Access is denied' when renaming module cache directory

@networkimprov, 500ms of extra latency is enough as it is. 30s is unacceptably slow. We'll figure out some alternative.

kiwionly

comment created time in 16 hours

issue commentgolang/go

runtime: "found bad pointer in Go heap" on solaris-amd64-oraclerel builder

@networkimprov, I don't think there is enough evidence on #37506 to suggest a link. (For all we know, that one really could just be incorrect use of unsafe or cgo.)

bcmills

comment created time in 17 hours

issue commentgolang/go

cmd/go: build -o dir ./... should build (and discard) non main packages

Thinking about this some more. In most repos that mix main packages and other packages, I would expect the vast majority of packages to be imported by the main ones. So, while it's true that go build -o dir ./... would possibly become slower, I don't think it would be much slower in practice.

And, for the few cases that matter, users can always select only the main packages explicitly, using something like go build -o dir $(go list -f '{{if eq .Name "main"}}{{.ImportPath}}{{end}}' ./...).

I think it makes sense for the -o flag to be orthogonal to the package pattern. Right now it is not: -o changes the meaning of ./... to select only main packages.

perillo

comment created time in 19 hours

issue openedgolang/go

net/http/httptest: Close does not wait for the underlying Server's ConnState callbacks to complete

In issue #37505, the observed data race seems to be due to the http.Server embedded in an httptest.Server firing a ConnState callback after the call to the httptest.Sever's Close method has already returned.

The documentation for (*httptest.Server).Close says that it “blocks until all outstanding requests on this server have completed”, so it seems reasonable for users to assume that the corresponding ConnState callbacks on the corresponding connections will have completed by that point as well. Empirically, that does not always happen.

CC @bradfitz @rsc @tombergan

created time in 20 hours

IssuesEvent

issue openedgolang/go

x/tools/internal/lsp: test failures due to data corruption

This could be a symptom of #37269, of #36605, or of some other undiagnosed memory-corruption bug. (I note goroutines in both golang.org/x/tools/go/packages.Load and golang.org/x/tools/internal/fastwalk.Walk in the stack dump.)

020/02/26 22:48:02 no dep handle: no metadata for nosuchpkg
	package = nosuchpkg
2020/02/26 22:48:15 unable to compute error positions: no file for  in package golang.org/x/tools/internal/lsp/danglingstmt
	package = golang.org/x/tools/internal/lsp/danglingstmt
2020/02/26 22:48:15 unable to compute error positions: no file for  in package golang.org/x/tools/internal/lsp/danglingstmt
	package = golang.org/x/tools/internal/lsp/danglingstmt
2020/02/26 22:48:44 initial workspace load failed: couldn't run 'go': chdir /tmp/workdir/tmp/TestLSP_GOPATH210517143/lsp/src: no such file or directory
2020/02/26 22:48:44 initial workspace load failed: err: exit status 1: stderr: 2020/02/26 22:48:44 cannot determine current directory: getwd: no such file or directory

2020/02/26 22:49:32 no dep handle: no metadata for nosuchpkg
	package = nosuchpkg
2020/02/26 22:49:41 unable to compute error positions: no file for  in package golang.org/x/tools/internal/lsp/danglingstmt
	package = golang.org/x/tools/internal/lsp/danglingstmt
2020/02/26 22:49:41 unable to compute error positions: no file for  in package golang.org/x/tools/internal/lsp/danglingstmt
	package = golang.org/x/tools/internal/lsp/danglingstmt
2020/02/26 22:49:52 diagnose: could not generate diagnostics for go.mod file: err: exit status 1: stderr: golang.org/x/tools/internal/lsp/bad imports
	nosuchpkg: package nosuchpkg is not in GOROOT (/tmp/workdir/go/src/nosuchpkg)

2020/02/26 22:49:54 quick fixes failed: err: exit status 1: stderr: golang.org/x/tools/internal/lsp/bad imports
	nosuchpkg: package nosuchpkg is not in GOROOT (/tmp/workdir/go/src/nosuchpkg)

	file = file:///tmp/workdir/tmp/TestLSP_Modules744837051/lsp/suggestedfix/has_suggested_fix.go
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]
…
FAIL	golang.org/x/tools/internal/lsp	161.038s

CC @findleyr @stamblerre @ianthehat @matloob

created time in 20 hours

issue commentgolang/go

x/tools/internal/lsp/regtest: TestGoToStdlibDefinition is flaky

Looks like TestGoToInternalDefinition is flaky too (https://build.golang.org/log/f4005ba97ed110dada6639ae9471c52d744e9bb3):

2020/02/27 06:05:06 initial workspace load failed: err: exit status 1: stderr: go: open /tmp/workdir/tmp/go.goplstest-ws-lsprpc-546835840.254255568.mod: no such file or directory

2020/02/27 06:05:35 diagnose: could not generate diagnostics for go.mod file: err: exit status 1: stderr: 2020/02/27 06:05:35 cannot determine current directory: getwd: no such file or directory

2020/02/27 06:06:01 diagnose: could not generate diagnostics for go.mod file: err: exit status 1: stderr: 2020/02/27 06:06:01 cannot determine current directory: getwd: no such file or directory

--- FAIL: TestGoToInternalDefinition (135.43s)
2020/02/27 06:09:39 : context deadline exceeded
    --- FAIL: TestGoToInternalDefinition/forwarded (77.60s)
        definition_test.go:38: definition: context deadline exceeded
panic: Shutdown: context deadline exceeded [recovered]
	panic: Shutdown: context deadline exceeded

goroutine 9453 [running]:
testing.tRunner.func1.1(0xe3fac0, 0xc002a7a6a0)
	/tmp/workdir/go/src/testing/testing.go:941 +0x5d0
testing.tRunner.func1(0xc00aafbe60)
	/tmp/workdir/go/src/testing/testing.go:944 +0x600
panic(0xe3fac0, 0xc002a7a6a0)
	/tmp/workdir/go/src/runtime/panic.go:973 +0x396
golang.org/x/tools/internal/lsp/regtest.(*Runner).RunInMode.func1.1(0xc00b179140, 0x10990c0, 0xc00a7d9440)
	/tmp/workdir/gopath/src/golang.org/x/tools/internal/lsp/regtest/env.go:180 +0xc1
runtime.Goexit()
	/tmp/workdir/go/src/runtime/panic.go:634 +0x104
testing.(*common).FailNow(0xc00aafbe60)
	/tmp/workdir/go/src/testing/testing.go:657 +0x5b
testing.(*common).Fatal(0xc00aafbe60, 0xc0009e9bc0, 0x1, 0x1)
	/tmp/workdir/go/src/testing/testing.go:718 +0x8a
golang.org/x/tools/internal/lsp/regtest.(*Env).GoToDefinition(0xc00b179140, 0xf26c4b, 0x7, 0x5, 0xd, 0x0, 0xc005b3b0d0, 0xc005b3b300, 0xc00aaf8ff0)
	/tmp/workdir/gopath/src/golang.org/x/tools/internal/lsp/regtest/env.go:323 +0x1a2
golang.org/x/tools/internal/lsp/regtest.TestGoToInternalDefinition.func1(0x10990c0, 0xc00a7d9440, 0xc00aafbe60, 0xc00b179140)
	/tmp/workdir/gopath/src/golang.org/x/tools/internal/lsp/regtest/definition_test.go:38 +0x9e
golang.org/x/tools/internal/lsp/regtest.(*Runner).RunInMode.func1(0xc00aafbe60)
	/tmp/workdir/gopath/src/golang.org/x/tools/internal/lsp/regtest/env.go:183 +0x3bc
testing.tRunner(0xc00aafbe60, 0xc00aaf8eb0)
	/tmp/workdir/go/src/testing/testing.go:992 +0x1ec
created by testing.(*T).Run
	/tmp/workdir/go/src/testing/testing.go:1043 +0x661
FAIL	golang.org/x/tools/internal/lsp/regtest	275.474s
bcmills

comment created time in 20 hours

issue openedgolang/go

x/net/http2: data race in onSameConn test helper

https://build.golang.org/log/0d66aaa201ea31f6aa29c94ff8d6b76f67789071

==================
WARNING: DATA RACE
Read at 0x00c00015c163 by goroutine 315:
  testing.(*common).logDepth()
      /tmp/workdir/go/src/testing/testing.go:669 +0xa1
  testing.(*common).log()
      /tmp/workdir/go/src/testing/testing.go:662 +0x8f
  testing.(*common).Logf()
      /tmp/workdir/go/src/testing/testing.go:701 +0x21
  golang.org/x/net/http2.onSameConn.func2()
      /tmp/workdir/gopath/src/golang.org/x/net/http2/transport_test.go:196 +0x101
  net/http/httptest.(*Server).wrap.func1()
      /tmp/workdir/go/src/net/http/httptest/server.go:357 +0x121
  net/http.(*conn).setState()
      /tmp/workdir/go/src/net/http/server.go:1725 +0x155
  net/http.(*conn).serve.func1()
      /tmp/workdir/go/src/net/http/server.go:1777 +0xf8
  net/http.(*conn).serve()
      /tmp/workdir/go/src/net/http/server.go:1807 +0x1c10

Previous write at 0x00c00015c163 by goroutine 195:
  testing.tRunner.func1()
      /tmp/workdir/go/src/testing/testing.go:978 +0x467
  testing.tRunner()
      /tmp/workdir/go/src/testing/testing.go:996 +0x20d

Goroutine 315 (running) created at:
  net/http.(*Server).Serve()
      /tmp/workdir/go/src/net/http/server.go:2933 +0x5b6
  net/http/httptest.(*Server).goServe.func1()
      /tmp/workdir/go/src/net/http/httptest/server.go:308 +0xd3

Goroutine 195 (running) created at:
  testing.(*T).Run()
      /tmp/workdir/go/src/testing/testing.go:1043 +0x660
  testing.runTests.func1()
      /tmp/workdir/go/src/testing/testing.go:1300 +0xa6
  testing.tRunner()
      /tmp/workdir/go/src/testing/testing.go:992 +0x1eb
  testing.runTests()
      /tmp/workdir/go/src/testing/testing.go:1298 +0x57f
  testing.(*M).Run()
      /tmp/workdir/go/src/testing/testing.go:1210 +0x353
  main.main()
      _testmain.go:668 +0x223
==================
FAIL
FAIL	golang.org/x/net/http2	17.754s

The racing write is here: https://github.com/golang/go/blob/7bb33179cadf072403b2f1d8f8210c5ae414d135/src/testing/testing.go#L976-L978

That comment suggests that the bug lies in the test itself: https://github.com/golang/net/blob/0de0cce0169b09b364e001f108dc0399ea8630b3/http2/transport_test.go#L193-L198

	st := newServerTester(t, func(w http.ResponseWriter, r *http.Request) {
		io.WriteString(w, r.RemoteAddr)
	}, optOnlyServer, func(c net.Conn, st http.ConnState) {
		t.Logf("conn %v is now state %v", c.RemoteAddr(), st)
	})
	defer st.Close()

That, in turn, suggests that the serverTester is continuing to execute one of its callbacks after its Close method has already returned.

The callback is registered via the httptest.Server's Config field: https://github.com/golang/net/blob/0de0cce0169b09b364e001f108dc0399ea8630b3/http2/server_test.go#L118-L119

The (*serverTester).Close method explicitly closes its httptest.Server and its net.Conn. https://github.com/golang/net/blob/0de0cce0169b09b364e001f108dc0399ea8630b3/http2/server_test.go#L256-L259

The documentation for (*httptest.Server).Close says that it “blocks until all outstanding requests on this server have completed.” However, it does not specify whether it blocks until the corresponding connections have been closed.

I would argue that (*httptest.Server).Close should block until the outstanding connections are completely closed, including any ConnState callbacks. However, there may be a shorter-term workaround we can apply in the x/net/http2 test in the interim. (I will file a separate issue for httptest.Server.)

CC @bradfitz @rsc @tombergan

created time in 20 hours

issue commentgolang/go

cmd/go: "no go-import meta tags" when fetching from a private GitLab repo

Please follow up with GitLab about the 500's and let us know if you're still having trouble.

2at2

comment created time in 21 hours

issue commentgolang/go

cmd/go: "no go-import meta tags" when fetching from a private GitLab repo

Also, go1.13 is missing quite a few critical patches. On the 1.13 line, you'll want to use go1.13.8 instead.

2at2

comment created time in 21 hours

issue commentgolang/go

no go-import meta tags

If the server is returning status 500, there isn't really anything the go command can do about that. (Open an issue with GitLab.)

FWIW, here's what I get:

example.com$ go version
go version devel +7bb33179 Thu Feb 27 05:56:21 2020 +0000 linux/amd64

example.com$ go mod init example.com
go: creating new go.mod: module example.com

example.com$ go get gitlab.com/strebul/test_lib
go get gitlab.com/strebul/test_lib: module gitlab.com/strebul/test_lib: git ls-remote -q origin in /tmp/tmp.GIerny0Ddu/_gopath/pkg/mod/cache/vcs/fe81d9efa2646d8017d2a3c892b3f5b0f3070c2aaf4304e69e8a35ab3e5b45e8: exit status 128:
        fatal: could not read Username for 'https://gitlab.com': terminal prompts disabled
Confirm the import path was entered correctly.
If this is a private repository, see https://golang.org/doc/faq#git_https for additional information.

Note that with Go 1.14, in order to access private GitLab repos you'll probably need to put some sort of credential in your .netrc file.

2at2

comment created time in 21 hours

issue openedgolang/go

runtime: "found bad pointer in Go heap" on solaris-amd64-oraclerel builder

2020-02-26T23:27:55-12cd55c/solaris-amd64-oraclerel

##### ../doc/codewalk
runtime: pointer 0xc00033c002 to unallocated span span.base()=0xc00033c000 span.limit=0xc00033dee0 span.state=0
runtime: found in object at *(0xc000230000+0x0)
object=0xc000230000 s.base()=0xc000230000 s.limit=0xc000232000 s.spanclass=10 s.elemsize=64 s.state=mSpanInUse
 *(object+0) = 0xc00033c002 <==
 *(object+8) = 0x9
 *(object+16) = 0xc00033c00e
 *(object+24) = 0x10
 *(object+32) = 0xc00033c021
 *(object+40) = 0xb
 *(object+48) = 0xc00033c02f
 *(object+56) = 0xc
fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)

The doc/codewalk test is pretty simple (no unsafe or cgo and only a little concurrency), so I suspect this is a runtime or platform bug.

Compare #35541, #32324, #28054.

CC @mknyszek, @cherrymui @aclements

created time in a day

issue commentgolang/go

race_linux_amd64.syso now depends on glibc 2.16

CC @dvyukov @randall77 (see CL 201898 / #33309)

Roguelazer

comment created time in 2 days

issue commentgolang/go

cmd/go: build -o dir ./... should build (and discard) non main packages

Hmm... The obvious workaround is to run go build ./... && go build -o dir ./..., but that will also be suboptimally slow due to #31629.

perillo

comment created time in 2 days

issue commentgolang/go

cmd/go: build -o dir ./... should build (and discard) non main packages

But why?

Because of the other bug you observed: we are failing to detect collisions when building multiple executables with the same binary name.

perillo

comment created time in 2 days

issue commentgolang/go

memory corruption while using appending to a slice across multiple goroutines

(https://research.swtch.com/gorace is a good read if you haven't seen it already.)

bionoren

comment created time in 2 days

issue commentgolang/go

memory corruption while using appending to a slice across multiple goroutines

Have you run the program under the race detector? The Go memory model does not allow concurrent goroutines to append to the same slice.

bionoren

comment created time in 2 days

issue commentgolang/go

runtime: "fatal error: unexpected signal" 0xC0000005 on Windows for a small program with a large allocation

@networkimprov, now that 1.14 has been released I would not expect any further 1.12.x releases.

ulikunitz

comment created time in 2 days

issue commentgolang/go

proposal: cmd/go: invalidate cache entries for test runs using different timeouts

I think we should revert the special-case for the -test.timeout flag, so that different -timeout values result in fresh runs of the test. That's a simple change to make, and it's easy to adapt it to very long tests by setting GOFLAGS=-timeout=20m or similar.

(Then we can see if there are any remaining cases where the GOFLAGS approach does not suffice, and if so whether they merit the additional complexity of flag tracking and timeout comparisons for more precise cache invalidation.)

bcmills

comment created time in 2 days

issue commentgolang/go

cmd/go: GOOS=js GOARCH=wasm go build -o [non-empty parent dir] ./... fails on Windows host

Oh! The outputs for the default GOOS=windows have a .exe suffix.

That's what avoids the collision with the existing directories for non-build-tagged binaries.

Gregory-Ledray

comment created time in 2 days

issue openedstamblerre/work-stats

"422 Only the first 1000 search results are available" for GitHub issue interactions

I got this output from work-stats for a ~1yr window:

<pre> ~/src/github.com/stamblerre/work-stats$ work-stats --username=bcmills --email=bcmills@google.com --since=2019-02-01 2020/02/26 13:28:28 Loading data from log *maintner.netMutSource ... 2020/02/26 13:28:28 Downloading 3565 bytes of https://maintner.golang.org/logs/63 ... 2020/02/26 13:28:28 wrote /usr/local/google/home/bcmills/.cache/golang-maintner/0063.growing.mutlog 2020/02/26 13:28:42 Reloaded data from log *maintner.netMutSource. 2020/02/26 13:28:42 Wrote output to /tmp/work-stats048958562/golang-issues.csv. 2020/02/26 13:28:42 Wrote output to /tmp/work-stats048958562/golang-authored.csv. 2020/02/26 13:28:42 Wrote output to /tmp/work-stats048958562/golang-reviewed.csv. <b>2020/02/26 13:29:12 GET https://api.github.com/search/issues?page=11&per_page=100&q=involves%3Abcmills+updated%3A%3E%3D2019-02-01: 422 Only the first 1000 search results are available []</b> </pre>

The 1000-result error seems unfortunate. Any ideas for how to work around it?

created time in 2 days

issue commentgolang/go

proposal: cmd/go: stamp git/vcs current HEAD hash/commit hash/dirty bit in binaries

This may be a duplicate of #29814.

bradfitz

comment created time in 2 days

issue commentgolang/go

cmd/go: build -o dir ./... should build (and discard) non main packages

I think at least building the matching packages makes sense, although it would make the use-case in #14295 arbitrarily slower in some cases.

Jay, Michael: any thoughts?

perillo

comment created time in 2 days

issue commentgolang/go

cmd/go: build -o dir ./... should build (and discard) non main packages

CC @jayconrod @matloob

perillo

comment created time in 2 days

issue commentgolang/go

cmd/go: inconsistency when go build -o is a file or directory

For consistency, go build -o dir ./... should save the archive files in the build directory, when processing non main packages, using the same algorithm used for main packages.

I don't think I understand what you mean. Do you expect go build to write archive files into dir, or to build the archive files but not copy them in?

More generally (and following https://github.com/golang/go/issues/36784#issuecomment-583498323): what is the concrete problem that you're trying to address where the current behavior of the -o flag is causing trouble?

perillo

comment created time in 2 days

issue commentgolang/go

cmd/go: inconsistency when go build -o is a file or directory

This is done even if two executable happen to have the same name, without any notice.

That seems like an independent bug. File it as a separate issue?

perillo

comment created time in 2 days

issue commentgolang/go

cmd/go: inconsistency when go build -o is a file or directory

CC @jayconrod @matloob

perillo

comment created time in 2 days

push eventbcmills/work-stats

push time in 2 days

push eventbcmills/work-stats

Bryan C. Mills

commit sha 2e4ff6b4afbd79398cb2b094d7a2bf29793d9ccb

golang: reset issues.go to match upstream

view details

push time in 2 days

push eventbcmills/work-stats

Rebecca Stambler

commit sha 284da7edea8b0051ddcac695a35fcc3e6b38308c

Merge pull request #2 from bcmills/master golang: track owner IDs by project

view details

Rebecca Stambler

commit sha 47731e670f509d4d32d719156440a60f230fba19

add support for exporting as a Google spreadsheet

view details

Rebecca Stambler

commit sha f949e4395ee004b28672508d0e7d342caa3c8501

run go mod tidy

view details

Rebecca Stambler

commit sha b400f2caf637b7278f9e1fcf25fd48b3c03b9a4f

some small cleanup

view details

Rebecca Stambler

commit sha b09bfb126a6d6a5eb024ae083283bd80ed4178e8

add some additional formatting steps

view details

Rebecca Stambler

commit sha ba1a260a252922684e55d6bbb27cc44eced0b4df

don't create sheet unless successful

view details

Rebecca Stambler

commit sha 7f4d672a191e12a9da77182d98978dbd8f975565

group reviews by author, add subtotals, format sheets

view details

Rebecca Stambler

commit sha 5b074791bdda0c9fadf0228d953c9c302bbef56a

explain usage of Google Sheets API

view details

Rebecca Stambler

commit sha 45f167de73594c167e6e0609fd331104f31cf4cc

cleanup

view details

Rebecca Stambler

commit sha 89d50ff6d830944cf273a57806c5739879268cfe

some code cleanup

view details

Rebecca Stambler

commit sha ace79def5c493aa73e512fd2029a2354f04c0230

Merge branch 'master' of https://github.com/stamblerre/work-stats

view details

Rebecca Stambler

commit sha e44ebe7d7625ffb3b004b20f5f6ed7777d4d5b05

support appending to an existing Google Sheet

view details

Rebecca Stambler

commit sha 3e227ca118c7112abb7506bd60c1ef42f43eb8d0

remove global variables, clean up

view details

Rebecca Stambler

commit sha 9f108c5198b28583c28e19c6aed7eefaf3a15c9e

refactor to create a generic CL and issue type

view details

Jean de Klerk

commit sha 468f9e47506386ab3b2459b2c83eb6dd1580e9d8

do not automatically attempt to create Google Sheets output This commit cleans up a usability issue: that when you provide only your github/gerrit credentials, this program fails because it tries to create google sheets stuff (which is guaranteed to fail, since it hasn't been provided). It fixes this by setting the default value of the sheets flag to empty, which causes the program to exit before it tries to create sheets unless the user specifically sets that flag. Several examples on the README.md are therefore fixed with this. It also fixes the problem a second time by setting tokenFile and credentialsFile to default empty values, and adding a check that they actually got set by the user before attempting to spin up a google sheet. In addition to fixing the aforementioned problem (again), they are a little better user experience: users won't get cryptic "file not found credentials.json" errors and have no idea what is credentials.json. Also cleans up: - README.md 80 char limit - README.md use multi-line code snippets for wide snippets - Refactor google sheets ID parsing into its own function - Use log.Print* everywhere rather than a mix of log.Print* and fmt.Print*

view details

Rebecca Stambler

commit sha f244d452615290dec6b7ddf51348d8987f216be1

fix minor issues

view details

Rebecca Stambler

commit sha c787464e34846a51b093fc64f5b150914ff043e4

Merge pull request #5 from stamblerre/make-generic Split out generic output functions

view details

Rebecca Stambler

commit sha 152bc7d64d8c869e836518d157a1b7e9788ac43b

make subtotals conditional

view details

Rebecca Stambler

commit sha 52e8e1d8b5e151daa4b93efc7803108f566ca792

Merge pull request #4 from jadekler/cleanups do not automatically attempt to create Google Sheets output

view details

Rebecca Stambler

commit sha baa89e0df841f2d90d56c79a72f3df52fa2ef552

minor fix

view details

push time in 2 days

issue commentgolang/go

Windows: Fatal error unexpected signal 0xC0000005 for small program that runs on Linux

The [1 << 17]uint32 field is ~524 KiB. If that ends up being allocated on the stack, I could imagine that it is triggering some bug in the interaction between the runtime and the OS and causing the stack growth to appear to be a wild memory fault.

CC @randall77 @aclements @mknyszek

ulikunitz

comment created time in 2 days

issue commentgolang/go

cmd/go: GOOS=js GOARCH=wasm go build -o [non-empty parent dir] ./... fails on Windows host

Looking at your go env output, you appear to be running the go build command on a Windows host? That's probably a relevant detail.

Gregory-Ledray

comment created time in 2 days

issue commentgolang/go

cmd/go: GOOS=js GOARCH=wasm go build -o [non-empty parent dir] ./... fails

CC @jayconrod @matloob @neelance @cherrymui

Gregory-Ledray

comment created time in 2 days

issue commentgolang/go

cmd/go: mod tidy and mod vendor fighting with each other

I would probably start with go mod why -m github.com/jonboulle/clockwork and go mod why -m github.com/prometheus/client_model.

The differences between go mod tidy and go mod vendor arise through dependencies of tests of dependencies of the main module, so a minimal repro probably involves one of those.

agnivade

comment created time in 2 days

issue commentgolang/go

proposal: cmd/go: lazy module loading

are these [go version] changes documented somewhere centrally?

Not yet. That's arguably part of #30791...

bcmills

comment created time in 2 days

issue commentgolang/go

proposal: cmd/go: lazy module loading

This was the comment I had in mind when asking: …

Ah, now I remember. The untidiness there was “larger than tidy” rather than “smaller than tidy”, and I think we have basically settled on the // +build approach for that use-case.

bcmills

comment created time in 2 days

issue commentgolang/go

proposal: cmd/go: add GOMODCACHE

Running goproxy server for the duration of abuild seems overcomplicated.

Note that you can use a file:// URL as a valid GOPROXY. There is no need to run an explicit server if you already have all of the files cached.

But this is really getting off into a tangent. #35922 is probably a more relevant venue for this discussion.

mvdan

comment created time in 2 days

issue commentgolang/go

cmd/go: go build should be able to write multiple executables

@Gregory-Ledray, please open a new issue with steps to reproduce. Probably there is something special about wasm binaries that is interfering with the feature.

kardianos

comment created time in 2 days

issue commentgolang/go

internal/go115: add package

I don't mind consolidating the gates into a package, but I don't understand the benefit of string literals over constants.

Constants would not only provide clear points at which to attach documentation (such as a description of the feature or a link to a tracking issue), but also provide a clearer, centralized overview of which gated features are present and enabled.

josharian

comment created time in 2 days

issue commentgolang/go

internal/go115: add package

CC @golang/osp-team

josharian

comment created time in 2 days

issue commentgolang/go

runtime: mlock of signal stack failed: 12

What's not immediately clear though is whether just the Go compiler or all Go built apps have issues too?

The Linux kernel bug is not even Go-specific. If I understand correctly, it affects any program — even one written in C! — that uses the XMM or YMM registers and may receive signals. Go programs under 1.14 happen to be more severely affected than many other programs because they use signals internally for goroutine preemption, and that is why Go 1.14 includes the mlock workaround.

karalabe

comment created time in 2 days

issue commentgolang/go

cmd/compile: inconsistent signaling NaN behavior on mips64le

The assembly code for add0 is the same on both platforms.

Could this be due to a difference in the default kernel or libc signal behavior for floating-point exceptions? (What happens if you compile the program with -fsignaling-nans, and/or register an explicit SIGFPE handler?)

randall77

comment created time in 2 days

issue commentgolang/go

cmd/compile: inconsistent signaling NaN behavior on mips64le

According to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1011.htm:

Binary operations that have a normal operand and a signaling NaN operand shall trigger the signaling NaN and should produce that signaling NaN made quiet as a result.

but:

Whether an operation that merely returns the value of a numeric operand, changing at most its sign, triggers signaling NaNs is unspecified. Such operations include conversions that do not change precision, the unary + and - operators, and the fabs and copysign functions.

So the behavior on the rtrk builder seems to be a bug, depending on whether you consider +0 to be “an operation that merely returns the value of a numeric operand” or one that has “a normal operand and a signaling NaN operand”.

I suspect that that distinction depends in practice on the specific version and default flags of the C compiler. I'm not sure that it should have any bearing on the behavior of the Go compiler, except that I would prefer that we not language-lawyer a binary operation into a non-operation.

randall77

comment created time in 2 days

issue commentgolang/go

testing: when using a custom TestMain, m.Run does not return if one of the tests it runs panics

I don't think we do need to “figure out how to do more later”. We should structure our own code to propagate panics from non-main goroutines back to the main goroutine, and encourage users to do the same.

Especially for non-Parallel tests, the mapping of test functions to goroutines should be an implementation detail internal to the testing package. It should not matter whether the Test function runs on the same goroutine as TestMain or an entirely different goroutine, but today it does. We should fix that.

orlangure

comment created time in 2 days

issue commentgolang/go

cmd/go: get fails on gitlab subgroups due to go-import meta tags referring to nonexistent repos

@Yi-Hunter, “this issue” as reported by its original author has been verified as fixed. If you're seeing a similar symptom, please open a new issue with details and steps to reproduce it.

umputun

comment created time in 2 days

issue closedgolang/go

cmd/go: go mod vendor in empty new project produces confusing error message in 1.14

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

<pre> go version go1.14 linux/amd64 </pre>

Does this issue reproduce with the latest release?

yes

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

<details><summary><code>go env</code> Output</summary><br><pre> GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/nmartin/.cache/go-build" GOENV="/home/nmartin/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/nmartin/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" 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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build614761053=/tmp/go-build -gno-record-gcc-switches" </pre></details>

What did you do?

<pre> mkdir -p /tmp/go-vendor cd /tmp/go-vendor go mod init github.com/cocorambo/govendor go get github.com/sirupsen/logrus go mod vendor </pre>

What did you expect to see?

I expect go command to create vendor directory and modules.txt file

What did you see instead?

<pre> go mod vendor: open /tmp/go-vendor/vendor/modules.txt: no such file or directory </pre>

closed time in 2 days

cocorambo

issue commentgolang/go

cmd/go: go list reports a mangled ImportPath for a relative path that is not a valid Go package

This appears to be fixed by CL 185345:

example.com$ go list -e -f '{{.ImportPath}}: {{.Error}}' .
.: no Go files in /tmp/tmp.D9RXv9t6b4/example.com
nmiyake

comment created time in 2 days

issue commentgolang/go

proposal: cmd/go: lazy module loading

Thinking about the compatibility section and CI use, if I've understood things correctly, running go mod tidy with go1.13.x on a go.mod file that was otherwise stable with go1.15.x will result in changes, but running with go1.14.x will not.

go mod tidy with any older version, including 1.14, will demolish the go 1.15 invariants.

The difference between 1.13 and 1.14 is that 1.14 will not demolish those invariants unless you invoke go mod tidy explicitly.

Note that we have fixed bugs in go mod tidy in nearly every release so far, so I hope that by now folks have realized that go mod tidy-ness is version-dependent, much like go fmt cleanness. (And note that go fmt with an older Go version may choke on new language features, so it, too, is not something you want to run with older releases in CI.)

bcmills

comment created time in 2 days

issue commentgolang/go

proposal: cmd/go: lazy module loading

People will, per your proposal, need to specify go 1.15 in their go.mod files. I'm not currently aware of any side effects of making that change (from an earlier version), but perhaps that would be worth confirming via an FAQ?

Currently the only other effect on module-mode semantics is that the transition from go 1.13 or lower to go 1.14 or higher also enables automatic use of -mod=vendor when the main module has a vendor subtree. Beyond that, the new language features that come along with the version are all strict additions so far.

bcmills

comment created time in 2 days

issue commentgolang/go

cmd/go: panics listing ./... in GOROOT/src

Thinking about this some more: I don't think there is any clear, concise error message we can emit for go test ./... that explains what the problem actually is, and I don't think folks actually intend for those files to be treated as a package anyway.

We should certainly emit an error for go test ., but I think we should just leave the directory out of the matches for ./..., just like we do for the special builtin package (which also cannot be imported).

Coincidentally, that approach also simplifies the code somewhat.

heschik

comment created time in 2 days

issue commentgolang/go

proposal: cmd/go: lazy module loading

What about go.mod files that are left intentionally untidy?

Don't do that? 😅

Are there any situation where this is still required/desirable? If so, how does that influence (or not influence) the proposed (behaviour) changes?

I would argue that there weren't any situations where that was ever required (or particularly desirable). But if you have specific examples, I'd like to look into them in more depth.

bcmills

comment created time in 3 days

IssuesEvent

issue closedgolang/go

proposal: cmd/go: lazy module loading

I propose to change cmd/go to avoid loading transitive module dependencies that have no observable effect on the packages to be built.

The key insights that lead to this approach are:

  1. If no package in a given dependency module is ever (even transitively) imported by any package loaded by an invocation of the go command, then an incompatibility between any package in that dependency and any other package has no observable effect in the resulting program(s). Therefore, we can safely ignore the (transitive) requirements of any module that does not contribute any package to the build.

  2. We can use the explicit requirements of the main module as a coarse filter on the set of modules relevant to the main module and to previous invocations of the go command.

Based on those insights, I propose to change the go command to retain more transitive dependencies in go.mod files and to avoid loading go.mod files for “irrelevant” modules, while still maintaining high reproducibility for build and test operations.

Design doc: CL 220080.

closed time in 3 days

bcmills

issue commentgolang/go

proposal: cmd/go: lazy module loading

In the context of changing the definition of the all package pattern, does this not imply the change to the definition is contingent on the go version specified in the go.mod file?

Not really, no: the all package pattern (both before and after this proposal) is a function of the import graph, and only interacts with modules (and go.mod files) to the extent that those modules provide imported packages.

But not that the all module pattern does depend on the version, and for a go 1.15 module, the all module pattern as defined in Go 1.14 does not necessarily cover the all package pattern as defined in Go 1.14.

bcmills

comment created time in 3 days

issue commentgolang/go

cmd/go: mod download modpath@HEAD erroneously resolves to a pseudo-version when HEAD is subsequently tagged

At one point we did only fetch the heads and tags. However, the current version of the code fetches the refs and tags along with all ancestors of those commits: https://github.com/golang/go/blob/2ed96d0958a2efb0bb7a0b010fc152b557ce9844/src/cmd/go/internal/modfetch/codehost/git.go#L407-L437

That's potentially a lot of data, but given the default GOPROXY usage it's probably fine for non-canonical versions.

perillo

comment created time in 3 days

issue commentgolang/go

testing: when using a custom TestMain, m.Run does not return if one of the tests it runs panics

I don't think a global panic handler would be an appropriate solution, here or in servers. An uncaught panic may indicate than an important program invariant was violated, and trying to resume execution may just replace a panic with a clear backtrace with a hard-to-diagnose deadlock.

orlangure

comment created time in 3 days

issue commentgolang/go

net/http: "racy use of timers" in (*http2pipe).CloseWithError

That may be #26206..?

bcmills

comment created time in 3 days

issue commentgolang/go

net/http: "racy use of timers" in (*http2pipe).CloseWithError

Could this be related to #37196? (I'm not sure.)

bcmills

comment created time in 3 days

issue commentgolang/go

x/tools/go/loader: data race reported while running TestCycles

Still present: https://build.golang.org/log/ecaa511eb5aca0da535eb5c016e62c9ceb69c3f1

<details>

package nosuchpkg is not in GOROOT (/workdir/go/src/nosuchpkg)
package nosuchpkg is not in GOROOT (/workdir/go/src/nosuchpkg)
open /workdir/gopath/src/golang.org/x/tools/go/loader/missing.go: no such file or directory
open /workdir/gopath/src/golang.org/x/tools/go/loader/missing.go: no such file or directory
/workdir/gopath/src/golang.org/x/tools/go/loader/testdata/badpkgdecl.go:1:34: expected 'package', found 'EOF'
/workdir/gopath/src/golang.org/x/tools/go/loader/testdata/badpkgdecl.go:1:34: expected 'package', found 'EOF'
/go/src/b/x.go:1:21: could not import c (cannot find package "c" in any of:
	/go/src/c (from $GOROOT)
	($GOPATH not set. For more details see: 'go help gopath'))
/go/src/b/x.go:1:21: could not import c (cannot find package "c" in any of:
	/go/src/c (from $GOROOT)
	($GOPATH not set. For more details see: 'go help gopath'))
/go/src/b/x.go:1:21: could not import c (/go/src/c/x.go:1:8: expected 'IDENT', found 'EOF')
/go/src/c/x.go:1:20: expected operand, found 'EOF'
cannot find package "two/three" in any of:
	/go/src/two/three (from $GOROOT)
	($GOPATH not set. For more details see: 'go help gopath')
cannot find package "http" in any of:
	/go/src/vendor/http (vendor tree)
	/go/src/http (from $GOROOT)
	($GOPATH not set. For more details see: 'go help gopath')
/go/src/c/x.go:1:31: cannot convert false (untyped bool constant) to int
==================
WARNING: DATA RACE
Read at 0x00c000752e40 by goroutine 101:
  go/types.(*Package).Imports()
      /workdir/go/src/go/types/package.go:56 +0x2a1
  golang.org/x/tools/go/loader.markErrorFreePackages()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:686 +0x12f
  golang.org/x/tools/go/loader.(*Config).Load()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:669 +0x1d31
  golang.org/x/tools/go/loader_test.TestCycles()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader_test.go:744 +0xac2
  testing.tRunner()
      /workdir/go/src/testing/testing.go:992 +0x1eb

Previous write at 0x00c000752e40 by goroutine 74:
  go/types.(*Checker).collectObjects()
      /workdir/go/src/go/types/resolver.go:264 +0x1c8a
  go/types.(*Checker).checkFiles()
      /workdir/go/src/go/types/check.go:255 +0xd7
  go/types.(*Checker).Files()
      /workdir/go/src/go/types/check.go:248 +0x2a2
  golang.org/x/tools/go/loader.(*importer).addFiles()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:1030 +0x24c
  golang.org/x/tools/go/loader.(*importer).load()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:989 +0x1f5
  golang.org/x/tools/go/loader.(*importer).startLoad.func1()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:970 +0x46

Goroutine 101 (running) created at:
  testing.(*T).Run()
      /workdir/go/src/testing/testing.go:1043 +0x660
  testing.runTests.func1()
      /workdir/go/src/testing/testing.go:1300 +0xa6
  testing.tRunner()
      /workdir/go/src/testing/testing.go:992 +0x1eb
  testing.runTests()
      /workdir/go/src/testing/testing.go:1298 +0x57f
  testing.(*M).Run()
      /workdir/go/src/testing/testing.go:1210 +0x353
  golang.org/x/tools/go/loader_test.TestMain()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader_test.go:32 +0x3d
  main.main()
      _testmain.go:90 +0x223

Goroutine 74 (running) created at:
  golang.org/x/tools/go/loader.(*importer).startLoad()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:969 +0x2bb
  golang.org/x/tools/go/loader.(*importer).importAll()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:884 +0x327
  golang.org/x/tools/go/loader.(*importer).addFiles()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:1014 +0x110
  golang.org/x/tools/go/loader.(*importer).load()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:989 +0x1f5
  golang.org/x/tools/go/loader.(*importer).startLoad.func1()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:970 +0x46
==================
==================
WARNING: DATA RACE
Read at 0x00c0011774c8 by goroutine 101:
  golang.org/x/tools/go/loader.markErrorFreePackages()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:686 +0x161
  golang.org/x/tools/go/loader.(*Config).Load()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:669 +0x1d31
  golang.org/x/tools/go/loader_test.TestCycles()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader_test.go:744 +0xac2
  testing.tRunner()
      /workdir/go/src/testing/testing.go:992 +0x1eb

Previous write at 0x00c0011774c8 by goroutine 74:
  go/types.(*Checker).collectObjects()
      /workdir/go/src/go/types/resolver.go:264 +0x1c50
  go/types.(*Checker).checkFiles()
      /workdir/go/src/go/types/check.go:255 +0xd7
  go/types.(*Checker).Files()
      /workdir/go/src/go/types/check.go:248 +0x2a2
  golang.org/x/tools/go/loader.(*importer).addFiles()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:1030 +0x24c
  golang.org/x/tools/go/loader.(*importer).load()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:989 +0x1f5
  golang.org/x/tools/go/loader.(*importer).startLoad.func1()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:970 +0x46

Goroutine 101 (running) created at:
  testing.(*T).Run()
      /workdir/go/src/testing/testing.go:1043 +0x660
  testing.runTests.func1()
      /workdir/go/src/testing/testing.go:1300 +0xa6
  testing.tRunner()
      /workdir/go/src/testing/testing.go:992 +0x1eb
  testing.runTests()
      /workdir/go/src/testing/testing.go:1298 +0x57f
  testing.(*M).Run()
      /workdir/go/src/testing/testing.go:1210 +0x353
  golang.org/x/tools/go/loader_test.TestMain()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader_test.go:32 +0x3d
  main.main()
      _testmain.go:90 +0x223

Goroutine 74 (running) created at:
  golang.org/x/tools/go/loader.(*importer).startLoad()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:969 +0x2bb
  golang.org/x/tools/go/loader.(*importer).importAll()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:884 +0x327
  golang.org/x/tools/go/loader.(*importer).addFiles()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:1014 +0x110
  golang.org/x/tools/go/loader.(*importer).load()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:989 +0x1f5
  golang.org/x/tools/go/loader.(*importer).startLoad.func1()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:970 +0x46
==================
--- FAIL: TestCycles (0.01s)
    testing.go:906: race detected during execution of test
==================
WARNING: DATA RACE
Write at 0x00c002c30a50 by goroutine 74:
  runtime.mapassign_faststr()
      /workdir/go/src/runtime/map_faststr.go:202 +0x0
  golang.org/x/tools/go/loader.(*importer).load()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:992 +0x2c4
  golang.org/x/tools/go/loader.(*importer).startLoad.func1()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:970 +0x46

Previous read at 0x00c002c30a50 by goroutine 101:
  runtime.mapiterinit()
      /workdir/go/src/runtime/map.go:797 +0x0
  golang.org/x/tools/go/loader.(*Config).Load()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:640 +0x1543
  golang.org/x/tools/go/loader_test.TestCycles()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader_test.go:744 +0xac2
  testing.tRunner()
      /workdir/go/src/testing/testing.go:992 +0x1eb

Goroutine 74 (running) created at:
  golang.org/x/tools/go/loader.(*importer).startLoad()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:969 +0x2bb
  golang.org/x/tools/go/loader.(*importer).importAll()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:884 +0x327
  golang.org/x/tools/go/loader.(*importer).addFiles()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:1014 +0x110
  golang.org/x/tools/go/loader.(*importer).load()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:989 +0x1f5
  golang.org/x/tools/go/loader.(*importer).startLoad.func1()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader.go:970 +0x46

Goroutine 101 (finished) created at:
  testing.(*T).Run()
      /workdir/go/src/testing/testing.go:1043 +0x660
  testing.runTests.func1()
      /workdir/go/src/testing/testing.go:1300 +0xa6
  testing.tRunner()
      /workdir/go/src/testing/testing.go:992 +0x1eb
  testing.runTests()
      /workdir/go/src/testing/testing.go:1298 +0x57f
  testing.(*M).Run()
      /workdir/go/src/testing/testing.go:1210 +0x353
  golang.org/x/tools/go/loader_test.TestMain()
      /workdir/gopath/src/golang.org/x/tools/go/loader/loader_test.go:32 +0x3d
  main.main()
      _testmain.go:90 +0x223
==================
--- FAIL: TestLoad2 (8.75s)
    testing.go:906: race detected during execution of test
--- FAIL: TestLoad1 (8.78s)
    testing.go:906: race detected during execution of test
FAIL
FAIL	golang.org/x/tools/go/loader	43.191s

</details>

dmitshur

comment created time in 3 days

issue openedgolang/go

x/tools/internal/lsp/lsprpc: TestDebugInfoLifecycle is flaky

https://build.golang.org/log/fbfefd18c9b55e2e3dcb6f7a3010e3d2b9615a31

It isn't clear to me whether this is a bug in the test itself or in the code under test.

2020/02/25 14:48:16 : context canceled
2020/02/25 14:48:16 : context canceled
2020/02/25 14:48:16 : context canceled
2020/02/25 14:48:16 closed a connection with error: disconnected
2020/02/25 14:48:16 forwarder: gopls handshake failed: context canceled
2020/02/25 14:48:16 : forwarder: gopls path mismatch: forwarder is "/workdir/tmp/go-build615687836/b640/lsprpc.test", remote is ""
--- FAIL: TestDebugInfoLifecycle (0.65s)
    lsprpc_test.go:217: len(client:Servers) = 0, want 1
FAIL
FAIL	golang.org/x/tools/internal/lsp/lsprpc	0.694s

CC @stamblerre @ianthehat

created time in 3 days

issue commentgolang/go

net: TestDialerLocalAddr is flaky on Dragonfly

I mean that the test is observed to fail nondeterministically.

It is not obvious to me whether the bug is in the Dragonfly kernel, the Go standard library, or the test itself.

bcmills

comment created time in 3 days

issue commentgolang/go

cmd/go: go get module/pkg@master doesn't seem to work sometimes

I can reproduce the same behavior with an explicit commit hash. Having the module already present at v1.2.0 seems to be essential.

foo$ go get -d github.com/grpc-ecosystem/go-grpc-prometheus@v1.2.0
go: downloading github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0
go: finding module for package github.com/prometheus/client_golang/prometheus
go: finding module for package golang.org/x/net/context
go: finding module for package google.golang.org/grpc
go: finding module for package google.golang.org/grpc/status
go: finding module for package google.golang.org/grpc/codes
go: downloading github.com/prometheus/client_golang v1.4.1
go: downloading google.golang.org/grpc v1.27.1
go: downloading golang.org/x/net v0.0.0-20200222125558-5a598a2470a0
go: found github.com/prometheus/client_golang/prometheus in github.com/prometheus/client_golang v1.4.1
go: found golang.org/x/net/context in golang.org/x/net v0.0.0-20200222125558-5a598a2470a0
go: found google.golang.org/grpc in google.golang.org/grpc v1.27.1
go: found google.golang.org/grpc/codes in google.golang.org/grpc v1.27.1
go: found google.golang.org/grpc/status in google.golang.org/grpc v1.27.1
go: downloading github.com/golang/protobuf v1.3.2
go: downloading golang.org/x/sys v0.0.0-20200122134326-e047566fdf82
go: downloading github.com/prometheus/common v0.9.1
go: downloading github.com/cespare/xxhash/v2 v2.1.1
go: downloading github.com/beorn7/perks v1.0.1
go: downloading golang.org/x/text v0.3.0
go: downloading github.com/prometheus/procfs v0.0.8
go: downloading github.com/prometheus/client_model v0.2.0
go: downloading google.golang.org/genproto v0.0.0-20190819201941-24fa4b261c55
go: downloading github.com/matttproud/golang_protobuf_extensions v1.0.1

foo$ go get -d github.com/grpc-ecosystem/go-grpc-prometheus/packages/grpcstatus@6af20e3a5340
go: found github.com/grpc-ecosystem/go-grpc-prometheus/packages/grpcstatus in github.com/grpc-ecosystem/go-grpc-prometheus v1.2.1-0.20191002090509-6af20e3a5340
go: finding module for package github.com/grpc-ecosystem/go-grpc-prometheus/packages/grpcstatus
go get github.com/grpc-ecosystem/go-grpc-prometheus/packages/grpcstatus@6af20e3a5340: module github.com/grpc-ecosystem/go-grpc-prometheus@latest found (v1.2.0), but does not contain package github.com/grpc-ecosystem/go-grpc-prometheus/packages/grpcstatus
mvdan

comment created time in 3 days

issue commentgolang/go

cmd/go: non-top-level packages ending in "/vendor" are omitted from module zip files

That proposal is #30369, but it seems unlikely to be accepted.

bep

comment created time in 3 days

IssuesEvent

issue commentgolang/go

cmd/go: go get module/pkg@master doesn't seem to work sometimes

I can confirm that something is strange here.

go get manages to find the module, but then (for some reason) tries to re-resolve the package without that module.

foo$ go version
go version devel +450d0b2f Tue Feb 25 08:36:15 2020 +0000 linux/amd64

foo$ go mod init test.tld/foo
go: creating new go.mod: module test.tld/foo

foo$ go get -d github.com/grpc-ecosystem/go-grpc-prometheus@v1.2.0
…

foo$ go list -m -f {{.Version}} github.com/grpc-ecosystem/go-grpc-prometheus
v1.2.0

foo$ go get -d github.com/grpc-ecosystem/go-grpc-prometheus/packages/grpcstatus@master
go: downloading github.com/grpc-ecosystem/go-grpc-prometheus v1.2.1-0.20191002090509-6af20e3a5340
go: found github.com/grpc-ecosystem/go-grpc-prometheus/packages/grpcstatus in github.com/grpc-ecosystem/go-grpc-prometheus v1.2.1-0.20191002090509-6af20e3a5340
go: finding module for package github.com/grpc-ecosystem/go-grpc-prometheus/packages/grpcstatus
go get github.com/grpc-ecosystem/go-grpc-prometheus/packages/grpcstatus@master: module github.com/grpc-ecosystem/go-grpc-prometheus@latest found (v1.2.0), but does not contain package github.com/grpc-ecosystem/go-grpc-prometheus/packages/grpcstatus

CC @matloob

mvdan

comment created time in 3 days

issue commentgolang/go

testing: when using a custom TestMain, m.Run does not return if one of the tests it runs panics

At least part of the complexity of the test seems to arise because the runtime does not provide a mechanism for a program to re-raise an existing panic without altering its stack trace. (I've discussed that deficiency with at least @aclements before, but I don't see an issue filed for it.)

If we provided a general mechanism to re-panic without altering the stack trace, then I think the testing package would not need nearly so much complexity on top of that.

orlangure

comment created time in 3 days

issue commentgolang/go

testing: when using a custom TestMain, m.Run does not return if one of the tests it runs panics

If I get CL 134395 cleaned up and merged, it will be fairly straightforward for users to use an errgroup to structure their code such that all goroutines that may panic propagate that panic back to the main goroutine.

Moreover, I suspect that the vast majority of tests do not spawn goroutines, let alone goroutines that may panic. It seems reasonable for users to expect that their best-effort cleanup using defer will actually be invoked most of the time.

orlangure

comment created time in 3 days

issue openedgolang/go

x/build: shard and scale the `longtest` SlowBots

I missed a Windows test failure in CL 220645 because I forgot to run it against the windows-amd64-longtest SlowBot. I forgot to run it against that SlowBot because I'm not in the habit of doing so.

I'm not in the habit of running that SlowBot because it is currently much too slow. To pick some relevant runs:

  • The first run on CL 220717 started at 5:07 PM and completed at 5:31 PM (24 minutes).
  • The second run on that CL started at 5:51 PM and completed at 6:33 PM (42 minutes).
  • The run on CL 220722 started at 5:48 PM and completed at 6:28 PM (40 minutes).

In contrast, a regular TryBot typically caps out around 10 minutes (#32632), and we consider runs that take longer than 20 minutes to be “stuck” (#36629).

I think we should adjust the builder configuration to run the -longtest SlowBots with 4 or more shards each. That way, the end-to-end latency impact of adding one of these bots to a CL will be minimal, and we will not only have less of a disincentive to using them, but also have much faster feedback in order to inform revert-or-fix decisions when one breaks.

CC @golang/osp-team

created time in 3 days

issue closedgolang/go

cmd/compile: "internal compile error: … curfn mismatch" on darwin-amd64-10_11 builder

2020-02-22T04:31:20-f9c51e3/darwin-amd64-10_11

It's not obvious to me whether this is Darwin filesystem flakiness or a regression introduced in the recent cmd/compile refactoring. We should determine which is the case prior to the 1.15 release.

# fmt
<unknown line number>: internal compiler error: curfn mismatch: <N> != <node DCLFUNC>

goroutine 1 [running]:
runtime/debug.Stack(0x1a07de0, 0xc000122008, 0x0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/runtime/debug/stack.go:24 +0x9d
cmd/compile/internal/gc.Fatalf(0x18a2f01, 0x18, 0xc000715278, 0x2, 0x2)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/subr.go:193 +0x291
cmd/compile/internal/gc.(*Escape).newLoc(0xc0008a6780, 0xc0000cf0e0, 0xc000715300, 0xc0008aa4e0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/escape.go:1058 +0x329
cmd/compile/internal/gc.(*Escape).initFunc(0xc0008a6780, 0xc00012c6e0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/escape.go:182 +0xaf
cmd/compile/internal/gc.escapeFuncs(0xc0008a3390, 0xc, 0xe, 0xc000013201)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/escape.go:156 +0xe3
cmd/compile/internal/gc.(*bottomUpVisitor).visit(0xc000715818, 0xc00012c6e0, 0xc000715428)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/scc.go:118 +0x295
cmd/compile/internal/gc.(*bottomUpVisitor).visit.func1(0xc00038ff80, 0xc0007156a0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/scc.go:81 +0xaf
cmd/compile/internal/gc.inspect(0xc00038ff80, 0xc0007156a0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:949 +0xfc
cmd/compile/internal/gc.inspectList(0xc000442660, 0xc0007156a0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:962 +0x58
cmd/compile/internal/gc.inspect(0xc00038ef80, 0xc0007156a0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:956 +0xc8
cmd/compile/internal/gc.inspectList(0xc000442780, 0xc0007156a0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:962 +0x58
cmd/compile/internal/gc.inspect(0xc00038ef00, 0xc0007156a0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:956 +0xc8
cmd/compile/internal/gc.inspectList(0xc000442800, 0xc0007156a0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:962 +0x58
cmd/compile/internal/gc.inspect(0xc000379c80, 0xc0007156a0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:955 +0xac
cmd/compile/internal/gc.inspectList(0xc000442920, 0xc0007156a0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:962 +0x58
cmd/compile/internal/gc.inspect(0xc000379880, 0xc0007156a0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:956 +0xc8
cmd/compile/internal/gc.inspectList(0xc0004466a0, 0xc0007156a0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:962 +0x58
cmd/compile/internal/gc.inspect(0xc000378880, 0xc0007156a0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:956 +0xc8
cmd/compile/internal/gc.inspectList(0xc000446980, 0xc0007156a0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:962 +0x58
cmd/compile/internal/gc.(*bottomUpVisitor).visit(0xc000715818, 0xc00012d080, 0x0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/scc.go:76 +0x13d
cmd/compile/internal/gc.(*bottomUpVisitor).visit.func1(0xc0004bc880, 0xc0007157d0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/scc.go:81 +0xaf
cmd/compile/internal/gc.inspect(0xc0004bc880, 0xc0007157d0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:949 +0xfc
cmd/compile/internal/gc.inspectList(0xc0004460e0, 0xc0007157d0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/syntax.go:962 +0x58
cmd/compile/internal/gc.(*bottomUpVisitor).visit(0xc000715818, 0xc0004c0000, 0xbf8c49a51444cff0)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/scc.go:76 +0x13d
cmd/compile/internal/gc.visitBottomUp(0xc0006f0000, 0xb2, 0xc0, 0x18ba398)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/scc.go:58 +0x95
cmd/compile/internal/gc.escapes(...)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/esc.go:13
cmd/compile/internal/gc.Main(0x18ba218)
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/internal/gc/main.go:675 +0x30a6
main.main()
	/private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/src/cmd/compile/main.go:52 +0xac

go tool dist: FAILED: /private/var/folders/dx/k53rs1s93538b4x20g46cj_w0000gn/T/workdir-host-darwin-10_11/go/pkg/tool/darwin_amd64/go_bootstrap install -gcflags=all= -ldflags=all= -a -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status 2

CC @randall77 @josharian

closed time in 4 days

bcmills

issue commentgolang/go

cmd/compile: "internal compiler error: … unhandled expr" on darwin-amd64-10_11 builder

@dmitshur, we should adjust the buildsRepo functions so that the builder is not active for configurations that do not support it.

(See https://go-review.googlesource.com/c/build/+/169498/6/dashboard/builders.go#1862 for an example.)

bcmills

comment created time in 4 days

issue commentgolang/go

cmd/compile: "internal compiler error: … unhandled expr" on darwin-amd64-10_11 builder

Hmm, #23011 is probably relevant. Looks like we've declared an intent to drop support for macOS 10.11.

@dmitshur, @toothrot, @cagedmantis: given that the 10.11 builder seems to be flaky, would it make sense to go ahead and disable it for the main branch?

bcmills

comment created time in 4 days

issue commentgolang/go

x/exp/gorelease: support for using @latest as a version

That reminds me, I owe @jayconrod a code review on CL 216078.

I think latest makes sense as the default value inferred for -base, although it probably should be supported as an explicit value as well.

myitcv

comment created time in 4 days

issue commentgolang/go

cmd/go: support GOPROXY fallback on unexpected errors

I would prefer not to hard-code any timeouts in the fallback algorithm proper. We can't in general assume that the user is on a fast, reliable network connection, and the decision about when a network connection has actually failed is best left to a lower level (such as the default net/http configuration, which may reasonably initialize itself from some system-specific configuration).

heschik

comment created time in 4 days

issue commentgolang/go

build: all.bash fails for custom GOBIN and leaves test binaries in GOBIN

Bingo:

~/go/misc/cgo/testshared$ go env -w GOBIN=$(mktemp -d)

~/go/misc/cgo/testshared$ go test . -run=TestTrivialExecutable -count=1
--- FAIL: TestTrivialExecutable (0.45s)
    shared_test.go:43: executing ../../bin/trivial (trivial executable) failed fork/exec ../../bin/trivial: no such file or directory:
    shared_test.go:458: elf.Open("../../bin/trivial") failed: open ../../bin/trivial: no such file or directory
FAIL
FAIL    misc/cgo/testshared     1.614s
FAIL
zephyr

comment created time in 4 days

issue commentgolang/go

build: all.bash fails for custom GOBIN and leaves test binaries in GOBIN

Oh, we do that too! https://github.com/golang/go/blob/d243408ae5ec14131dfd83923d2c140325158c0d/misc/cgo/testshared/shared_test.go#L156-L158

I also can't reproduce the problem by setting GOBIN in my environment.

I bet the GOBIN value is coming from go env -w rather than the environment, so os.Unsetenv isn't strong enough to unset it.

zephyr

comment created time in 4 days

issue commentgolang/go

build: all.bash fails for custom GOBIN and leaves test binaries in GOBIN

Oh, that's how: the test is changing to a subdirectory of its own GOPATH: https://github.com/golang/go/blob/master/misc/cgo/testshared/shared_test.go#L108

Probably when we call os.Setenv("GOPATH", gopath) we should also os.Unsetenv("GOBIN").

zephyr

comment created time in 4 days

issue commentgolang/go

build: all.bash fails for custom GOBIN and leaves test binaries in GOBIN

I don't understand how these tests are passing in the first place, if they're hard-coding ../../bin — they shouldn't be allowed to write to GOROOT/bin in the first place (#30316).

zephyr

comment created time in 4 days

issue commentgolang/go

x/net/http2: TestTransportBody* flaky on android and ppc64

Also on aix-ppc64, apparently: *

bcmills

comment created time in 4 days

issue commentgolang/go

cmd/go: mod init shouldn't log information it was given on the command line

What's wrong with invoking go list -m to determine the module path?

perillo

comment created time in 4 days

issue commentgolang/go

cmd/go: mod tidy and mod vendor fighting with each other

I cannot reproduce the observed instability using go1.14rc1 or go1.13.8.

I see only one diff, but that diff is produced identically for both subcommands:

mattermost-server$ git status
On branch tidygomod
Your branch is up to date with 'origin/tidygomod'.

nothing to commit, working tree clean

mattermost-server$ go1.14rc1 mod tidy

mattermost-server$ git diff
diff --git i/go.mod w/go.mod
index 410361d74..2ba38df44 100644
--- i/go.mod
+++ w/go.mod
@@ -67,7 +67,7 @@ require (
        github.com/pkg/errors v0.9.1
        github.com/prometheus/client_golang v1.4.0
        github.com/rs/cors v1.7.0
-       github.com/russellhaering/goxmldsig v0.0.0-20180430223755-7acd5e4a6ef7
+       github.com/russellhaering/goxmldsig v0.0.0-20180430223755-7acd5e4a6ef7 // indirect
        github.com/rwcarlsen/goexif v0.0.0-20190401172101-9e8deecbddbd
        github.com/segmentio/analytics-go v3.1.0+incompatible
        github.com/segmentio/backo-go v0.0.0-20160424052352-204274ad699c // indirect

mattermost-server$ git reset --hard
HEAD is now at eb3f7be36 Merge branch 'master' into tidygomod

mattermost-server$ go1.14rc1 mod vendor
gi
mattermost-server$ git diff
diff --git i/go.mod w/go.mod
index 410361d74..2ba38df44 100644
--- i/go.mod
+++ w/go.mod
@@ -67,7 +67,7 @@ require (
        github.com/pkg/errors v0.9.1
        github.com/prometheus/client_golang v1.4.0
        github.com/rs/cors v1.7.0
-       github.com/russellhaering/goxmldsig v0.0.0-20180430223755-7acd5e4a6ef7
+       github.com/russellhaering/goxmldsig v0.0.0-20180430223755-7acd5e4a6ef7 // indirect
        github.com/rwcarlsen/goexif v0.0.0-20190401172101-9e8deecbddbd
        github.com/segmentio/analytics-go v3.1.0+incompatible
        github.com/segmentio/backo-go v0.0.0-20160424052352-204274ad699c // indirect

I wonder if this is a platform-specific bug — what is the output of your go env?

agnivade

comment created time in 4 days

issue commentgolang/go

cmd/go: support GOPROXY fallback on unexpected errors

Looking at my notes, I think @rsc and I discussed this sort of fallback back in January and settled on essentially the same design.

We observed that, semantically, , indicates a “definitive” proxy (that is, one that should control all module paths), while | indicates a "non-definitive" proxy (that is, one that does not control module paths per se).

From that perspective, the last entry in the list lacks a token because it is always definitive: if the last entry does not or cannot provide the requested path, then that path is de facto unavailable.

heschik

comment created time in 4 days

issue commentgolang/go

cmd/go: mod init shouldn't log information it was given on the command line

(https://github.com/golang/go/issues/35070#issuecomment-545043708 describes another situation where the logging is probably helpful, but the proper fix there is to stop writing the go.mod file in that case.)

perillo

comment created time in 4 days

issue commentgolang/go

cmd/go: mod init prints not requested verbose output

In principle I agree, provided that the module path was specified explicitly.

However, if the module path was inferred automatically (for example, from the location within GOPATH), we should probably still log something about the inferred path.

CC @matloob @jayconrod

perillo

comment created time in 4 days

issue commentgolang/go

runtime/debug: BuildInfo does not honour replace directives

This turned out to be easy enough to just go ahead and fix.

myitcv

comment created time in 4 days

issue commentgolang/go

runtime/debug: BuildInfo does not honour replace directives

This is closely related to #33975, in that modload.PackageBuildInfo is confusing “the main module” with “the module containing package main”. (There is no point in checking for a replacement for “the main module” because it cannot be replaced. However, we should check for a replacement for the module containing package main, because it is not necessarily the main module proper.)

CC @matloob

myitcv

comment created time in 4 days

issue commentgolang/go

missing dot in first path element when building from official golang Docker image

For more information on how to set up a project using Go modules, see the series of blog posts starting with https://blog.golang.org/using-go-modules.

lucas-dehandschutter

comment created time in 4 days

more