cmd/go: 'inconsistent vendoring' error when a user module is located within GOROOT/src

[awnumar]

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

$ go version
go version go1.13.1 windows/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
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\ContainerAdministrator\AppData\Local\go-build
set GOENV=C:\Users\ContainerAdministrator\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\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=C:\go\src\github.com\awnumar\memguard\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\ContainerAdministrator\AppData\Local\Temp\go-build491552814=/tmp/go-build -gno-record-gcc-switches

What did you do?

go get ./...
go build -race -v ./...

What did you expect to see?

Expected the go tool to fetch dependencies and build the project.

What did you see instead?

C:\go\src\github.com\awnumar\memguard>call go get ./... 
go: downloading golang.org/x/crypto v0.0.0-20190927123631-a832865fa7ad
go: downloading github.com/awnumar/memcall v0.0.0-20190930130926-11bbaffc6c8f
go: extracting github.com/awnumar/memcall v0.0.0-20190930130926-11bbaffc6c8f
go: extracting golang.org/x/crypto v0.0.0-20190927123631-a832865fa7ad
go: downloading golang.org/x/sys v0.0.0-20190927073244-c990c680b611
go: extracting golang.org/x/sys v0.0.0-20190927073244-c990c680b611
go: finding github.com/awnumar/memcall v0.0.0-20190930130926-11bbaffc6c8f
go: finding golang.org/x/crypto v0.0.0-20190927123631-a832865fa7ad
go: finding golang.org/x/sys v0.0.0-20190927073244-c990c680b611

C:\go\src\github.com\awnumar\memguard>call go build -race -v ./... 
go: inconsistent vendoring in C:\go\src\github.com\awnumar\memguard:
	go.mod requires github.com/awnumar/memguard  but vendor/modules.txt does not include it.
	run 'go mod tidy; go mod vendor' to sync

This is surprising since the exact same build works on linux, freebsd and osx, and since the project uses modules and has no vendor folder or modules.txt file.

The issue started with the recent go1.13 release and is reproducible on at least two of the packages that I maintain.

A log of the failing build is available here: https://cirrus-ci.com/task/6291981996654592

[andybons]

@bcmills @jayconrod

[bcmills]

@awnumar, go get does not update the contents of the vendor directory.

Did you run the command suggested by the error message? If so, did it cause go build to subsequently succeed?

[bcmills]

Ah, go env shows the problem:

set GOROOT=c:\go

GOROOT (in this case, c:\go) is where the Go standard library lives. User code is not intended to be placed there.

[bcmills]

That said, I suspect https://golang.org/cl/198319 would fix this symptom: it makes the vendor check depend on the presence of the vendor directory rather than the module's location within GOROOT/src.

[bcmills]

(That is to say: this would likely be fixed by #33848.)

[awnumar]

@bcmills Running the commands to generate the vendor folder did not fix the issue. Is there an ETA for this patchset?

[bcmills]

@awnumar, assuming that there are no last-minute objections or unforeseen problems, I'm hoping to get #33848 in to 1.14. It will not be released before then, but you can always build from source (with whatever patches you like) in the meantime.

[awnumar]

Can confirm moving the working directory to c:\golang fixed the build.

[bcmills]

The CLs for #33848 have landed, so I believe this should be fixed in gotip (or a go command otherwise built from source at head). Please let us know if you find that is not the case.

[L-maple]

Ah, go env shows the problem:

set GOROOT=c:\go

GOROOT (in this case, c:\go) is where the Go standard library lives. User code is not intended to be placed there.

Yes, this tip has solved my problem!! Thanks!

[digikin]

In windows there are two go folders generated.
C:\Go and C:\Users\XXX\go
To fix this issue you need to place all of your projects under the users golang folder:
C:\Users\XXX\go\src\github.com\XXXX