Project

General

Profile

Actions

Bug #15736

closed

r67361 Update to ruby/spec@e81b3cd - spec failures on MinGW ?

Added by MSP-Greg (Greg L) about 5 years ago. Updated about 5 years ago.

Status:
Closed
Assignee:
-
Target version:
-
ruby -v:
ruby 2.7.0dev (2019-03-29 trunk 67365) [x64-mingw32]
[ruby-core:92039]

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)>'

Related issues 1 (0 open1 closed)

Related to Ruby master - Bug #15738: RUBYOPT disables have precedence over the command lineClosedActions

Updated by Eregon (Benoit Daloze) about 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) about 5 years ago

@Eregon (Benoit Daloze)

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) about 5 years ago

@Eregon (Benoit Daloze)

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) about 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.

Actions #5

Updated by Eregon (Benoit Daloze) about 5 years ago

  • Related to Bug #15738: RUBYOPT disables have precedence over the command line added

Updated by Eregon (Benoit Daloze) about 5 years ago

  • Status changed from Open to Closed

I'll close this issue, I filed #15738 for the strange behavior.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0