rubocop / rubocop

A Ruby static code analyzer and formatter, based on the community Ruby style guide.

Home Page:https://docs.rubocop.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

regression in 1.63.1 -- "Could not locate Gemfile"

asottile opened this issue · comments

appears to be a regression of some very old issues #9148 and #6939

a sample ruby file (t.rb)

# frozen_string_literal: true

puts 'hello world'

install a copy of rubocop 1.63.0 and 1.63.1:

GEM_HOME=$PWD/gems-old gem install rubocop --version 1.63.0 --no-document
GEM_HOME=$PWD/gems-new gem install rubocop --version 1.63.1 --no-document

Expected behavior

on 1.63.0 I get:

$ GEM_HOME=$PWD/gems-old gems-old/bin/rubocop t.rb; echo -e "---\n$?"
Inspecting 1 file
.

1 file inspected, no offenses detected
---
0

Actual behavior

on 1.63.1 I get:

$ GEM_HOME=$PWD/gems-new gems-new/bin/rubocop t.rb; echo -e "---\n$?"
Inspecting 1 file
.

1 file inspected, no offenses detected
Could not locate Gemfile
/usr/lib/ruby/3.0.0/bundler/shared_helpers.rb:21:in `default_gemfile'
/usr/lib/ruby/3.0.0/bundler/shared_helpers.rb:26:in `default_lockfile'
/usr/lib/ruby/3.0.0/bundler.rb:453:in `default_lockfile'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/lockfile.rb:16:in `initialize'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli/command/suggest_extensions.rb:108:in `new'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli/command/suggest_extensions.rb:108:in `lockfile'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli/command/suggest_extensions.rb:74:in `all_extensions'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli/command/suggest_extensions.rb:96:in `not_installed_extensions'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli/command/suggest_extensions.rb:88:in `extensions'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli/command/suggest_extensions.rb:18:in `run'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli/command.rb:11:in `run'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli/environment.rb:18:in `run'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli.rb:118:in `run_command'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli.rb:130:in `suggest_extensions'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli.rb:125:in `block in execute_runners'
<internal:kernel>:90:in `tap'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli.rb:125:in `execute_runners'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli.rb:51:in `block in run'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli.rb:77:in `profile_if_needed'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/lib/rubocop/cli.rb:43:in `run'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/exe/rubocop:19:in `block in <top (required)>'
/usr/lib/ruby/3.0.0/benchmark.rb:308:in `realtime'
/tmp/y/z/gems-new/gems/rubocop-1.63.1/exe/rubocop:19:in `<top (required)>'
gems-new/bin/rubocop:25:in `load'
gems-new/bin/rubocop:25:in `<main>'
---
2

annoyingly, --debug causes it to no longer crash:

$ GEM_HOME=$PWD/gems-new gems-new/bin/rubocop t.rb --debug; echo -e "---\n$?"
For /tmp/y/z: Default configuration from /tmp/y/z/gems-new/gems/rubocop-1.63.1/config/default.yml
Use parallel by default.
Skipping parallel inspection: only a single file needs inspection
Inspecting 1 file
Scanning /tmp/y/z/t.rb
Loading cache from /home/asottile/.cache/rubocop_cache/6d1654be5b0207c1e9d80e4f40bb1c9d8d020976/6d7a3b621ca1730e04accd938619e4bdab66cfb1/cde7fc7a75eb728f1543d2d26c72b8a2cff94be8
.

1 file inspected, no offenses detected
Finished in 0.21053658401069697 seconds
---
0

Steps to reproduce the problem

see above!

RuboCop version

Include the output of rubocop -V or bundle exec rubocop -V if using Bundler.
If you see extension cop versions (e.g. rubocop-performance, rubocop-rspec, and others)
output by rubocop -V, include them as well. Here's an example:

$ GEM_HOME=$PWD/gems-new gems-new/bin/rubocop -V
1.63.1 (using Parser 3.3.0.5, rubocop-ast 1.31.2, running on ruby 3.0.2) [x86_64-linux-gnu]

#12826 appears to be the cause -- bisected to b0c508a and reverting it makes the regression goes away -- cc @bbatsov @amomchilov

Thank you for the feedback. I've opened #12847 to solve the issue.

Ah so the issue here isn't the require 'bundler'. That actually succeeded, even in folders without a Gemfile(.lock).

This error was caused by Bundler::GemfileNotFound being raised here:

lockfile_path ||= defined?(Bundler) ? Bundler.default_lockfile : nil