Proposal for testdata convention - spoof source root with go.mod to assist IDEs about go-flow-levee HOT 6 CLOSED

Whoops. It looks like I misplaced the go.mod file. It should be in .../testdata/src/github.com rather than the .../src/. When I was cleaning up the example PR, IntelliJ must've been holding linkage in the cache and not cared that I moved the module file.

Thanks for the early investigation. Maybe the updated PR this one will work for you, like it does for me:

from go-flow-levee.

That sounds fine to me. I don't have a hard preference concerning what the exact directory hierarchy should look like, as long as we can run the tests and the package resolution works.

from go-flow-levee.

analysistest expects testdata to be a fake GOROOT.

AFAIU analysistest takes whatever dir we give it (typically testdata) and makes that the GOPATH:

Env:   append(os.Environ(), "GOPATH="+dir, "GO111MODULE=off", "GOPROXY=off"),

Additionally, while I believe I'm the only one who does this, but it also prevents general execution of an analyzer from the command-line.

I've tried to do this a bunch of times. Most often I want to run levee itself on a directory under testadata. Sometimes ssadump too, e.g. it would be useful to be able to watch a test file I'm editing an see the SSA be regenerated live.

I like the idea of making test files easier to edit. Currently this proposal doesn't work for me in IntelliJ, though:

(I tried running config_test.go, both within IntelliJ and in the command line. I also tried doing Invalidate caches and restart.)

ssadump doesn't work either:

$ ssadump crosspkg.go 
crosspkg.go:18:2: cannot find module providing package github.com/example/core: module github.com/example/core: git ls-remote -q origin in /home/mlevesquedion/go/pkg/mod/cache/vcs/8fc61489a66c10f1cb2720315adbd1fcddb2be09da2b16992c594b1f4bd0a249: exit status 128:
	fatal: could not read Username for 'https://github.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.
crosspkg.go:19:2: cannot find module providing package github.com/example/notcore: module github.com/example/notcore: git ls-remote -q origin in /home/mlevesquedion/go/pkg/mod/cache/vcs/fcbb7f6dcdc96c1e7b9e49966da169abb5f1af41b6a1d625d4cd4bfdf6bea6d7: exit status 128:
	fatal: could not read Username for 'https://github.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.
crosspkg.go:20:2: cannot find module providing package github.com/notexample/core: module github.com/notexample/core: git ls-remote -q origin in /home/mlevesquedion/go/pkg/mod/cache/vcs/05d82718a71502c6bdc0b5cf2d857df5d61bfd8f91b2a0f114a9632f1ade61ce: exit status 128:
	fatal: could not read Username for 'https://github.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.
/home/mlevesquedion/Development/go-flow-levee/internal/pkg/config/testdata/src/github.com/example/crosspkg/crosspkg.go:18:2: could not import github.com/example/core (invalid package name: "")
/home/mlevesquedion/Development/go-flow-levee/internal/pkg/config/testdata/src/github.com/example/crosspkg/crosspkg.go:19:2: could not import github.com/example/notcore (invalid package name: "")
/home/mlevesquedion/Development/go-flow-levee/internal/pkg/config/testdata/src/github.com/example/crosspkg/crosspkg.go:20:9: could not import github.com/notexample/core (invalid package name: "")
ssadump: packages contain errors

from go-flow-levee.

Looks good on my end. This is great!

from go-flow-levee.

Glad it's not dependent on some weird config specific to my workflow!

To formalize the convention, do you have any input as to how we should name things? I was thinking that the root "package" that the go.mod spoofs should mirror the test file where it's going to be consumed. For instance, the files consumed by analyzer tests in config_test.go would correspond to files in .../testdata/src/config_test/**. The go.mod would need to live in that src/config_test/ root.

I haven't tested it yet, but I do believe we'll want to have the various src/<synthetic root> have distinct names. I'm not sure how an IDE would handle a collision if we had multiple modules defining the same (e.g.,) example.com.

from go-flow-levee.

This sounds great. Not seeing all the red in IDE is a quality of life improvement!

from go-flow-levee.