Fix stack overflow when loading default config - JRuby on Windows 8

[pimterry]

It's impossible to start Rubocop on my machine, with JRuby and Windows 8 (not sure which is the issue). Rubocop version 0.29.1.

If you try to so, you get a stack overflow, with:

SystemStackError: stack level too deep                                                                              
                   each at org/jruby/RubyArray.java:1613                                                            
              partition at org/jruby/RubyEnumerable.java:914                                                        
               validate at C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/lib/rubocop/config.rb:102       
      warn_unless_valid at C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/lib/rubocop/config.rb:80        
              load_file at C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/lib/rubocop/config_loader.rb:41 
           base_configs at C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/lib/rubocop/config_loader.rb:69 
                    map at org/jruby/RubyArray.java:2412                                                            
           base_configs at C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/lib/rubocop/config_loader.rb:60 
    resolve_inheritance at C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/lib/rubocop/config_loader.rb:128
              load_file at C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/lib/rubocop/config_loader.rb:29 
  default_configuration at C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/lib/rubocop/config_loader.rb:99 
               validate at C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/lib/rubocop/config.rb:103       
                   each at org/jruby/RubyArray.java:1613                                                            
              partition at org/jruby/RubyEnumerable.java:914                                                        
               validate at C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/lib/rubocop/config.rb:102       
      warn_unless_valid at C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/lib/rubocop/config.rb:80        
              load_file at C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/lib/rubocop/config_loader.rb:41 
           base_configs at C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/lib/rubocop/config_loader.rb:69 
                    map at org/jruby/RubyArray.java:2412         
                    ....                                                   

This happens because the check that ensures Rubocop does not validate its own config (and fall into an infinite loop) simply checks that RUBOCOP_HOME is not a prefix (via start_with?) of the config path. That's not sufficient.

For this check to be sufficient each path must be in a canonical format first, as otherwise two different (by string comparison) paths might actually refer to the same underlying path, giving false negatives.

In my case the paths being compared are:

C:\jruby-1.7.18\lib\ruby\gems\shared\gems\rubocop-0.29.1/config
C:/jruby-1.7.18/lib/ruby/gems/shared/gems/rubocop-0.29.1/config/enabled.yml

Note the different slashes. Path 1 is in reality a parent directory of path 2, but it is not a string prefix of path 2 (which is what the current test checks for). This seems to happen because File.realpath produces different slashes to File.join, but I don't think the source of this matters.

This patch fixes this generally, by ensuring the paths are always run through File.expand_path first, which ensures you get a canonical format for the path, not just what you were given from elsewhere. I've also put in an actual test for this feature (not validating your built-in config), since there wasn't one.

[bbatsov]

Add () for starts_with?.

[bbatsov]

The change looks good to me. Address my tiny remarks and add a changelog entry.

[pimterry]

Fixes and changelog entry added, and rebased.

[bbatsov]

Add a blank line here.

[bbatsov]

Squash the two commits and we're good to go.

[pimterry]

Squashed, should be good to go now.

[coveralls]

Coverage increased (+0.0%) to 99.65% when pulling 2b2a0a7 on pimterry:infinite-path-check-loop into 76e8f88 on bbatsov:master.

[coveralls]

Coverage increased (+0.0%) to 99.65% when pulling 2b2a0a7 on pimterry:infinite-path-check-loop into 76e8f88 on bbatsov:master.

[bbatsov]

👍

[pimterry]

Thanks for merging this. Any timeline on when it'll be released? I have some developers on Windows machines working with JRuby atm, and Rubocop being unusable in those conditions is causing some problems.