Project

General

Profile

Actions

Bug #15449

closed

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

Added by ana06 (Ana Maria Martinez Gomez) over 5 years ago. Updated over 4 years ago.

Status:
Closed
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

Updated by zverok (Victor Shepelev) over 5 years 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) over 5 years 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) over 5 years ago

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

Updated by osyo (manga osyo) over 5 years ago

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

Updated by jeremyevans0 (Jeremy Evans) over 4 years 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.

Actions #6

Updated by jeremyevans (Jeremy Evans) over 4 years 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]

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0