Bug #15736
closedr67361 Update to ruby/spec@e81b3cd - spec failures on MinGW ?
Description
ruby-loco (MinGW trunk) had the following failures in spec tests as of r67365 (r67357 passed)
1)
The --enable and --disable flags can be used with gems FAILED
Expected "nil"
to equal "\"constant\""
/ruby/spec/ruby/command_line/feature_spec.rb:6:in `block (2 levels) in <top (required)>'
/ruby/spec/ruby/command_line/feature_spec.rb:3:in `<top (required)>'
2)
The --enable and --disable flags can be used with gem FAILED
Expected "nil"
to equal "\"constant\""
/ruby/spec/ruby/command_line/feature_spec.rb:13:in `block (2 levels) in <top (required)>'
/ruby/spec/ruby/command_line/feature_spec.rb:3:in `<top (required)>'
3)
The --enable and --disable flags can be used with did_you_mean FAILED
Expected "nil"
to equal "\"constant\""
/ruby/spec/ruby/command_line/feature_spec.rb:20:in `block (2 levels) in <top (required)>'
/ruby/spec/ruby/command_line/feature_spec.rb:3:in `<top (required)>'
Updated by Eregon (Benoit Daloze) over 5 years ago
@MSP-Greg (Greg L) Could you investigate why they fail?
Those specs look fine and portable from a quick look.
Does "The --enable and --disable flags can be used with frozen-string-literal" passes?
That's very similar, could it be a bug of command-line parsing or features handling on MRI on Windows?
Updated by MSP-Greg (Greg L) over 5 years ago
Could you investigate why they fail?
Yes. I haven't had time to check it locally, will check tonite...
Updated by MSP-Greg (Greg L) over 5 years ago
Sorry & fixed. My test code had some disable=gems
in test-all, and I never cleared it for spec. The new tests aren't happy with that.
Note that I run tests in ruby-loco from the install folder, so I don't use make. Essentially the same as in ruby/spec...
Feel free to close.
Updated by Eregon (Benoit Daloze) over 5 years ago
MSP-Greg (Greg L) wrote:
Sorry & fixed. My test code had some
disable=gems
in test-all, and I never cleared it for spec. The new tests aren't happy with that.
Great.
Now, it is weird that the command line doesn't override the environment variable (I assume you use RUBYOPT):
$ RUBYOPT=--disable-gems ruby --enable=gems -e 'p defined?(Gem)'
nil
That seems a bug.
$ ruby --disable=gems --enable=gems -e 'p defined?(Gem)'
"constant"
$ ruby --enable=gems --disable=gems -e 'p defined?(Gem)'
nil
works as expected.
Updated by Eregon (Benoit Daloze) over 5 years ago
- Related to Bug #15738: RUBYOPT disables have precedence over the command line added
Updated by Eregon (Benoit Daloze) over 5 years ago
- Status changed from Open to Closed
I'll close this issue, I filed #15738 for the strange behavior.