Style/LegacyHash cop, prohibiting Hash[] method

[zverok]

# bad
Hash[ary]
^^^^^^^^^ Prefer ary.to_h to Hash[ary].

# good
ary.to_h

# bad
Hash[a, b, c, d]
^^^^^^^^^^^^^^^^ Prefer literal hash to Hash[arg1, arg2, ...].

# good
{a => b, c => d}

# bad
Hash[]
^^^^^^ Prefer literal hash to Hash[arg1, arg2, ...].

# good
{}

Correctly identifies un-autocorrecable cases (Hash[*foo], and an odd number of arguments).
I am open to suggestions regarding the name, it is my best guess :)

---

Before submitting the PR make sure the following are checked:

• The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
• Wrote good commit messages.
• Commit message starts with [Fix #issue-number] (if the related issue exists).
• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
• Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

[tejasbubane]

Please refer this for creating changelog entries. It will create separate files under /changelog which will later be combined into this main file by rubocop maintainer during release.

[tejasbubane]

These messages should be have dynamic variable names. Please refer to other cops like this one

[zverok]

I contemplated this, but I prefer not to. The real code that caused offense might look like this (Rubocop's own codebase):

Hash[PERCENT_LITERAL_TYPES.map do |type|
  [type, preferred_delimiters_config[type] ||
     preferred_delimiters_config['default']]
end]

...and that's not the limit, block inside Hash[] can take many lines, so the suggestion would look really cumbersome. That's why I've decided to stick with abstract recommendations.

[dvandersluis]

@zverok that's a fair point. I think maybe one case we can be more explicit about is Hash[] to {}.

[zverok]

@dvandersluis I actually believe it is the tiniest percent of actual Hash::[] usages in code, and didn't want to complicate the code for the rare case.

[dvandersluis]

Fair enough, I was basing on your example cases.

[tejasbubane]

We should auto-correct this too.

[zverok]

I don't think so. With splat, there are basically two possibilities:

1. Code inside Hash[] produces a flat list of keys and values by design (say, it reads a file which has [key, value, key, value] split line-by-line)
2. Code actually produces an array of pairs, and then flatten(1) added to the end of it to match Hash[] signature.

In both cases, it should be reviewed and redecided by human.
The only working suggestion we can produce is

- Hash[*something]
+ something.each_slice(2).to_h

...and in most cases, it would not be a good suggestion.

[tejasbubane]

For wordings of these example descriptions, please refer: https://github.com/rubocop-hq/rubocop/blob/77db90e6fa0f45ea7cb0b6ec4bee23faf66a385a/lib/rubocop/cop/internal_affairs/example_description.rb

[zverok]

I don't understand this suggestion, sorry. What exactly should be fixed here (except for "tries"→"try" 😂)?

[dvandersluis]

Yeah after correcting "tries" I think it's fine. The internal affairs cop is just to make sure that we don't have descriptions that contradict the actual test.

[bbatsov]

It seems to me that a name like ArrayToHashConversation or something along those lines would be better, as it's both more neutral (allows us to make this configurable) and more descriptive of what the cop actually checks for.

[zverok]

@bbatsov This was my first guess, but...

Hash[:a, 1, :b, 2]

...has no array to be seen :) (And we really have a few of those in the codebase, so they can happen in the wild!)

I thought about configurability and (maybe too bold for me) decided there should be no reason to prefer Hash[foo] to foo.to_h, the .to_h is clearly superior.

[bbatsov]

Fair points. Maybe simply HashConversion then? I still think that LegacyHash is not the most informative name.

[zverok]

@bbatsov Yeah, that's ideal.
Updated cop name, edited commit history to make more sense, pweeze check!

[bbatsov]

Looks great. I'll merge it after we cut 1.9.1.

[jdufresne]

I believe this could be further simplified to avoid the map

              PERCENT_LITERAL_TYPES.to_h do |type|
                [type, preferred_delimiters_config[type] ||
                  preferred_delimiters_config['default']]
              end

[dvandersluis]

to_h with a block was only added in ruby 2.6, but RuboCop supports 2.4, so we can’t use that.

[jdufresne]

Ah I see. Thanks for explaining that.

[bbatsov]

@zverok Can you squash the fixup commit?

[zverok]

@bbatsov Done

[bbatsov]

Just noticed that we need to update the name here as well.

[zverok]

@bbatsov fixed