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

Style/ConditionalAssignment triggers RuboCop parsing error in specific circumstances #2876

Closed
SaltwaterC opened this issue Feb 22, 2016 · 2 comments

Comments

@SaltwaterC
Copy link

It's bit difficult to explain this in the title itself. Found a piece of code in a Chef recipe triggering an issue in RuboCop. A simplified representation of this code is:

default['key-with-dash'] = []

dirs.each do |dir|
  if user == system_user
    default['key-with-dash'] << {
      'owner' => user,
      'group' => 'group',
      'dir' => "/path1/#{dir}"
    }
  else
    default['key-with-dash'] << {
      'owner' => user,
      'group' => 'group',
      'dir' => "/path2/#{dir}"
    }
  end
end
$ rubocop
Inspecting 1 file
An error occurred while Style/ConditionalAssignment cop was inspecting /Users/user/path/code.rb.
To see the complete backtrace run rubocop -d.
.

1 file inspected, no offenses detected

1 error occurred:
An error occurred while Style/ConditionalAssignment cop was inspecting /Users/user/path/code.rb.
Errors are usually caused by RuboCop bugs.
Please, report your problems to RuboCop's issue tracker.
Mention the following information in the issue report:
0.37.2 (using Parser 2.3.0.5, running on ruby 2.1.6 x86_64-darwin12.0)

The reported error in the backtrace is:

empty range in char class: /default['key-with-dash']\s*<<\s*/

To break the parser, the "default" array key needs to have dashes. This code doesn't trigger any issue:

default['key_without_dash'] = []

dirs.each do |dir|
  if user == system_user
    default['key_without_dash'] << {
      'owner' => user,
      'group' => 'group',
      'dir' => "/path1/#{dir}"
    }
  else
    default['key_without_dash'] << {
      'owner' => user,
      'group' => 'group',
      'dir' => "/path2/#{dir}"
    }
  end
end
rubocop
Inspecting 1 file
.

1 file inspected, no offenses detected

The issue appeared after upgrading to ChefDK 0.11.0 which bundles the latest RuboCop. Built a ChefDK 0.10.0 POC in Test Kitchen which doesn't have this issue:

[kitchen@cfaf8d46339e ~]$ rubocop
warning: parser/current is loading parser/ruby21, which recognizes
warning: 2.1.7-compliant syntax, but you are running 2.1.6.
warning: please see https://github.com/whitequark/parser#compatibility-with-ruby-mri.
Inspecting 1 file
.

1 file inspected, no offenses detected
[kitchen@cfaf8d46339e ~]$ rubocop -V
warning: parser/current is loading parser/ruby21, which recognizes
warning: 2.1.7-compliant syntax, but you are running 2.1.6.
warning: please see https://github.com/whitequark/parser#compatibility-with-ruby-mri.
0.34.2 (using Parser 2.2.3.0, running on ruby 2.1.6 x86_64-linux)
[kitchen@cfaf8d46339e ~]$ cat code.rb
default['key-with-dash'] = []

dirs.each do |dir|
  if user == system_user
    default['key-with-dash'] << {
      'owner' => user,
      'group' => 'group',
      'dir' => "/path1/#{dir}"
    }
  else
    default['key-with-dash'] << {
      'owner' => user,
      'group' => 'group',
      'dir' => "/path2/#{dir}"
    }
  end
end
@SaltwaterC
Copy link
Author

# rubocop:disable Style/ConditionalAssignment does not workaround the issue. Style/ConditionalAssignment needs to be disabled in .rubocop.yml. Tried to wrap the code with disable/enable inline statements. RuboCop correctly reports "Unnecessary disabling of Style/ConditionalAssignment" even though the parsing failure is triggered by this cop.

@SaltwaterC SaltwaterC changed the title Style/ConditionalAssignment triggers Rubocop parsing error in specific circumstances Style/ConditionalAssignment triggers RuboCop parsing error in specific circumstances Feb 22, 2016
@alexdowad
Copy link
Contributor

Thanks for the bug report. Just pushed a fix to my open PR.

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

No branches or pull requests

2 participants