uninitialized constant DidYouMean::SpellChecker

[geshwho]

TLDR: In c92a591, the name similarity module started using DidYouMean::SpellChecker but this gem is not explicitly listed as a dependency.

---

Expected behavior

Rubocop does not crash. We get an offense such as:
Unnecessary disabling of Lint/SuperCoolCop (did you mean Layout/SuperCoolCop?)

Actual behavior

We see the following error when running Rubocop:

Uninitialized constant DidYouMean::SpellChecker
--
  | /var/www/vendor/bundle/ruby/2.6.0/gems/rubocop-0.83.0/lib/rubocop/name_similarity.rb:18:in `find_similar_names'
  | /var/www/vendor/bundle/ruby/2.6.0/gems/rubocop-0.83.0/lib/rubocop/name_similarity.rb:9:in `find_similar_name'

Steps to reproduce the problem

Add a magic comment to disable a cop that does not actually exist. E.g. # rubocop:disable Lint/SuperCoolCop

RuboCop version

$ bundle exec rubocop -V
0.83.0 (using Parser 2.7.1.2, running on ruby 2.6.6 x86_64-darwin19)

[geshwho]

I originally thought that the fix might be as simple as requiring the dependency (#7980), but according the the did_you_mean docs, it is automatically required with ruby starting 2.3.0.

[alvincrespo]

Ran into this yesterday (same versions as you). Weird that it should be autoloader in Ruby and it's not doing so 🤔

[bquorning]

I think the problem has to do with $LOAD_PATH. Here’s the same two commands issues on a my local machine (which does not have the problem) and a Docker container (which does have the problem).

No problem:

❯ ruby -e 'puts DidYouMean::SpellChecker'
DidYouMean::SpellChecker

❯ ruby -e 'puts $LOAD_PATH'
/Users/bquorning/.rubies/ruby-2.5.8/lib/ruby/gems/2.5.0/gems/did_you_mean-1.2.0/lib
/Users/bquorning/.rubies/ruby-2.5.8/lib/ruby/site_ruby/2.5.0
/Users/bquorning/.rubies/ruby-2.5.8/lib/ruby/site_ruby/2.5.0/x86_64-darwin18
/Users/bquorning/.rubies/ruby-2.5.8/lib/ruby/site_ruby
/Users/bquorning/.rubies/ruby-2.5.8/lib/ruby/vendor_ruby/2.5.0
/Users/bquorning/.rubies/ruby-2.5.8/lib/ruby/vendor_ruby/2.5.0/x86_64-darwin18
/Users/bquorning/.rubies/ruby-2.5.8/lib/ruby/vendor_ruby
/Users/bquorning/.rubies/ruby-2.5.8/lib/ruby/2.5.0
/Users/bquorning/.rubies/ruby-2.5.8/lib/ruby/2.5.0/x86_64-darwin18

Problem:

➔ ruby -e 'puts DidYouMean::SpellChecker'
Traceback (most recent call last):
-e:1:in `<main>': uninitialized constant DidYouMean::SpellChecker (NameError)

➔ ruby -e 'puts $LOAD_PATH'
/usr/lib/ruby/site_ruby/2.5.0
/usr/lib/ruby/site_ruby/2.5.0/x86_64-linux
/usr/lib/ruby/site_ruby
/usr/lib/ruby/vendor_ruby/2.5.0
/usr/lib/ruby/vendor_ruby/2.5.0/x86_64-linux
/usr/lib/ruby/vendor_ruby
/usr/lib/ruby/2.5.0
/usr/lib/ruby/2.5.0/x86_64-linux

Why is there no /usr/lib/ruby/gems/2.5.0/gems/did_you_mean-1.2.0/lib in the last output?

[bquorning]

I just found this piece in the Ruby source: https://github.com/ruby/ruby/blob/ruby_2_5/gem_prelude.rb (DidYouMean is defined an empty module if the “did_you_mean” feature is enabled.)

No problem machine:

❯ ruby -e 'puts(gem "did_you_mean")'
false

Problem machine:

➔ ruby -e 'puts(gem "did_you_mean")'
Traceback (most recent call last):
	3: from -e:1:in `<main>'
	2: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:65:in `gem'
	1: from /usr/lib/ruby/2.5.0/rubygems/dependency.rb:322:in `to_spec'
/usr/lib/ruby/2.5.0/rubygems/dependency.rb:310:in `to_specs': Could not find 'did_you_mean' (>= 0) among 478 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/root/.gem/ruby/2.5.0:/usr/lib/ruby/gems/2.5.0:/bundle', execute `gem env` for more information

So it seems the real problem is that the did_you_mean gem is not always available.

[bquorning]

ruby/did_you_mean#117 seems related.

[bbatsov]

Btw, there's a second bug here - VariableForce is not a cop, yet the error message is tied to it, which is extra confusing for the end users IMO.

If we're blocked by an upstream bug we might just limit the cops that rely on this behaviour to Ruby 2.7+ for the time being.

[bquorning]

If we're blocked by an upstream bug we might just limit the cops that rely on this behaviour to Ruby 2.7+ for the time being.

Good point. I’ve suggested a fix in #8143.