Project

General

Profile

Bug #15449

Range#=== is not using cover in Ruby 2.6

Added by ana06 (Ana Maria Martinez Gomez) 10 months ago. Updated 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
2.6.0dev (2018-12-20 trunk 66466)
[ruby-core:90660]

Description

irb(main):105:0> ('A'..'Z').cover? 'ANA'
=> true
irb(main):106:0> ('A'..'Z') === 'ANA'
=> false

Is this expected? Should === use cover according to NEWS in Ruby 2.6?

> ruby -v
ruby 2.6.0dev (2018-12-20 trunk 66466) [x86_64-linux]

Files

range-case-cover-string.patch (3.69 KB) range-case-cover-string.patch jeremyevans0 (Jeremy Evans), 07/29/2019 11:32 PM

Associated revisions

Revision 6954ff1d
Added by jeremyevans (Jeremy Evans) 2 months ago

Make Range#=== operate like cover? instead of include? for string ranges

Previously, Range#=== treated string ranges that were not endless or
beginless the same as include?, instead of the same as cover?.
I think this was an oversight in 989e07c0f2fa664a54e52a475c2fcc145f06539d,
as the commit message did not indicate this behavior was desired.

This also makes some previously dead code no longer dead. Previously,
the conditionals were doing this:

if (RB_TYPE_P(beg, T_STRING)
    if (NIL_P(beg)) # can never be true

This restructures it so at the NIL_P(beg) check, beg could possibly
be nil (beginless ranges).

Fixes [Bug #15449]

History

Updated by zverok (Victor Shepelev) 10 months ago

According to code, it first tries to use range_include_internal, which has special handling for strings.

Justification is not obvious, but probably it is an attempt to preserve backwards compatibility?

Updated by ana06 (Ana Maria Martinez Gomez) 10 months ago

If that the case, this should be clarified in NEWS, because it sounds as it was changed for all cases...

Updated by Hanmac (Hans Mackowiak) 10 months ago

That isn't new, that is since 1.9 as #cover? was added

Updated by osyo (manga osyo) 10 months ago

Sorry, Range#=== is called Range#cover? in Ruby 2.6.
see: https://bugs.ruby-lang.org/issues/14575

Updated by jeremyevans0 (Jeremy Evans) 3 months ago

I agree that this is a bug, and not the intended behavior now that Range#=== calls Range#cover? in most cases. Hopefully nobu can confirm. Attached is a patch that fixes the behavior.

I think this should be backported to 2.6, assuming this behavior is not intentional.

#6

Updated by jeremyevans (Jeremy Evans) 2 months ago

  • Status changed from Open to Closed

Applied in changeset git|6954ff1dcb538ee6c042872088b64464a1ef6089.


Make Range#=== operate like cover? instead of include? for string ranges

Previously, Range#=== treated string ranges that were not endless or
beginless the same as include?, instead of the same as cover?.
I think this was an oversight in 989e07c0f2fa664a54e52a475c2fcc145f06539d,
as the commit message did not indicate this behavior was desired.

This also makes some previously dead code no longer dead. Previously,
the conditionals were doing this:

if (RB_TYPE_P(beg, T_STRING)
    if (NIL_P(beg)) # can never be true

This restructures it so at the NIL_P(beg) check, beg could possibly
be nil (beginless ranges).

Fixes [Bug #15449]

Also available in: Atom PDF