At one point (I believe until ruby-1.8.0) Time could only represent
values between 1970 and the integer overflow in 2038. On modern Ruby
there does not seem to be a limit.
>> Time.at(2**128)
=> 10783118943836478994022445751222-08-06 01:04:16 -0700
TimeWithZone will also convert a DateTime to a Time when initialized
with one, so the code we had to catch this overflow and to deal with
DateTime is dead. This commit removes this code and adjusts the test to
be more general (the old test passed but we might as well keep a better
version of the test to check that we have a large both negative and
positive range).
Co-authored-by: Adam Hess <HParker@github.com>
We're more likely to already have utc and can avoid constructing the
extra time object, and this will avoid deprecations on unconfigured
to_time_preserves_timezone.
If the value is already a local time, there's no difference, so no need
to warn.
Correspondingly, avoid calling to_time in the handful of places we were
using it internally: it's easy to do, and we know we don't care about
the zone.
String.new with no arguments returns the empty string with ASCII-8BIT
encoding. Then, depending on each grapheme cluster of the string and
on the omission string, the resulting string might keep the ASCII-8BIT
encoding. With this change, we preserve the encoding of the original
string instead.
Note that String.new accepts an `encoding` keyword argument, like
```
String.new(encoding: Encoding::UTF_8)
```
However, instead of using that, we rely on `force_encoding` to set the
original encoding. This is so that String subclasses don't need to
preserve this keyword argument. For example, SafeBuffer doesn't.
Thanks to @jeremy for catching this!
This commit addresses CI failure
at https://buildkite.com/rails/rails-nightly/builds/108#018d57ac-4f2a-45f1-86b9-9015a7b0a463/1165-2002
* Error addressed by this commit
```
$ ruby -v
ruby 3.4.0dev (2024-01-30T10:19:23Z master 86547fd69d) [x86_64-linux]
$ rm Gemfile.lock
$ bundle install
$ cd activesupport
$ bin/test test/core_ext/object/to_query_test.rb -n test_hash_not_sorted_lexicographically_for_nested_structure
... snip ...
E
Error:
ToQueryTest#test_hash_not_sorted_lexicographically_for_nested_structure:
NameError: uninitialized constant ToQueryTest::URI
test/core_ext/object/to_query_test.rb:90:in `test_hash_not_sorted_lexicographically_for_nested_structure'
bin/test test/core_ext/object/to_query_test.rb:79
Finished in 0.000385s, 2597.3082 runs/s, 0.0000 assertions/s.
1 runs, 0 assertions, 0 failures, 1 errors, 0 skips
$
```
This behavior has been introduced since Ruby 3.4.0dev vendors URI from top level to `Gem::URI`
via d64d0b5423 .
Here is the RubyGems one.
https://github.com/rubygems/rubygems/pull/7386
The introduction of the block argument means that `Object#with` can now
accept a `Symbol#to_proc` as the block argument:
```ruby
client.with(timeout: 5_000) do |c|
c.get("/commits")
end
```
This is a continuation of https://github.com/rails/rails/pull/46875
The behavior of looking up the class method when `to: :class` is passed
is a bit error prone because it silently degrades.
By passing the expected owner of the delegated method, we can be more
strict, and also generate a delegator in a module rather than having
to do it at inclusion time.
I made this argument private API because we want it in Rails, but
I'm worried it might be a bit too sharp for public API. I can
be convinced otherwise though.
The `@` prefix is always stripped, so might as well not require it.
For backward compatibility reasons we still handle the prefix for now,
but we eagerly strip it and emit a deprecation.
Prior to this commit, `String#downcase_first` and `String#upcase_first`
would return a frozen string when called on an empty string:
```ruby
# BEFORE
"foo".downcase_first.frozen? # => false
"".downcase_first.frozen? # => true
# AFTER
"foo".downcase_first.frozen? # => false
"".downcase_first.frozen? # => false
```
`with_test.rb` should define a class named `WithTest`. Instead, it
redefines `BlankTest`. This seems to be a copy/paste typo.
This commit renames `BlankTest` to `WithTest` to follow convention, and
to avoid any potential conflicts of 2 test files defining the same
class.
Previously, #overlap? would incorrectly return true when one of the
ranges is effectively "empty":
```ruby
(2...2).overlap? 1..2 # => true
(1..2).overlap? 2...2 # => true
```
This is fixed in the Ruby 3.3 implementation of Range#overlap?, so this
commit fixes it for Ruby < 3.3 as well.
The tests added are from the Ruby repository and the implementation is
effectively a Ruby version of the fix in C.
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
Co-authored-by: Shouichi Kamiya <shouichi.kamiya@gmail.com>
There are assertions that expected/actual arguments are passed in the
reversed order by mistake. Enabling the LiteralAsActualArgument rule
prevents this mistake from happening.
The existing tests were auto-corrected by rubocop with a bit of
indentation adjustment.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
The previous examples were causing failures in CI, after ruby/bigdecimal#264 was merged.
For example:
```
Failure:
NumericExtFormattingTest#test_default_to_fs [/rails/activesupport/test/core_ext/numeric_ext_test.rb:446]:
--- expected
+++ actual
@@ -1 +1,3 @@
-"10000 10.0"
+# encoding: US-ASCII
+# valid: true
+"10 00010.0"
```
The recommendation was to adjust the test to deal with the upstream change more flexibly.
This changed `many?` to yield with `element, *args`. The causes elements that are arrays to be destructured which can lead to defective behaviour. Since the introduction of `element, *args` was for readability purposes, we can just use `*args` instead and get the same behaviour without the defect.
`assert_raises` has been extended with a `match:` keyword argument to
assert the error message so there is no reason for Rails itself to keep
maintaining custom implementations of the same feature.
When 8b2f57dc6f was
introduced it broke delegation of a method with implicit block like this:
```ruby
class Foo
def self.bar
yield
end
end
class Bar
delegate :bar, to: Foo
end
Bar.new.bar { } # raises LocalJumpError: no block given (yield)
```
It happens because it's impossible to detect a method with implicit block and
we rely on method's parameters when we generate delegated methods.
I've found only one solution to this issue: we always generate a method that explicitly accepts
block. It kind of makes sense since evey Ruby method accepts block implicitly anyway.
Fixes https://github.com/rails/rails/issues/47624
