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

Jump to bottom

Infinite loop in Layout/HashAlignment autocorrection #9836

Closed
vlad-pisanov opened this issue May 29, 2021 · 0 comments · Fixed by #9837
Closed

Infinite loop in Layout/HashAlignment autocorrection #9836

vlad-pisanov opened this issue May 29, 2021 · 0 comments · Fixed by #9837
Labels
bug

Comments

@vlad-pisanov
Copy link

vlad-pisanov commented May 29, 2021 •
edited

Consider this snippet:

foo x: 1,
    y: 2, **opts

When linting this with Layout/HashAlignment and EnforcedColonStyle: table, Rubocop flags this as:
Layout/HashAlignment: Align the keys and values of a hash literal if they span more than one line
and during auto-correction, errors out with:
Infinite loop detected in file.rb and caused by Layout/HashAlignment

Expected behavior

It should not crash

RuboCop version

1.15.0 (using Parser 3.0.1.1, rubocop-ast 1.7.0, running on ruby 2.6.6 x86_64-darwin20)
  - rubocop-minitest 0.10.1
  - rubocop-performance 1.9.0
  - rubocop-rails 2.8.1
@koic koic added the bug label May 29, 2021
dvandersluis added a commit to dvandersluis/rubocop that referenced this issue May 29, 2021
@dvandersluis
[Fix rubocop#9836] Fix incorrect corrections for `Layout/HashAlignmen…
50153aa 
…t` when a `kwsplat` node is on the same line as a `pair` node with table style.

Keyword splats were previously treated as pairs using colon style, which some hacks in the Alignment classes to handle them. However, this did not account for all possibilities and would cause previous pairs on the same line as the `kwsplat` to be removed by autocorrection.

Instead, now a special `KeywordSplatAlignment` type was added to handle `kwsplat`s. The previously behaviour about `kwsplat`s was retained (they will still be aligned with the beginning of the rest of the hash, regardless of enforced style), and the hacks in `KeyAlignment` and `TableAlignment` for `kwsplat`s were removed.
@dvandersluis dvandersluis linked a pull request May 29, 2021 that will close this issue
[Fix #9836] Fix incorrect corrections for Layout/HashAlignment when a kwsplat node is on the same line as a pair node with table style #9837
Merged
8 tasks
bbatsov pushed a commit that referenced this issue May 31, 2021
@dvandersluis @bbatsov
[Fix #9836] Fix incorrect corrections for Layout/HashAlignment when…
73575d1 
… a `kwsplat` node is on the same line as a `pair` node with table style.

Keyword splats were previously treated as pairs using colon style, which some hacks in the Alignment classes to handle them. However, this did not account for all possibilities and would cause previous pairs on the same line as the `kwsplat` to be removed by autocorrection.

Instead, now a special `KeywordSplatAlignment` type was added to handle `kwsplat`s. The previously behaviour about `kwsplat`s was retained (they will still be aligned with the beginning of the rest of the hash, regardless of enforced style), and the hacks in `KeyAlignment` and `TableAlignment` for `kwsplat`s were removed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
2 participants
@koic @vlad-pisanov