Introduce config.deprecation_warnings

[byroot]

Fix: #37

Since Ruby 2.7.2, Ruby expect test frameworks to enable deprecation warnings so users get advance notice of future breaking changes.

I implemented it as specified in #37 (comment)

[byroot]

Hum, CI fails because of the 100% coverage target, but I don't know how I can satisfy this given some code path are only ever entered by some specific Ruby versions.

I'll try to do some static define instead but I don't think it will work.

[byroot]

Alright, I tried a few workarounds but they're all awful and don't pass the coverage check anyway, so I'll wait for instruction from the maintainers.

[byroot]

Alright, I believe the remaining errors are unrelated to my changes?

[JonRowe]

Personally, I'd rather we overload warnings= here to be one of: false :deprecations_only :all or true where true has the same effect as :all

[byroot]

I suppose that make sense, one downside I can think of however if that since regular warnings are quite verbose, it's likely that a bunch of projects have warnings = false and won't ever know about deprecation warnings.

So while I agree making it a difference config is a bit less clean, it give every RSpec user the opportunity to know about it.

But that's your call.

[JonRowe]

I think that risk is low as false was the default, but I propose that the setting be :none, :deprecations_only and :all with true/false synonyms for :all/:none that in turn issue an RSpec deprecation warning asking people to update to the specifics.

[byroot]

Ah I see. Ok, I'll try to implement that then.

[byroot]

Alright, I think I implemented what you suggested. I'm not really familiar with RSpec codebase though, so hopefully it's implemented the proper way?

[JonRowe]

Last change, can we wrap this up into the above

[byroot]

I'm sorry, I don't think I understand what you mean by that.

[benoittgt]

Hello Jean

I see two failures in feature specs.

bundle exec cucumber features/configuration/enable_global_dsl.feature:40
bundle exec cucumber features/command_line/ruby.feature:10

It happens in the CI after the simplecove coverage tests...

The issue seems related to how we try to report caller lines when using .warning. Maybe @JonRowe knows if .warning should be used here. I'm tempted to change how we report caller line. In my test I have 14 frames and with the current setup we are getting outside of frames before looping 3 times. 😄

Quick and dirty.

--- a/rspec-support/lib/rspec/support/caller_filter.rb
+++ b/rspec-support/lib/rspec/support/caller_filter.rb
@@ -65,7 +65,7 @@ module RSpec
 
         loop do
           stack = caller_locations(skip_frames, increment)
-          raise "No non-lib lines in stack" unless stack
+          break unless stack

Snippet to reproduce.

require "bundler/inline"
gemfile(true) do
  source "https://rubygems.org"
  gem 'rspec', path: '../rspec'
end

require 'rspec/autorun'

RSpec.describe 'Joyeux Noël' do
  it do
    expect({ :a => 1, :b => 2 }).not_to include(:a, :b)
  end
end

[byroot]

I fixed the typos in the message.

For the remaining failures, I don't know what to do, so I'll await further instructions.

[byroot]

The remaining failures are what @benoittgt pointed out.

Both failing scenarios are related to rspec/autorun:

Failing Scenarios:
cucumber features/command_line/ruby.feature:10 # Scenario: Require `rspec/autorun` from a spec file
cucumber features/configuration/enable_global_dsl.feature:40 # Scenario: By default rspec/autorun allows the DSL to be used globally

It fails because it's emitting a warning about config.warnings not being set.

[byroot]

Thanks for the fix, I was a bit stuck because of my limited knowledge of rspec.

One of the spec I added now complains but I can fix that.

[pirj]

That one seemed flaky and caused by order dependence (/tmp/aruba isn't getting created when `rspec spec/integration/order_spec.rb is run). But the seemingly trivial fix, mocking other similar specs that use Aruba, didn't work. I can reproduce this locally. PS fixed. PPS merged in #176

I don't mind reverting my last commit and merging this PR as is, as this failure seems largely unrelated to this PR. @JonRowe WDYT?
But if it's a quick fix, I hope you don't mind including it. I can extract the flaky fix.

My apologies for the inconvenience, we've just changed the repo structure dramatically, and it may have some rough edges

[pirj]

💚

[benoittgt]

LGTM. Thanks !

[JonRowe]

Apologies for the delay in getting back to this some build failures and work have sucked up all my free time, its on my list to get this in this week.

[JonRowe]

Can we also back out the unrelated changes for the other specs, @pirj if you'd like to work on another PR for those I'm happy to review that.

[pirj]

@JonRowe Done

[pirj]

RuboCop job fix #201

HunkGenerator is flaky

@JonRowe is the rest good to merge?

[JonRowe]

Sorry for the silence on this, I'm going to merge this manually when I get the time to split it into 3.x and 4.x capable patches, but no input is needed beyond that.