This is too much complexity for something low value. Let's just always
warn when a test doesn't have any assertions.
If people want to raise an error or ignore them, they can do so by
overriding `Warning.warn`.
rails/rails@76966f9 implemented configuration to report assertionless tests. But the configuration causes ActiveSupport::TestCase to be loaded too early in the boot process. It causes issues when other engines define load hooks on :active_support_test_case because they are run immediately. Instead, we should wrap the configuration in a load hook so it gets set at the appropriate time.
This Pull Request has been created because the documentation for `ActiveSupport::TimeWithZone#change` wasn't correct.
The behavior of `:hour` and `:min` is different from the example in the documentation.
I checked with Rails 7.1.3.2 and all digits after nano seconds are 0.
```ruby
t = Time.zone.now #=> Sat, 20 Apr 2024 14:55:55.688536000 JST +09:00
t.change(hour: 12) #=> Sat, 20 Apr 2024 12:00:00.000000000 JST +09:00
t.change(min: 30) #=> Sat, 20 Apr 2024 14:30:00.000000000 JST +09:00
```
Ref: https://bugs.ruby-lang.org/issues/15554
This new Ruby 3.4 warning is still being fined tuned to reduce false positives,
so we shouldn't fail builds on it just yet.
It however caught one mistake in the test suite which is valuable.
Fix: https://github.com/rails/rails/pull/51426#issuecomment-2042611790
`perform_later` is supposed to return the Job instance on success,
and `false` on error.
When the `enqueue` is automatically delayed, it's of course impossible
to predict if the actual queueing will succeed, but for backward compatibility
reasons, it's best to assume it will.
If necessary, you can hold onto the job instance and check for
`#successfully_enqueued?` after the transaction has completed.
On March 1, 2024, Kazakhstan (all parts) switched to use UTC+5. This
updates Astana (captital of Kazakhstan) to use a Western Kazakhstan
TZInfo identifier.
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!
Using ActiveSupport::LogSubscriber#color inside a custom log subscriber
causes NoMethodError.
```ruby
require "bundler/inline"
gemfile(true) do
source "https://rubygems.org"
gem "activesupport"
end
require "active_support"
class TestLogSubscriber < ActiveSupport::LogSubscriber
attach_to :test
def hi(event)
info(color(event.payload[:message], GREEN))
end
private
def log_exception(name, e)
super
raise e
end
end
ActiveSupport::LogSubscriber.logger = ActiveSupport::Logger.new(STDOUT)
ActiveSupport::Notifications.instrument("hi.test", message: "Hello!")
```
```
/rails/activesupport/lib/active_support/log_subscriber.rb:193:in `mode_from': undefined method `compact_blank' for an instance of Hash (NoMethodError)
modes = MODES.values_at(*options.compact_blank.keys)
^^^^^^^^^^^^^^
```
For what it's worth, I have encountered this while using kredis locally, like;
```
$ cd kredis
$ bin/console
irb(main):001> Kredis.string "mystring"
Could not log "meta.kredis" event. NoMethodError: undefined method `compact_blank' for an instance of Hash
```
Fixed incorrect documentation for `ActiveSupport::Logger.logger_outputs_to?`. The method expects the first argument to be a Logger object and subsequent variadic arguments to be either IO objects or strings representing file paths.
Also corrected the sample code in CHANGELOG.md, which previously only passed a single argument, not reflecting the correct usage.
related PR: https://github.com/rails/rails/pull/51125
The original example has race condition issue that the output of the example isn't conistent, see https://github.com/rails/rails/issues/43588.
The change improves the example by removing unnecessary thread and add detailed comments.
In the new example, there will be race condition only if `ActiveSupport::Cache::MemoryStore` took longer than 0.1 second to extend expiry but that's unlikely to happen.
Close#43588