rubocop-rspec: RSpec/FilePath is broken with vscode-ruby after 1.39.0 (2020-05-01)

Details:

• rubocop-rspec version: 1.43.2 (all versions >= 1.39.0 affected)
• Rubocop version: 0.92.0

Related issue with vscode-ruby: https://github.com/rubyide/vscode-ruby/issues/625

---

The RSpec/FilePath cop does not work with vscode-ruby.

It causes issues such as this one (originating from https://github.com/decidim/decidim/pull/6857):

Why this happens is that vscode-ruby runs rubocop inside the folder where the file exists. So, in the example case shown in the screenshot it does the following:

$ cd /home/user/dev/decidim/decidim-assemblies/spec/presenters/decidim/assemblies/admin_log
$ bundle exec rubocop /home/user/dev/decidim/decidim-assemblies/spec/presenters/decidim/assemblies/admin_log/assemblies_type_presenter_spec.rb
Inspecting 1 file
C

Offenses:

assemblies_type_presenter_spec.rb:5:1: C: RSpec/FilePath: Spec path should end with decidim/assemblies/admin_log/assemblies_type_presenter*_spec.rb.
describe Decidim::Assemblies::AdminLog::AssembliesTypePresenter, type: :helper do
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

1 file inspected, 1 offense detected

I was debugging vscode-ruby to find the root cause but I figured it was this commit in rubocop-rspec that has broken the functionality: https://github.com/rubocop-hq/rubocop-rspec/commit/811ae08ea3a60453e18a8bcb9dfaefafd848f779#diff-5b709885b35566a0c699ad4a3200b9b7acbc28ef640fa56a8e66f6c732420a34

Is there some reasoning behind this change or should vscode-ruby change the way it runs the linter?

This could be fixed for vscode-ruby by changing the following lines in rubocop-rspec: https://github.com/rubocop-hq/rubocop-rspec/blob/78f94bb3216fa2a6f27a43af47728762caabde89/lib/rubocop/cop/rspec/file_path.rb#L135-L137

To:

filename = File.expand_path(processed_source.buffer.name)

But maybe this would possibly reintroduce the problems that https://github.com/rubocop-hq/rubocop-rspec/commit/811ae08ea3a60453e18a8bcb9dfaefafd848f779 fixed?

It is hard to make the judgement where the actual bug is without knowing some insight about this change. I don’t understand why it has been made.