-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
ExtraSpacing Infinite Correction Loop with AlignHash #2121
Comments
@jfelchner Do have that hash for reproducing? It would help a lot. |
Hi, begin
# Some comment
rescue => e
puts e.response
end here is rubocop response : $ rubocop -a test.rb
Inspecting 1 file
C
Offenses:
test.rb:3:1: C: [Corrected] Use 2 (not 0) spaces for indentation.
rescue => e
test.rb:3:3: C: [Corrected] rescue at 3, 2 is not aligned with end at 5, 0.
rescue => e
^^^^^^
test.rb:4:3: C: [Corrected] Use 2 (not 4) spaces for indentation.
puts e.response
^^^^
0 files inspected, 3 offenses detected, 3 offenses corrected
/usr/local/lib/ruby/gems/2.2.0/gems/rubocop-0.33.0/lib/rubocop/runner.rb:126:in `check_for_infinite_loop': Infinite loop detected in /Users/pgl/developpement/test.rb. (RuboCop::Runner::InfiniteCorrectionLoop)
from /usr/local/lib/ruby/gems/2.2.0/gems/rubocop-0.33.0/lib/rubocop/runner.rb:101:in `block in do_inspection_loop'
from /usr/local/lib/ruby/gems/2.2.0/gems/rubocop-0.33.0/lib/rubocop/runner.rb:100:in `loop'
from /usr/local/lib/ruby/gems/2.2.0/gems/rubocop-0.33.0/lib/rubocop/runner.rb:100:in `do_inspection_loop'
from /usr/local/lib/ruby/gems/2.2.0/gems/rubocop-0.33.0/lib/rubocop/runner.rb:78:in `process_file'
from /usr/local/lib/ruby/gems/2.2.0/gems/rubocop-0.33.0/lib/rubocop/runner.rb:53:in `block in inspect_files'
from /usr/local/lib/ruby/gems/2.2.0/gems/rubocop-0.33.0/lib/rubocop/runner.rb:51:in `each'
from /usr/local/lib/ruby/gems/2.2.0/gems/rubocop-0.33.0/lib/rubocop/runner.rb:51:in `inspect_files'
from /usr/local/lib/ruby/gems/2.2.0/gems/rubocop-0.33.0/lib/rubocop/runner.rb:30:in `run'
from /usr/local/lib/ruby/gems/2.2.0/gems/rubocop-0.33.0/lib/rubocop/cli.rb:26:in `run'
from /usr/local/lib/ruby/gems/2.2.0/gems/rubocop-0.33.0/bin/rubocop:13:in `block in <top (required)>'
from /usr/local/Cellar/ruby/2.2.1/lib/ruby/2.2.0/benchmark.rb:303:in `realtime'
from /usr/local/lib/ruby/gems/2.2.0/gems/rubocop-0.33.0/bin/rubocop:12:in `<top (required)>'
from /usr/local/bin/rubocop:23:in `load'
from /usr/local/bin/rubocop:23:in `<main>'
$
And when I re-run rubocop on 'corrected file', I obtain the same error. |
@Pilooz Thanks, but that's a different error, not related to |
`Style/IndentationWidth` never aligns `rescue` or `ensure`. Related to rubocop#2121.
Here's an example that reproduces this issue: # .rubocop.yml
Style/AlignHash:
EnforcedHashRocketStyle: table
EnforcedColonStyle: table The offending ruby file: hash = {
alice: {
age: 23,
role: 'Director'
},
bob: {
age: 25,
role: 'Consultant'
}
}
p hash Output of RuboCop:
|
To resolve the issue I propose adding an exception for |
How do you think it should be handled? It seems to me that currently the two conflicting cops have different ideas about alignment. |
I think we can just let |
That would certainly solve the conflict at hand. However, I think it's still worth considering my proposal for What would be the benefit of aligning values of top-level keys in the hash example above? It's even more of a pain to fix alignment as the value hashes become bigger. |
@lackac There's no benefit in your example above, but it's easy to tweak the example so aligning the values looks better than not doing so: hash = {
alice: { age: 23,
role: 'Director' },
bob: { age: 25,
role: 'Consultant' }
} So I prefer to let |
[Fix #2121] Allow space before values in hash literals in ExtraSpacing
Currently it appears that
ExtraSpacing
conflicts (possibly?) with theAlignHash
cop's autocorrection. It seems as thoughExtraSpacing
is trying to correct spacing on hash values which I believe it should be prohibited from doing since that's the job of theAlignHash
cop.When I attempt to run it, I get:
@jonas054 I'll attach a hash that will repro this issue in a couple hours.
The text was updated successfully, but these errors were encountered: