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

Warnings in Ruby verbose mode #3457

Closed
nateberkopec opened this issue Aug 30, 2016 · 6 comments · Fixed by #4058
Closed

Warnings in Ruby verbose mode #3457

nateberkopec opened this issue Aug 30, 2016 · 6 comments · Fixed by #4058
Labels

Comments

@nateberkopec
Copy link

I suspect you've already dealt with this issue, but I couldn't find a previous one. Sorry if this is a dupe!

Rubocop outputs lots of warnings when run with RUBYOPT="-w":

/Users/nateberkopec/Code/rubocop/lib/rubocop/cop/performance/string_replacement.rb:24: warning: character class has duplicated range
/Users/nateberkopec/Code/rubocop/lib/rubocop/cop/style/and_or.rb:124: warning: character class has duplicated range: /\?[!\S]/
/Users/nateberkopec/Code/rubocop/lib/rubocop/cop/style/block_comments.rb:31: warning: Unknown escape \z is ignored: /\n(?=[^\z#])/
/Users/nateberkopec/Code/rubocop/lib/rubocop/cop/style/line_end_concatenation.rb:43: warning: literal in condition
/Users/nateberkopec/Code/rubocop/lib/rubocop/cop/style/method_missing.rb:72: warning: assigned but unused variable - temp2

...etc, etc.

Many think that Ruby libraries should not output any warnings when Ruby is running in verbose mode. What say you? Will you accept PRs to fix some of these warnings?

I discovered this while trying to remove some warnings from raven-ruby - we use require 'rubocop/rake_task', so rubocop's warnings were cluttering up the warnings from our own library.

Also, as a side note, how do you see Rubocop interacting with verbose mode? Does Rubocop completely supercede verbose mode, or should they be able to work together?

RuboCop version

$ rubocop -V
0.16.0 (using Parser 2.1.2, running on ruby 2.0.0 x86_64-darwin12.4.0)
@bbatsov
Copy link
Collaborator

bbatsov commented Aug 30, 2016

Guess we'll have to look into this. Btw, the current RuboCop version is 0.42. :-)

@bbatsov
Copy link
Collaborator

bbatsov commented Aug 30, 2016

Also, as a side note, how do you see Rubocop interacting with verbose mode? Does Rubocop completely supercede verbose mode, or should they be able to work together?

That's actually not a verbose mode, but "warnings" mode. Yes, RuboCop is supposed to supersede it.

@nateberkopec
Copy link
Author

Derp, I just copied the version from the issue template. I'm using 0.42/2.3.0.

The Ruby manpage describes it as verbose mode, not warnings mode:

nodachi:raven-ruby nateberkopec$ man ruby | grep verbose
     -W[level=2]    Turns on verbose mode at the specified level without
                          2 (default) Verbose mode is "verbose". It sets the
     -v             Enables verbose mode.  Ruby will print its version at the
     -w             Enables verbose mode without printing version message at
     --verbose      Enables verbose mode without printing version message a

@bbatsov bbatsov added the bug label Sep 6, 2016
@mikegee
Copy link
Contributor

mikegee commented Feb 6, 2017

The reported warnings are all gone. #3698 cleared them up.

When I run Rubocop on itself (RUBYOPT="-w" bin/rubocop lib) I get a warning out of the Parser gem:

/usr/local/bundle/gems/parser-2.3.3.1/lib/parser/lexer.rb:10922: warning: assigned but unused variable - testEof

and an unavoidable warning from a comment about magic comments in MagicComment (so meta):

lib/rubocop/magic_comment.rb:124: warning: `frozen_string_literal' is ignored after any tokens

Unless we institute some kind of "no new warnings" check, there's nothing to do for this issue.

@backus
Copy link
Contributor

backus commented Feb 6, 2017

and an unavoidable warning from a comment about magic comments in MagicComment (so meta):

I'd be fine with just tweaking or removing this comment. If it emits warnings for all users then it is probably not worth it.

@backus
Copy link
Contributor

backus commented Feb 6, 2017

Unless we institute some kind of "no new warnings" check, there's nothing to do for this issue.

I've implemented a "No new warnings" check for a few open source projects I've contributed to that could be helpful here. For example, see https://github.com/backus/mutest/blob/c4765390103b514b066c2a1e59ee81c98bafe3d2/spec/spec_helper.rb#L66-L69 https://github.com/backus/mutest/blob/c4765390103b514b066c2a1e59ee81c98bafe3d2/spec/support/warning.rb. Basically it compares ruby warnings against warnings listed in a config file and then asserts at the end of the test suite that there weren't any new warnings. It is a bit of a hack but it works very nicely

mikegee added a commit to mikegee/rubocop that referenced this issue Feb 22, 2017
The documentation for `MagicComment` produced:
```
lib/rubocop/magic_comment.rb:124: warning: `frozen_string_literal' is ignored after any tokens
```
bbatsov pushed a commit that referenced this issue Feb 23, 2017
The documentation for `MagicComment` produced:
```
lib/rubocop/magic_comment.rb:124: warning: `frozen_string_literal' is ignored after any tokens
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants