-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use go modules, analysis package and add test #8
Conversation
* Use go modules * Use `analysis.Analyzer` for the linter * Introduce running mode to use from `golangci-lint` * Add tests using the testing package and assert fixer * Add standalone linter (`cmd/whitespace`)
It can be a good idea to add GitHub action. |
I also found a "issue" in whitespace When not using gofmt. It's possible to create multiple whitespaces package main
import "fmt"
func fn3() {
// A comment
// < Whitespace will target this line
// < This is not seen by whitespace, thus fix will only omit the previous line, resulting in yet another linter warning?
fmt.Println(`Hello World`)
} I don't know if this is important enough to fix. Because majority of people use gofmt... |
This is a great question! And I don't think I can answer this. I discussed it briefly in the Also as seen in my my comment #8 (comment), applying the suggested fixes with the Here's an example package that I formatted, showing other changes as well: Before with inconsistent spaces:
And after applying suggested fixes:
Personally I have a hard time seeing the target audience for someone that's interested in a formatter like this but don't care for To avoid false positives I could rewrite this to actually get the position of where the comment ends instead of the |
Thats good information, I wasn't aware of the fact that the If it's before, than the issue will is non-existent
This is "beaking" in a logical sense. But I don't think it's an impact at all. I'll ask my colleague for his opinion to this @elwint, what is your thought on this? |
Sadly it looks like after. Before: › bat -A example.go
───────┬───────────────────────────────────────
│ File: example.go
───────┼───────────────────────────────────────
1 │ package·main␊
2 │ ␊
3 │ ␊
4 │ ␊
5 │ ␊
6 │ import·"fmt"␊
7 │ ␊
8 │ func·main()·{␊
9 │ ␊
10 │ ␊
11 │ ␊
12 │ ····fmt.Println("Hello,·World")␊
13 │ ␊
14 │ ····├──┤fmt.Println("Hello,·World·2")␊
15 │ }␊
───────┴─────────────────────────────────────── After (only one run) › bat -A example.go
───────┬───────────────────────────────────
│ File: example.go
───────┼───────────────────────────────────
1 │ package·main␊
2 │ ␊
3 │ import·"fmt"␊
4 │ ␊
5 │ func·main()·{␊
6 │ ␊
7 │ ├──┤fmt.Println("Hello,·World")␊
8 │ ␊
9 │ ├──┤fmt.Println("Hello,·World·2")␊
10 │ }␊
───────┴─────────────────────────────────── This is actually an issue for |
First of all, thanks for being patient. I think that if it's doable than why not at this point |
Thank you for taking the time to review this and considering the PR 😃
Sure thing, I'll give this a go when I get the time! |
Instead of relying on the file being `gofmt`:ed and only containing one empty line at most this commit will keep track of comments after the opening bracket of block statements and set the fix start to where this comment ends. This means that we will fix all the way from the left bracket or comment til the first statement no matter how many empty lines this is. This will also keep a list of lines affected by the linter to support fixing multiple empty lines in `golangci-lint`.
Wow, can't believe this took me almost a month, sorry about that! Anyway, I added a change so we now keep track of where the opening position is; either the left bracket or the end of a comment on the same line. This made me able to set the whole fix range between where this node ends and where the first statement (or comment) starts. While doing this I also changed I added some test cases where the file is not formatted and contains multiple lines. Sadly since the package main
import "fmt"
func main() {
fmt.Println("Hello, World")
} And ran |
Don't mention it, I really appreciate your expertise. Thanks for all the effort 💪 |
Sorry for the delay.
The consensus about this case is that it should indeed be allowed. After this I think that's all |
Nice solution 💪 First thing in the morning I will review and ask a colleague for review. Thanks for all the effort once again |
No worries, there's no rush here and I appreciate you're considering this PR.
Thanks! Yeah the change grew over time and I understand that this is a lot to review. But I hope that all the test cases should help add some confidence that the code is actually doing what it's supposed to do. If you can think of any more test cases that would probe the expected behaviour feel free to add them!
Thank's for the great feedback and considering this PR! Just let me know if there's anything else missing or that needs clarification. |
Can you create a tag? (I suggest v0.1.0) |
Yes, I will. Thanks for reminding 😅 |
analysis.Analyzer
for the lintergolangci-lint
cmd/whitespace
)Sorry for the big PR and rewrite! While doing some refactoring I renamed
main.go
towhitespace.go
(since it's not amain
package) but it seems likegit
doesn't realize it's a rename as well so the whole file is diffing. As you can see most of the original code is intact and the changes are described below.Given the current requirements in
golangci-lint
and per the discussion in golangci/golangci-lint#3967, linters needs to use theanalysis
package. This PR mostly just adapts to that but to also support fixes from the analyzer itself (which only makes sense since we at one point want to address golangci/golangci-lint#1779). To make the analysis fixer work I did some additional changes:Message.Diagnostic
), where a fix will start which will be theLBrace
or following comment (Message.FixStart
) and where the first statement which is where the fix will end (Message.FixEnd
)golangci-lint
to use the cache to read the file and find the line number, I addedMessage.LineNumber
which tells which line number should be deleted when removing whitespacesMessageType
is now slimmed down to only being eitherMessageTypeRemove
orMessageTypeAdd
To allow the run method to return diagnostics in a way
golangci-lint
want I added support for a running mode which will be set toRunningModeGolangCI
when called fromgolangci-lint
.There's actually no need for this change to add the
cmd/whitespace
binary but given how simple it is to make an executable that also supports fixing I did so anyway.Another benefit of using the
analysis
package is the ease of testing. Given that I added tests for different configuration to ensure the linter does what it's supposed to do.I already prepared a PR in
golangci-lint
which will make use of the changes in this PR: golangci/golangci-lint#4003