The Logger severity predicates have existed since the [introduction of
Logger][1]. However, these methods only looked at the `level` instance
variable, so they did not work with the [thread safe implementation][2]
of temporary log levels in Rails.
Since then, the Logger severity predicates were [updated][3] to use the
`level` method instead of the instance variable, making Rails' severity
predicate overrides obsolete.
This commit removes Rails' custom severity predicates in favor of
Logger's implementation, since the new implementation was released in
Logger 1.4.2 and came bundled with Ruby 2.7.0.
[1]: ruby/logger@525b58d97e
[2]: rails/rails@629efb6057
[3]: ruby/logger@7365c995bf
Some of them can be a bit costly to generate, particularly
when inspecting very large objects or when accessing the AST
of procs.
Minitest supports passing the message as a callable, which allow
us to defer all these computations.
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.
Fix: #52111
Fix: 5dbc7b4
The above commit caused the size of the `CodeGenerator` method cache
to explode, because the dynamic namespace is way too granular.
But there is actually a much better fix for that, since `alias_attribute`
is now generating exactly the same code as the attribute it's aliasing,
we can generated it as the canonical method in the cache, and then just
define it in the model as the aliased name.
This prevent the cache from growing a lot, and even reduce memory
usage further as the original attribute and its alias now share
the same method cache.
The documentation on ActiveSupport::MessageVerifier used the “sensitive data” string as an example; that wording might induce the developer to think we’re dealing with encryption, while the payload is actually only Base64 encoded and is not protected at all.
We also improve the documentation on ActiveRecord::SignedId, which uses MessageVerifier and thereby will also expose the ID as encoded cleartext, making explicit that it’s not encryption, only signing.
Lastly, we refer the developer to MessageEncryptor if the payload needs to be encrypted.
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.
Previously if `assert_difference` called with a proc fails, the inspect
output of the proc object was shown. This is not helpful to identify
what went wrong.
With this commit we leverage the experimental
`RubyVM::AbstractSyntaxTree` api of MRI to print the source code of the
proc that was passed to `assert_difference`. On all other platforms the
behavior stays the same.
The same applies to `assert_changes`.
As of Ruby 2.6, ::Time supports rich timezone objects and expects them
to follow a similar API to tzinfo. Mostly we already do this with
ActiveSupport::TimeZone, delegating to the underlying tzinfo object,
except we were missing the API to display the timezone's name.
Calling strftime with "%Z" will try the following on the timezone:
* zone.abbr(time)
* zone.strftime("%Z", time)
* zone.name
Because we only implemented name, a ::Time created with an
ActiveSupport::TimeZone would "abbreviate" awkwardly to the full tz
identifier (like "12:34:00 America/Vancouver" instead of "12:34:00
PDT"). This commit implements abbr to make these Times format the same
way as TimeWithZone.
Co-authored-by: Jason Kim <jasonkim@github.com>
This is getting the same treatment as `base64`, `mutex_m`, etc.
In Ruby 3.4 it will start to warn: d7e558e3c4
Remoce require from two files that don't seem to need it
This will avoid a warning about circular dependencies.
/circular require considered harmful.*rails-html-sanitizer/
This happens because `rails-html-sanitizer` requires `action_view/helpers`
that requires `action_view/helpers/sanitize_helper` that requires
`rails-html-sanitizer`.
I'll properly fix this in rails-html-sanitizer later removing the code
that needs to be added to ActionView::Helpers in that gem.
The usage of `dispatch` in all logging methods causes common usages such
as `logger.info` to return an array of loggers, making it unsafe for an
application to upgrade to Rails 7.1.
Returning `nil` is more efficient, and is the default behavior when
using `Logger`.
The usage of `dispatch` in all logging methods causes common usages such
as `logger.info` to return an array of loggers, making it unsafe for an
application to upgrade to Rails 7.1.
Returning `nil` is more efficient, and is the default behavior when
using `Logger`.
It has to be reverted because the previous implementation wasn't
cgroup aware so it would often start way too many processes on various
shared hosting platforms.
Thanks to https://github.com/ruby-concurrency/concurrent-ruby/pull/1038
concurrent-ruby 1.3 now offer a cgroups aware method to detect how
many processors we can actually use.
* Change asset pipeline default to Propshaft
* Use :all for stylesheets when propshaft is active
* Switch to using propshaft as the default (still need to find a way to tests against sprockets too)
* Fix tests that rely on sprockets being used
* Fix Propshaft tests (#51913)
* Update railties/test/generators/shared_generator_tests.rb
Co-authored-by: Lázaro Nixon <lazaronixon@hotmail.com>
---------
Co-authored-by: Lázaro Nixon <lazaronixon@hotmail.com>
Allocations count is often an interesting proxy for performance,
but not necessarily the most relevant thing to include in request
logs, given they aren't a per thread metric, so the reporting
is widely innacurate in multi-threaded environments.
Since Ruby 3.1 there is now `GC.total_time` which is a monotonically
increasing counter of time spent in GC. It still isn't really a per
thread metric, but is is more interesting because it uses the same
unit as the response time, allowing to better see when you have a GC
pause performance issue.
