Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Call .value to get gemspec required_ruby_version only if str_type?
This change avoids an exception (NoMethodError: undefined method `value' for an instance of RuboCop::AST::SendNode) that currently occurs in `rubocop` version 1.61.0 when the project has a gemspec file and that gemspec specifies a `required_ruby_version` by reading from another file (such as `.ruby-version`). This bug began occurring in several of my projects as a result of #12645 (d1746be) ("Check gemspec `required_ruby_version` before `.ruby-version` and other sources"). My projects have both a `.ruby-version` file and a gemspec that sets the `required_ruby_version` by reading from that `.ruby-version` file. Prior to #12645, the latent bug that this change fixes was not occurring for me, because the GemspecFile TargetRuby finder was never running, because the RubyVersionFile TargetRuby finder had higher precedence (and a target Ruby version was found using this finder), and so the GemspecFile TargetRubyVersion finder was never invoked. With #12645, because the GemspecFile finder now runs before the RubyVersionFile finder, this exception has started occurring in these projects, when I try to run rubocop 1.61.0. This exception can be fixed/avoided by checking that the `right_hand_side` is a `str_type?` before attempting to call `right_hand_side.value`. In a setup like mentioned in my projects above, `right_hand_side` will be a `RuboCop::AST::SendNode` and `str_type?` will be false, so we avoid the NoMethodError exception that otherwise will occur if we attempt to call `.value` on that node. I also updated several of the specs in the `target_ruby_spec.rb` file. The motivation for this change is that several of these specs were at risk of "falsely passing", because they had spec setups that intended for `2.7` to be returned as the target Ruby version, but Ruby 2.7 is also currently the `RuboCop::TargetRuby::DEFAULT_VERSION`. So, in working on the bug that is the focus of this change, although one of my initial attempts to fix the bug substantially broke some relevant functionality, all of the specs nevertheless still passed, because they expected a target Ruby version of 2.7 to be returned, and it was still being returned, even after I had broken some of the functionality, simply because Ruby 2.7 is also the default. By setting up the specs to expect a target Ruby version other than the default (Ruby 2.7), the specs will now fail, if/when the relevant functionality under test is broken.
- Loading branch information