-
-
Notifications
You must be signed in to change notification settings - Fork 395
Fix Include Matcher For Ranges #1324
Fix Include Matcher For Ranges #1324
Conversation
06b29d1
to
df827ac
Compare
df827ac
to
47d409f
Compare
Does it make sense to rebase this on |
@pirj Thanks for your help on that other PR! I'm not sure what a normal review timeline is for RSpec; is there something you could do to help get this one approved + merged? I'd love to get this merged in before the 4.0 release if possible. Thanks again for your help! |
It may take a while. We're making our best effort, but often times life and daily job intervenes, and it may take longer. Processing has improved this year, though: |
Ah that's really helpful; I mostly wanted to be sure it didn't get lost in the shuffle but sounds like these things, understandably, take time. Thanks for the info! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
What do you think of re-targeting it for RSpec 4 where we've dropped support for Ruby < 2.2? It would require rebasing on top of 4-0-dev
and chaning the base branch of the PR.
|
||
shared_context "only runs for modern rubies" do | ||
around(:example) do |example| | ||
example.run if RUBY_VERSION >= "2.1.9" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we change this for an expected error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JonRowe Definitely!
I just pushed a PR that runs examples for all ruby versions so I can see the error across older rubies (the retention window for this PR's build logs has elapsed).
Mind kicking off another build, I'll see which errors crop up and figure out where to go from there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, I wish Github remembered approvals, I assume it goes off "merged commiters"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JonRowe Awesome, I just pushed those changes (it looks like old rubies raise a TypeError
so that's what I now expect to get raised for those versions).
Mind kicking off one more build?
Also, I'm not 100% sure that my naming for the shared examples is best. Open to suggestion there!
let(:range) { (start..finish) } | ||
end | ||
|
||
shared_context "only runs for modern rubies" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we do the below this should be renamed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to merge this once we've addressed what happens on older Rubies, I don't mind it "not working", I'd just like the specs to show what happens on older Rubies, even if thats just this (or equivalent):
if RUBY_VERSION >= "2.1.9"
example.run
else
expect { example.run }.to raise_error(WhateverErrorIsRaised)
end
fb1a144
to
b070eb9
Compare
Hi @JonRowe, I'd like to suggest going with the approach that only runs these new tests for ruby >= 2.1.9. This covers all ruby versions in the last 9 years and fixes the bug. How would you feel about that? Here's a bit of technical discussion about why I don't think the proposed approach quite works: I don't think there's a straightforward way to expect examples to raise a
actually causes 2 failures for specs run on pre-2.1.9 ruby:
This is because the original expectation is evaluated first and isn't met (it raises a Do you know a way around this? If not, I'd love to merge as is since it still represents a solid improvement. Let me know what you think! |
This is issue #1191. Previously, a few parts of the Include matcher assumed all Ranges were iterable. This caused it to raise errors like: TypeError: Can't iterate from [Float|Time] This happens because Ranges require that their beginning element implement succ. Float doesn't which causes the error. Time is different because it does implement succ but a) it's deprecated as of Ruby 1.9.2 and b) some Ruby implementations raise an exception when trying to iterate through a range of Time objects. This PR does a few things: 1) Fixes the Include matcher to handle Ranges that don't support iteration, while continuing to support Ranges that do 2) Adds specs for both types of Ranges in 1). There weren't any for the Include matcher used with Ranges.
b070eb9
to
e61ca2b
Compare
5dc0c99
to
211e733
Compare
This has been migrated to the monorepo, given that the blockers were largely legacy rubys that RSpec 4 won't support I hope to merge this in relatively quickly, sorry it got forgotten about |
This PR addresses issue rspec/rspec#138 for ruby >= 2.1.9.
Previously, a few parts of the
Include
matcher assumed allRange
s were iterable. This caused it to raise errors likeTypeError: Can't iterate from [Float|Time]
This happens because
Range
s require that their beginning element implementsucc
.Float
doesn't, which causes the error.Time
is different because it does implementsucc
buta)
Range#succ
is deprecated as of ruby 1.9.2 andb) Some Ruby implementations raise an exception when trying to iterate through a range of
Time
objectsThis PR does a few things:
Include
matcher to handleRange
s that don't support iteration, while continuing to supportRange
s that doRange
s in 1). There weren't any for theInclude
matcher used withRange
s.