/ go Public
cmd/go: set module root directory so editors/scripts see filenames in error messages relative to current directory #47399
FeatureRequest modules NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
This label describes issues relating to any tools in the x/tools repository.
What version of Go are you using (
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
What did you do?
First: This issue is created based on the discussion of #47363 but given that that issue was closed without any resolution to the underlying problem, as it didn't make the problem clear enough, here is the refined issue.
What did you see?
This issue is a "user story" (in the sense of "a legitimate user need that is currently not fulfilled") and could be solved in more than one way. Abbreviating from the conclusion, the behavior "the working directory determines the module" coupled with the behavior "diagnostic file names are printed relative to the working directory" breaks a lot of existing tooling in real-world projects.
go build|run|test ./path/to/directoryused the indicated directory as the root from which to discover which module it's in
gocommand had an option
--module-paththat overrode what the current directory was when determining which module it's in
gotooling print full paths to files in error/failure messages, rather than relative to the current working directory
What did you expect to see?
The problem is one of "I'm a user of go, Typescript, C++, protobuf, and a number of other languages, that all live in a single monorepo, and I want editors to be able to build and test code, and open the correct file when it fails, no matter what particular language is involved in the failure."
One of the subdirectories of this repo contains go code. The root of this monorepo is not a go module. I may not even be focused on a go module when I want to build integration tests.
The working directory of the editor (be it vim, emacs, vscode, or something else) is the root of the monorepo, which is not inside the go module.
Build and test commands invoked by the editor end up being run from the current working directory of the editor, which is the root of the monorepo ;they provide the relative path of the file in question from the editor working directory as argument. This works fine for all the other languages we use.
Currently, I can't find a good way of gluing this presumably not uncommon setup into the go build system, such that the error parser of each kind of editor (vim, emacs, vscode, and more) will find and open the correct file for a test failure (or build failure.)
For the tooling and editors we use, the following things are true:
make -C cpp/path/modulethat's appropriate for each language
subdir/path/module/include/someheader.h:123: template is too complex, or errors are printed with full paths to filenames.
gobuilds used to do
go test ./go/src/whatever/packageand that used to work (and with
GO111MODULEturned off, that invocation now errors out, complaining that the CWD is not within a module, even though the interesting directory in question is within a module.
For purposes of this comment, let's consider an overall project that looks like:
If I were to change the build command for the go package to do something like
cd go/src/whatever && go test ./packagethen the filename printed will be
package/myfile_test.go:123: insufficient shoe sizewhich is relative to
go/src/whatever, not relative to the editor CWD, and thus the editor won't find and open the file.
Best would be "if a directory is the argument to the command, then determine the module based on that directory, not based on the CWD" which would make the current setup Just Work.
Second best would be "allow the module-to-assume to be specified using a separate command line option" which means we could specify the go build/test command as go test --module-root=./go/src/whatever whatever/package -- this is a little more cumbersome because of the duplication of "whatever" in the path (it's both the root of the module, and the root package name) but it can be made to work.
Third best would be a command line option that forces the tooling to always output full path filenames. This will let the editor find the right file no matter what the working directory is. We'd invoke it like cd go/src/whatever && go test --print-full-paths whatever/package
The text was updated successfully, but these errors were encountered: