Set :all/:deprecation_only/:none as options for config.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)

3.99 deprecation for boolean config.warnings = true/config.warnings = false #268

[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.

[pirj]

@JonRowe I've tried inlining the deprecation_warnings= into warnings=, it ended up like this:

- self.deprecation_warnings = true
+ ::Warning[:deprecated] = true if defined?(::Warning) && ::Warning.respond_to?(:[]=)

Do you want to keep it as it is now, or inline?

The decision point here would be the ability to notice and remove those redundant checks when we drop Ruby below 2.7, correct?

I can add a commit here real quick.

[pirj]

My previous comment doesn't stand with us retiring Ruby 2.x support.
There are no downsides left from collapsing those two methods into one.

[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.

[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.

[pirj]

I stumbled across our CLI --warnings option

rspec/rspec-core/features/command_line/warnings_option.feature

Line 3 in 029e58c

Use the `--warnings` option to run specs with warnings enabled.

--warnings already works like :all.

[pirj]

The code to warn users to set the configuration option is getting complicated with the text config (.rspec) and CLI options sparser involved.
So far, I made it work with such a check:

      def warnings_set?
        @warnings_set || @preferred_options.key?(:warnings)

The second part is a shortcut, where a longer path would be to create some WarningsConfigurationManager, following the FilterManager and Order::ConfigurationManager, which feels overkill for what it does.

warnings_option.feature still fails. It expects no warnings if it doesn't pass --warning to rspec, but there's this warning to call config.warning= from spec_helper.rb. If we'd follow the path of adding this setup to this feature spec, whatever we set there undermines the elegance and the clarity of the spec.

What do you think of not warning when this option is not set, and default to :all?

I've pushed a temporary commit, but I'm not happy with the result, and would prefer taking another approach.

[JonRowe]

I've finally gotten 4.0 and 3.99 into a place where this can be merged so I've tidied it up and done so 😂 Thanks for this @byroot I'm sorry its taken so long to land but the default warning behaviour in RSpec 4 will now be the equivalent of :deprecations_only with a recommendation to go to :all in the commented out project template.