Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/cmd/goimports: Panics when GO111MODULE=on and there is no go.mod #30855

Closed
epk opened this issue Mar 14, 2019 · 4 comments
Closed

x/tools/cmd/goimports: Panics when GO111MODULE=on and there is no go.mod #30855

epk opened this issue Mar 14, 2019 · 4 comments
Milestone

Comments

@epk
Copy link

@epk epk commented Mar 14, 2019

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

$ go version
go version go1.12 darwin/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
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/adi/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/adi"
GOPROXY=""
GORACE=""
GOROOT="/Users/adi/.dev/go/1.12"
GOTMPDIR=""
GOTOOLDIR="/Users/adi/.dev/go/1.12/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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/7c/qpccms_j3v38zgnhczjy8f5c0000gn/T/go-build273490665=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

bar.go

package main

import (
	"github.com/paranoidaditya/foo/pkg/middleware"
)

func main() {
	middleware, err := middleware.New()
	client, err := client.New(middleware)
}
GO111MODULE=on goimports -w bar.go

What did you expect to see?

bar.go

package main

import (
	"github.com/paranoidaditya/foo/pkg/middleware"
        "github.com/paranoidaditya/foo/pkg/client"
)

func main() {
	middleware, err := middleware.New()
	client, err := client.New(middleware)
}

What did you see instead?

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x1286bce]

goroutine 1 [running]:
golang.org/x/tools/imports.(*moduleResolver).scan(0xc000100280, 0xc0001455f0, 0xc000100280, 0x11453b0, 0x1, 0x1, 0xc0001455f0)
	/Users/adi/pkg/mod/golang.org/x/tools@v0.0.0-20190314010720-1286b2016bb1/imports/mod.go:205 +0x11e
golang.org/x/tools/imports.addExternalCandidates(0xc0001821b0, 0xc0001455f0, 0x7ffeefbff295, 0x47, 0x0, 0x0)
	/Users/adi/pkg/mod/golang.org/x/tools@v0.0.0-20190314010720-1286b2016bb1/imports/fix.go:683 +0x73
golang.org/x/tools/imports.fixImportsDefault(0xc0000247c0, 0xc00010c200, 0x7ffeefbff295, 0x47, 0xc00010c080, 0xe00, 0x15cfa80)
	/Users/adi/pkg/mod/golang.org/x/tools@v0.0.0-20190314010720-1286b2016bb1/imports/fix.go:504 +0x2fb
golang.org/x/tools/imports.process(0x7ffeefbff295, 0x47, 0xc00018a000, 0x747, 0xe00, 0x15cfa80, 0xc00010c080, 0x0, 0xc0000b3d98, 0x10344b4, ...)
	/Users/adi/pkg/mod/golang.org/x/tools@v0.0.0-20190314010720-1286b2016bb1/imports/imports.go:72 +0x753
golang.org/x/tools/imports.Process(...)
	/Users/adi/pkg/mod/golang.org/x/tools@v0.0.0-20190314010720-1286b2016bb1/imports/imports.go:50
main.processFile(0x7ffeefbff295, 0x47, 0x0, 0x0, 0x13c2b40, 0xc000094000, 0x1, 0x0, 0x0)
	/Users/adi/pkg/mod/golang.org/x/tools@v0.0.0-20190314010720-1286b2016bb1/cmd/goimports/goimports.go:136 +0x1d4
main.gofmtMain()
	/Users/adi/pkg/mod/golang.org/x/tools@v0.0.0-20190314010720-1286b2016bb1/cmd/goimports/goimports.go:280 +0x230
main.main()
	/Users/adi/pkg/mod/golang.org/x/tools@v0.0.0-20190314010720-1286b2016bb1/cmd/goimports/goimports.go:196 +0x33

creating a go.mod which looks like:

module foobar

require (
	github.com/paranoidaditya/foo v0.0.0
)

replace github.com/paranoidaditya/foo => /Users/adi/src/github.com/paranoidaditya/foo

Fixes the panic

@gopherbot gopherbot added this to the Unreleased milestone Mar 14, 2019
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Mar 15, 2019

@heschik
Copy link
Contributor

@heschik heschik commented Mar 15, 2019

I guess there's no main module when GOMOD=/dev/null. I believe that you can still do go build file.go, but not go build . Maybe goimports should be able to handle it as well as the go command itself does? I think that would mean scanning the module cache, but nothing else.

@bcmills, is that right?

@bcmills
Copy link
Member

@bcmills bcmills commented Mar 15, 2019

Yep, that sounds right.

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 15, 2019

Change https://golang.org/cl/167860 mentions this issue: imports: handle missing main module

movie-travel-code added a commit to elastic/go-langserver that referenced this issue Mar 19, 2019
If GO111MODULE=on but there's no go.mod, GOMOD will be set to /dev/null
or NUL and there will be no main module. goimports should handle this
case roughly the same way the go command does.

Fixes golang/go#30855

Change-Id: I6fbf4c056000db5abd8788a6014ae5f13b1c8cd4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/167860
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
@golang golang locked and limited conversation to collaborators Mar 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.