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

Wrong return code on nil diagnostics #129

Closed
nalves599 opened this issue Mar 24, 2024 · 2 comments
Closed

Wrong return code on nil diagnostics #129

nalves599 opened this issue Mar 24, 2024 · 2 comments

Comments

@nalves599
Copy link

When I run nil diagnostics <file-name> on a file with only warnings the help util says:

Exit with non-zero code if there are any diagnostics. (1 for errors, 2 if only warnings)

But when there are only warnings it returns 0.

image

The bug might be in this piece of code

@tennox
Copy link
Contributor

tennox commented May 7, 2024

Hey there, just stumbled on this randomly, and I'm also the author of the code you're referring to.

It's in fact the wanted behaviour we ended up deciding for in this discussion - gist:

To me, warnings should not be errors. We can just change the default behavior here to make it returns non-zero only on errors. Users who want the old deny-all behavior can still check if stdout is empty anyway. What do you think?

I did in fact, forget to update the help/documentation I had changed before 😅

If the help would explain the current behaviour correctly, would it still be an issue for you?
i.e. can you just check for empty output in your use-case where you need to know about warnings?

tennox pushed a commit to tennox/nil that referenced this issue May 7, 2024
@nalves599
Copy link
Author

Hey! Thanks for your reply. It's good enough for me and I understand your point of view.

My only concern is trust in the output to check something (i.e. if it has warnings, some output will be printed) :/

But as you discussed, having the option to say that warnings are errors is the best.

oxalica pushed a commit that referenced this issue May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants