Proc#source_location returns [path, start_line, start_column, end_line, end_column] with Ruby 3.5.0dev

[yahonda]

Description

This pull request supports Ruby 3.5.0dev sicne Proc#source_location returns [path, start_line, start_column, end_line, end_column]

This commit addresses the following spec failure with ruby 3.5.0dev since Proc#source_location returns [path, start_line, start_column, end_line, end_column].

Proc#source_location returns [path, start_line] with Ruby 3.4 or earlier.

% ruby -v
ruby 3.5.0dev (2025-03-12T09:42:39Z master b8af9325c0) +PRISM [arm64-darwin24]
% ruby -e 'p proc { true }.source_location'
["-e", 1, 7, 1, 15]

% ruby -v
ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24]
% ruby -e 'p proc { true }.source_location'
["-e", 1]

% ruby -v
ruby 3.5.0dev (2025-03-12T09:42:39Z master b8af9325c0) +PRISM [arm64-darwin24]
% bundle exec rspec ./spec/cucumber/core/test/runner_spec.rb:27
Run options:
  include {locations: {"./spec/cucumber/core/test/runner_spec.rb" => [27]}}
  exclude {slow: true}
F

Failures:

  1) Cucumber::Core::Test::Runner when reporting the duration of a test case with a passing test case records the nanoseconds duration of the execution on the result
     Failure/Error:
       def self.new(file, raw_lines = nil)
         file || raise(ArgumentError, 'file is mandatory')
         if raw_lines
           Precise.new(file, Lines.new(raw_lines))
         else
           Wildcard.new(file)

     ArgumentError:
       wrong number of arguments (given 5, expected 1..2)
     # ./lib/cucumber/core/test/location.rb:32:in 'new'
     # ./lib/cucumber/core/test/action/defined.rb:17:in 'Cucumber::Core::Test::Action::Defined#initialize'
     # ./lib/cucumber/core/test/step.rb:40:in 'Class#new'
     # ./lib/cucumber/core/test/step.rb:40:in 'Cucumber::Core::Test::Step#with_action'
     # ./spec/support/shared_context/test_step_types.rb:6:in 'block (2 levels) in <top (required)>'
     # ./spec/cucumber/core/test/runner_spec.rb:25:in 'block (4 levels) in <top (required)>'
     # ./spec/cucumber/core/test/runner_spec.rb:13:in 'block (2 levels) in <top (required)>'
     # ./spec/cucumber/core/test/runner_spec.rb:31:in 'block (4 levels) in <top (required)>'

Finished in 0.00272 seconds (files took 0.07305 seconds to load)
1 example, 1 failure

Failed examples:

rspec ./spec/cucumber/core/test/runner_spec.rb:27 # Cucumber::Core::Test::Runner when reporting the duration of a test case with a passing test case records the nanoseconds duration of the execution on the result

Type of change

• Bug fix (non-breaking change which fixes an issue)

Note to other contributors

Refer to https://github.com/ruby/ruby/pull/12539 https://bugs.ruby-lang.org/issues/6012 for the background of this change.

Checklist:

Your PR is ready for review once the following checklist is complete. You can also add some checks if you want to.

• [ ] Tests have been added for any changes to behaviour of the code
• [x] New and existing tests are passing locally and on CI
• [x] bundle exec rubocop reports no offenses
• [ ] RDoc comments have been updated
• [x] CHANGELOG.md has been updated

[faisal]

Once this lands in HEAD could it also go into a 13.0.x update?

[luke-hill]

@yahonda Thanks for the work. I'll get round to reviewing this when I have time. Priorities at the moment are seeing me look at cucumber-ruby predominantly. So this likely won't be for a couple of weeks

@faisal At the moment the first priority is getting cucumber v10 out. As that has several major updates for a lot of the downstream gems. So it's likely a cut / release of this won't be the next thing to come

[luke-hill]

Hi @yahonda

Just to clarify expectations. It's still likely I won't get to this until July at the earliest. I really want to focus all my time on getting cucumber v10 out and this is taking its time. This is because there is a bugfix or two in the v10 branch plus a lot of new functionality and CCK conformance

[luke-hill]

I've looked into this some more @yahonda I think there's a better fix we can do as we use little to no information from the Proc. But you've given me enough information to dig it out.

I think the implementor nested inside the core library will be a better place to patch this.

[luke-hill]

Closing in favour of #299 thanks for the pointer