let gofmt and goimports support the --tags flag (from go build)

[metakeule]

The proposed workaround for #9310 is

$ cat release.go 
// +build !dev 
package foo // import "example.org/foo" 

to have a canonical import path, but not for development (when --tags=dev is passed to go build or go install).

however neither gofmt nor goimports allow tags to be passed, so they are not usable in this scenario. so please add support for tags to these commands.

also if the canonical path does not match the repository path, both commands hang, while they should through the same error as go build.

[bradfitz]

gofmt works on files, not packages, so tags aren't applicable.

goimports also mostly works on files but can scan packages in GOPATH to find symbols. But because it's invoked via your editor, it can't take any options, nor do we want its interface to diverge from gofmt.

I wasn't convinced that #9310 was a problem, either, so it's premature to be finding workarounds.

[minux]

gofmt/goimport, when applied to a package, are supposed to ignore the build
tags and
always format all Go source files in a package, this is to benefit the case
where there are
os_windows.go file in the package, and the developer is running
gofmt/goimport on linux.

go fmt, on the other hand, uses go command to load the package, so it will
check for
vanity imports. As explained above, it also ignores build tags.

Given that they ignore build tags intentionally, why should they take -tags?

You're fighting the vanity import checking. Why? There are more obvious and
correct way
to do it.

If you are complaint about some commands hang, please provide more details.
(note, it's
probable that the command is just waiting for data from stdin.)

[metakeule]

@bradfitz @minux
You want to tell me that it is the correct way for gofmt and goimports to hang if the canonical path does not match the the path inside $GOPATH/src folder?

They either should ignore the // import "" section or should fail with a message.
I prefer them to ignore since they are not building anything.

I am not fighting vanity imports but trying to use them to fix the packaging problems of go (and that could be well done, if... see other ticket).

[bradfitz]

Please tell us how to reproduce a "hang".

[minux]

Also please be aware that sometimes the command hangs because it's waiting
input from stdin.
Try typing ^D (or ^Z on windows) to see if it's the case.

I tried very hard to reproduce the hang you mentioned, but I can't, and I
don't think gofmt or
goimport could possibly hang due to wrong import comments either. Only
cmd/go checks that.
(I've searched the entire golang.org/x/tools repository and
$GOROOT/src/cmd/gofmt directory
for ImportComment, but find none. This means that those commands don't even
request the
go/build package to scan for import comments)

[metakeule]

ok, I re-checked it; my editor did not gave me feedback from errors (only when the canonical import path was set) where it previously did and I attributed it to gofmt and goimports since that was what he is calling.

then I tried inside the shell and had the misconception that like e.g. go build one could omit the path to use the package of the current directory. Instead gofmt and goimports are waiting for input...

My testing was wrong, since the problem was my editor. (I did not use gofmt and goimports directly since they are integrated). so obviously my editor also go builds somehow before calling gofmt/imports.

sorry for the noise.