build: is not compatible with the latest golang.org/x/tools

[sitano]

1. Version of golangci-lint: golangci-lint --version (or git commit if you don't use binary distribution)
   97ea1cbb21bbf5e4d0e8bcc0f9243385e9262dcc / v1.16.0 tag
2. Version of the golang.org/x/tools which is github.com/golang/tools
aef51cc3777c6a88d6834b42444edffdac4860fa
3. Expected behavior: golangci-lint compiles fine
4. Actual behavior:

github.com/golangci/golangci-lint/pkg/lint/load.go:171:2: duplicate case "golang.org/x/tools/go/packages".LoadAllSyntax (value 991) in switch
	previous case at golang.org/x/tools/go/packages/packages.go:98

5. Reason: a change to a const LoadAllSyntax that became equal to a LoadSyntax https://github.com/golang/tools/blob/master/go/packages/packages.go#L104 by golang/tools@dbeab5a

[jirfag]

I've merged the linked pull request. Also, I recommend using binary releases

[sitano]

I recommend using binary releases

@jirfag of course. yet we have a specific CI process in which we include golangci-lint into a vendor of the projects as a dependency. we do use dep instead of mod, that's why we could not move fwd with that - we can't downgrade x/tools dependency as all other libraries depend on the latest version.

[mwf]

Hi guys!

We also hit this problem - @jirfag do you have any plans to make a release with this fix?
1.16.1 or 1.17.0 if you have new stuff in master?

[thepudds]

@jirfag @sitano @leonklingele Any quick thoughts on timing of a new release to resolve the golang.org/x/tools/go/packages issue?

Also, not sure of relationships between the different projects, but it would probably be good to avoid renaming go-consistent (github.com/Quasilyte/go-consistent vs. github.com/quasilyte/go-consistent) if possible (e.g., see quasilyte/go-consistent#34).

Finally, not 100% sure of the history here, so sorry in advance anything I say is off base.

CC @matloob @dmitshur @quasilyte

[jirfag]

Hi!
I can't update x/tools because of #558.

[jirfag]

also, I've made the new release

[thepudds]

FWIW, for the new v1.17.0 release, doing a go get -u fails for me:

cd $(mktemp -d)
go mod init tempmod
go get -u github.com/golangci/golangci-lint@v1.17.0

which fails with error:

go: github.com/Quasilyte/go-consistent@v0.0.0-20190521200055-c6f3937de18c: parsing go.mod: unexpected module path "github.com/quasilyte/go-consistent"

Doing go get -u is fairly common, though removing the -u works:

cd $(mktemp -d)
go mod init tempmod
go get github.com/golangci/golangci-lint@v1.17.0

Some related discussion in #479 (comment) and quasilyte/go-consistent#34.