Style/NestedParenthesizedCalls rspec whitelist is non-exhaustive

[ncanning]

RuboCop triggers a violation on some rspec methods that are left out of the list of rspec matchers. In my case, this specifically occurs with be_an:

FNG145099:tmp nathan$ cat test.rb 
should((be nil).or(be_an Integer))
FNG145099:tmp nathan$ rubocop -V
0.38.0 (using Parser 2.3.0.6, running on ruby 2.1.5 x86_64-darwin14.0)
FNG145099:tmp nathan$ rubocop
Inspecting 1 file
C

Offenses:

test.rb:1:20: C: Style/NestedParenthesizedCalls: Add parentheses to nested method call be_an Integer.
should((be nil).or(be_an Integer))
                   ^^^^^^^^^^^^^

1 file inspected, 1 offense detected

[tejasbubane]

There are a lot of matchers which are missing in the list (eg. exist, throw_symbol, etc) and the list will keep growing as rspec grows. I think we should not make our core cop logic dependent on some other gem. Let the user disable the cop whenever required. Thoughts?

[ncanning]

I agree in principle, but by including some rspec matchers, it seems rubocop is somewhat dependent on rspec already, but still produces inconsistent behavior depending on which rspec matchers you're using. Yes, you can just disable the cop if you run into that issue, but I feel that you're sweeping the problem under the rug at that point. Perhaps it's better to remove any rspec dependent logic from the core of rubocop, and put that logic in an rspec-specific cop, e.g. Rubocop-Rspec.

[bbatsov]

Why do you think that is RuboCop dependent on rspec?

Probably it'd be best to drop this functionality and just leave it to people to configure the cop. Hardcoded config is bad, but the option to add/alter config is great.

[ncanning]

Maybe "dependent" isn't exactly the word, but the correctness of this cop relies on the current state of Rspec. I agree though, having some ability to configure this whitelist would be super helpful.