Open mx-psi opened 2 years ago
revive
relies on the GO parser
https://github.com/mgechev/revive/blob/2c895fb33f8f3bb0008ab96dcd8619b2ec79927d/lint/file.go#L33
gopls
also relies on the Go parser, they had a similar-ish issue (golang/go#41057) and fixed it (golang/tools@cf7880770c1e80a90b5973b87c1583154b05af5f) while still relying on the Go parser. I was hoping a similar thing could be achieved here.
Is this still relevant? The issue seems fixed and we're using the latest parser.
This can still be reproduced with the latest version (main.go
being the file on my original comment):
❯ go install github.com/mgechev/revive@latest
go: downloading github.com/mgechev/revive v1.2.3
go: downloading github.com/chavacava/garif v0.0.0-20220630083739-93517212f375
❯ revive main.go
<no output>
❯ sed -e $'s/$/\r/' main.go > main_crlf.go
❯ file main_crlf.go
main_crlf.go: ASCII text, with CRLF line terminators
❯ revive main_crlf.go
main_crlf.go:4:1: package comment is detached; there should be no blank lines between it and the package statement
The issue upstream was not fixed by fixing the parser, but by applying a workaround on gopls. The solution would be to apply the same workaround here.
Also getting this bug with revive 1.3.7
and go1.22.3 linux/amd64
.
Describe the bug
revive
will incorrectly reportpackage comment is detached
on CRLF ended files. This is likely related to golang/go#41197.To Reproduce Steps to reproduce the behavior:
go get -u github.com/mgechev/revive
main.go
file with the following content:sed -e $'s/$/\r/' main.go > main_crlf.go
)file main_crlf.go
should sayASCII text, with CRLF line terminators
andcat -v main_crlf.go
should show^M
control codes at the end of lines).revive main_crlf.go
.Expected behavior
revive
should not report anything for that file (i.e. it should have the same behavior as if I skipped steps 3-4).Logs
revive
output isDesktop (please complete the following information):
Additional context
The Go team deemed the issue above unfixable in the parser side because of backwards-compatibility concerns (see golang/go@a14e7bf6d42d9a8b0d698c0a47422c12e38b3f6c). This does not mean the bug is unfixable on
revive
, but the solution may be a bit more cumbersome.