Skip to content
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

Run revive over a project with an invalid go source file #364

Closed
josemiguelmelo opened this issue Mar 5, 2020 · 8 comments
Closed

Run revive over a project with an invalid go source file #364

josemiguelmelo opened this issue Mar 5, 2020 · 8 comments

Comments

@josemiguelmelo
Copy link

josemiguelmelo commented Mar 5, 2020

Hello,

Describe the bug
When you run Revive on a project that has an invalid go source file, it fails because it can't read the AST.

To Reproduce
Steps to reproduce the behavior:

  1. Create an invalid go source file, such as:
package main

import "fmt"

func example() {
	ok := 1
	if ok == 1 {
		fmt.Print("OK")
	
}
  1. I run it with the following flags & no configuration file:
revive -formatter json

Expected behavior
Instead of failing the entire analysis, Revive could add the AST parsing error to the revive failures list and output it at the end along with other failures.

Logs

Current output:

example.go:10:3: expected '}', found 'EOF'

with exit status 1

@chavacava
Copy link
Collaborator

The current behavior is that of golint.

$ golint test
test/add-constant_test.go:6:2: expected declaration, found "github.com/mgechev/revive/lint"
$ revive test
test/add-constant_test.go:6:2: expected declaration, found "github.com/mgechev/revive/lint"

@josemiguelmelo
Copy link
Author

Is it required to have the exact same behaviour as golint? I think it would be nice to at least have the option to not fail when the AST is invalid in a file. I mean revive doesn't need compilation to analyse the code, so this invalid AST could become a revive Failure instead of finishing the process with exit status 1.

@chavacava
Copy link
Collaborator

chavacava commented Mar 7, 2020

Hi @josemiguelmelo, thanks for filling the issue.
Does revive need to behave as golint? I think yes because it is announced as a drop-in replacement for golint.
I understand your point but we also need to take into account that skipping one file's analysis may bias other files' analysis in the context of typechecked analysis.

Maybe we can add a command line flag to ask for skipping incorrect files.

@josemiguelmelo
Copy link
Author

Sure, sure. That's why I was saying to add this incorrect file to the final results as a Failure, without failing the entire analysis. However, it gets a slightly different behaviour than the golint.

Maybe the command line flag would be nice. With it, revive continues with same behaviour as golint, unless the user specifically uses the flag.

@mgechev
Copy link
Owner

mgechev commented Mar 8, 2020

Although configurability allows a level of flexibility, over time it can get hard to follow what's the combined behavior of different flags.

If we decide to introduce this feature I'd prefer if we enable it by default for everyone. As @chavacava mentioned, ideally we want to keep compatibility with golint, but we can continue the discussion and collect more opinions.

@josemiguelmelo
Copy link
Author

I agree that it can get hard over time. It would be just a way of continuing with the same behaviour as golint by default, except if the user specifies it.

@doniacld
Copy link
Contributor

Hey!
I would be interested to work on this issue. If you could assign it to me please ?

doniacld added a commit to doniacld/revive that referenced this issue Oct 16, 2021
doniacld added a commit to doniacld/revive that referenced this issue Oct 16, 2021
doniacld added a commit to doniacld/revive that referenced this issue Oct 16, 2021
doniacld added a commit to doniacld/revive that referenced this issue Oct 16, 2021
doniacld added a commit to doniacld/revive that referenced this issue Oct 16, 2021
doniacld added a commit to doniacld/revive that referenced this issue Oct 17, 2021
@chavacava
Copy link
Collaborator

closed by #598

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants