add spec for Warning[category] = true|false to emit/suppress warnings

[lxxxvi]

Hello 👋

This time I'll try to cover this one from #745

•  Added Warning.[] and Warning.[]= to manage emitting/suppressing
  some categories of warnings. Feature #16345 Feature #16420

However, I discovered that suppressing experimental (Warning[:experimental] = false) does not seem to work when invoking a script with ruby -e '...'. In irb it works as expected.

Example:

# Tested with Ruby v2.7.2 on macOS 10.15 (Catalina) and Debian 10 (buster)

# :deprecated
ruby -e 'Warning[:deprecated] = true; $; = ""'  # => -e:1: warning: `$;' is deprecated
ruby -e 'Warning[:deprecated] = false; $; = ""' # =>

# :experimental
ruby -e 'Warning[:experimental] = true; 0 in a'  # => -e:1: warning: Pattern matching is experimental ...
ruby -e 'Warning[:experimental] = false; 0 in a' # => -e:1: warning: Pattern matching is experimental ...

Is this expected, or am I missing something here?

[eregon]

I think it's because 0 in a is warned at parse time, vs $; warned on assignment.
Using eval() around 0 in a should make it work.

[lxxxvi]

@eregon Once again, thank you for your precious feedback. 🙇

Today I Learned...

_"0 in a is warned at parse time, vs $; warned on assignment."

(and I guess, that's why it works in irb, because each command is put through eval(..)... ?!)

---

You are right, the warnings disappear with eval('0 in a'), but is this really the intention of Feature 16345?

Given this script.rb

Warning[:experimental] = false
0 in a

ruby ./script.rb
# ./script.rb:2: warning: Pattern matching is experimental, and the behavior may change in future versions of Ruby!

I'd expect that Warning[:experimental] = false suppresses this warning, without wrapping it into eval(..), no?

(Sorry for my annoying questions 😉)

[eregon]

Feel free to mention that drawback on the issue, but it is expected behavior, parse-time warnings can only be disabled if it's set before parsing of course. And pattern matching emits a parse-time warning.

[lxxxvi]

@eregon 👍 Alright, in that case I think that part of the feature is kind of pointless, even if's technically explainable... 🤷 😀

Thanks for your explanation. I changed the specs accordingly and marked this PR as "Ready for review":

[eregon]

Actually deprecated defaults to false in 2.7.2 (but it is true in 2.7.0&1).
I'd suggest using ruby_version_is guards to test that one since it's the big change in 2.7.2:
https://www.ruby-lang.org/en/news/2020/10/02/ruby-2-7-2-released/

Also I just updated the CI to use 2.7.2 so this would actually fail the CI when rebased.

[eregon]

Looks great!

[lxxxvi]

@eregon I rebased master and changed the default for :deprecated to false.

However, I had to change the spec n to use ruby_exe(), because the other way it still returned the old default true:

     3: ruby_version_is '2.7.2' do
     4:   describe "Warning.[]" do
     5:     it "returns default values for categories :deprecated and :experimental" do
     6:       ruby_exe('p Warning[:deprecated]').chomp.should == "false"
     7:       ruby_exe('p Warning[:experimental]').chomp.should == "true"
 =>  8:       binding.irb
     9:     end
    10:
    11:     it "raises for unknown category" do
    12:       -> { Warning[:noop] }.should raise_error(ArgumentError, /unknown category: noop/)
    13:     end

irb: warn: can't alias context from irb_context.
2.7.2 :001 > RUBY_VERSION
 => "2.7.2"

2.7.2 :002 > Warning[:deprecated]
 => true

I have no idea why this is 😏 ... do you?

[eregon]

I have no idea why this is ... do you?

It's because of ruby/mspec@e154fa1, which is intended but I did not think about it in this context.
Using ruby_exe is a good workaround here, especially useful to test global defaults that might be affected by the test harness.

[lxxxvi]

It's because of ruby/mspec@e154fa1 ...

Thanks for that, I was very confused... 😂