Golangci-lint: False positive from gofmt on Windows

[panjf2000]

• [x] Yes, I'm using a binary release within 2 latest major releases. Only such installations are supported.
• [x] Yes, I've searched similar issues on GitHub and didn't find any.
• [ ] Yes, I've included all information below (version, config, etc).

Hi,
I got an issue when integrating golangci-lint with travis, it kept misreporting the gofmt alert, this is the details about it: https://github.com/panjf2000/gnet/runs/569818757 where golangci-lint insisted that those files were not gofmt-ed on Windows while those files are wellformed on Linux/OSX, judged by golangci-lint.

This is the yml of travis: https://github.com/panjf2000/gnet/blob/165ebf6420d97ad99dfea9a2c710cae6e5f1e405/.travis.yml, the version of golangci-lint is v1.24.0.

[panjf2000]

I had to exclude Windows currently to get rid of these false positives but still, it is not the radical solution, so I'm hoping that we can locate the root cause and resolve it?

[renypaul]

I am also seeing the same issue. Same code works fine on Linux machine

[ernado]

Probably it has something to do with https://github.com/golangci/gofmt handling of line endings.

Am I correct that only gofmt is affected?

[panjf2000]

Am I correct that only gofmt is affected?

It is only gofmt so far, as I can see.

[dbungert]

I have a private repository that will false-positive report a need for gofmt and goimports. Here's what I know:
1) It doesn't happen with default git checkout settings on windows, but can be produced with a fresh clone using:
git config --system core.autocrlf true
2) The issue can be produced on linux, if you force to windows newlines:
find . -type f -name '*.go' -exec unix2dos {} \;
3) successive invocations of golangci-lint complain about different files
4) gofmt/goimports on the files in question doesn't actually change anything

[dbungert]

See also https://github.com/golangci/golangci-lint/issues/580

[adrianre12]

This is a rather frustrating issue. today I did a merge and had over 700 files fail goimport and not one single line of code was different. Looking back through the history of issues it has been reported for years and it seems that there is a great reluctance to do anything about it.
GoFmt really should be agnostic of line endings as the Go compiler is. Not supporting one of the major operating systems file endings is just daft.