False positive for goimports and gofmt when line ending is CRLF

[velut]

Hi,

I noticed that on Windows correctly formatted .go files that have CRLF line endings (\r\n) are reported as
File is not 'goimports'-ed (goimports) or File is not 'gofmt'-ed with '-s'.
Applying the --fix flag changes the line endings to LF (\n) and the errors disappear.

The false positives however impact automated builds on Windows when files are downloaded from git (see for example https://dev.azure.com/scibonaedoardo/fsutils-go/_build/results?buildId=22).

I understand that this may not be golangci-lint fault (golang/go#16355), but I also wanted to post this for reference.

Thank you for your time.

1. Version of golangci-lint: golangci-lint --version (or git commit if you don't use binary distribution)
   1.17.1, installed with go get github.com/golangci/golangci-lint/cmd/golangci-lint@v1.17.1

2. Config file: cat .golangci.yml
N/A

3. Go environment: go version && go env

From my local machine

go version go1.12.6 windows/amd64

set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\edo\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\edo\go
set GOPROXY=
set GORACE=
set GOROOT=c:\go
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\edo\AppData\Local\Temp\go-build544321906=/tmp/go-build -gno-record-gcc-switches

From Azure

go version go1.12 windows/amd64

set GOARCH=amd64
set GOBIN=d:\a\1\s/gopath/bin
set GOCACHE=C:\Users\VssAdministrator\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=d:\a\1\s/gopath
set GOPROXY=
set GORACE=
set GOROOT=C:\hostedtoolcache\windows\go\1.12.0\x64
set GOTMPDIR=
set GOTOOLDIR=C:\hostedtoolcache\windows\go\1.12.0\x64\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\VSSADM~1\AppData\Local\Temp\go-build666985170=/tmp/go-build -gno-record-gcc-switches

4. Verbose output of running: golangci-lint run -v

From my local machine, with an example file

level=info msg="[config_reader] Config search paths: [./ C:\\dev\\golangci-CRLF C:\\dev C:\\]"
level=info msg="[lintersdb] Active 32 linters: [bodyclose deadcode depguard dupl errcheck gochecknoglobals gochecknoinits goconst gocritic gocyclo gofmt goimports golint gosec gosimple govet ineffassign interfacer lll maligned misspell nakedret prealloc scopelint staticcheck structcheck stylecheck typecheck unconvert unparam unused varcheck]"
level=info msg="[lintersdb] Optimized sublinters [staticcheck gosimple unused stylecheck] into metalinter megacheck"
level=info msg="[loader] Go packages loading at mode load types and syntax took 816.8164ms"
level=info msg="[loader] SSA repr building timing: packages building 5.9844ms, total 47.8738ms"
level=info msg="[runner] worker.8 took 12.9653ms with stages: unparam: 11.9683ms, gosec: 997µs, maligned: 0s, scopelint: 0s, goconst: 0s, ineffassign: 0s, varcheck: 0s, deadcode: 0s, typecheck: 0s, gocyclo: 0s, gochecknoglobals: 0s, prealloc: 0s, errcheck: 0s, lll: 0s, structcheck: 0s, unconvert: 0s, nakedret: 0s, gochecknoinits: 0s"
level=info msg="[runner] worker.4 took 15.957ms with stages: interfacer: 14.9601ms, depguard: 996.9µs"
level=info msg="[runner] worker.2 took 21.9411ms with stages: bodyclose: 21.9411ms"
level=info msg="[runner] worker.1 took 74.8ms with stages: misspell: 73.8031ms, gocritic: 996.9µs"
level=info msg="[runner] worker.6 took 119.68ms with stages: govet: 119.68ms"
level=info msg="[runner] worker.7 took 167.5521ms with stages: gofmt: 162.5638ms, golint: 4.9883ms, dupl: 0s"
main.go:1: File is not `gofmt`-ed with `-s` (gofmt)
package main

import "fmt"

func main() {
        fmt.Println("hello")
}
level=info msg="[runner] worker.3 took 196.4756ms with stages: goimports: 196.4756ms"
level=info msg="[runner] worker.5 took 316.1546ms with stages: megacheck: 316.1546ms"
level=info msg="[runner] Workers idle times: #1: 224.3996ms, #2: 261.302ms, #3: 118.6831ms, #4: 270.2772ms, #6: 195.4749ms, #7: 148.6027ms, #8: 276.2594ms"
level=info msg="[runner] Issues before processing: 2, after processing: 1"
level=info msg="[runner] processing took 997.6µs with stages: path_prettifier: 997.6µs, exclude: 0s, max_from_linter: 0s, path_shortener: 0s, skip_dirs: 0s, identifier_marker: 0s, exclude-rules: 0s, uniq_by_line: 0s, cgo: 0s, autogenerated_exclude: 0s, max_same_issues: 0s, filename_unadjuster: 0s, diff: 0s, skip_files: 0s, nolint: 0s, max_per_file_from_linter: 0s, source_code: 0s"
level=info msg="File cache stats: 2 entries of total size 146B"
level=info msg="Memory: 16 samples, avg is 104.6MB, max is 238.5MB"
level=info msg="Execution took 1.4291386s"

[jirfag]

ok, thank you for information!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[corylanou]

I don't think this is a golangci-lint issue, it's a git issue. On github, you solve it by adding a .gitattributes file and adding this line to it:

*.go text eol=lf 

For travis CI, you solve it with by adding this config to the .travis.yml file:

git:
  autocrlf: input

Maybe this needs to be added very clearly in the CI documentation section. It has solved 100% of my gofmt golint issues by doing this.

[sayboras]

I don't think this is a golangci-lint issue, it's a git issue. On github, you solve it by adding a .gitattributes file and adding this line to it *.go text eol=lf

@codyleyhan agreed, I have been using the same settings, this is quite a common problem with vendoring as well.