Follow-up to #50699.
This prevents a `NoMethodError` from being masked when the missing
method is itself named `render_in`.
Co-authored-by: Hartley McGuire <skipkayhil@gmail.com>
Follow-up to #50665.
Unconditionally converting `NoMethodError` to `ArgumentError` can mask a
legitimate `NoMethodError` from within the `render_in` method. This
commit adds a check to prevent that.
For example:
```ruby
delegate :negative?, to: :value, as: Numeric
```
Before:
```
def negative?(&block)
_ = @value
_.negative?(&block)
rescue NoMethodError => e
if _.nil? && e.name == :negative?
raise DelegationError, "ActiveSupport::Duration#negative? delegated to @value.negative?, but @value is nil: #{self.inspect}"
else
raise
end
end
```
After:
```ruby
def negative?(&block)
_ = @value
_.negative?(&block)
rescue NoMethodError => e
if _.nil? && e.name == :negative?
raise DelegationError.nil_target(:negative?, :"@value")
else
raise
end
end
```
Before almost every delegator would generate a large unique string that gets interned for
the error message that is rarely if ever used.
Rather than to "hardcode" a unique string, we now only pass pre-existing symbols to
a method helper that will build the error message.
This alone saves about 160B per delegator, and the method bytecode is also marginally
smaller (but it's harder to assess how much this actually saves)
The private `#assign_nested_parameter_attributes` was introduced in
[774ff18][] (Dec 15, 2011), moved to `ActiveRecord::AttributeAssignment`
in [ceb33f8][] (also Dec 15, 2011), then most recently modified in
[2606fb3][] (Jan 23, 2015) when `ActiveModel::AttributeAssignment` was
extracted.
Support for `accepts_nested_attributes_for` (introduced in [ec8f045][]
Feb 1, 2009) pre-dates those commits, and has evolved enough to cover
this behavior in other ways.
With its removal, Active Record's test suite still passes, so if it's a
crucial piece of code to retain, we should expand the suite to exercise
it.
[774ff18]: 774ff18c09
[ceb33f8]: ceb33f8493
[2606fb3]: 2606fb3397
[ec8f045]: ec8f045844
The main change is the default number of threads
is reduced from 5 to 3 as discussed in https://github.com/rails/rails/issues/50450
Pending a potential future "Rails tuning" guide, I tried
to include in comments the gist of the tradeoffs involved.
I also removed the pidfile except for development.
It's useful to prevent booting the server twice there
but I don't think it makes much sense in production,
especially [since Puma no longer supports daemonization
and instead recommend using a process
monitor](99f83c50fb/docs/deployment.md (should-i-daemonize)).
And it makes even less sense in a PaaS or containerized
world.
Replacing on the fly a `method_missing` by a generated method
sound like a nice trick, but it's not as good as it sound for
optimization, as the method will be generated by the first
request to use it, preventing the ISeq from being is shared memory.
Instead we can eagerly define a delegator when instance methods
are defined, and keep a regular `method_missing + send` for the
very rare cases not covered.
Co-Authored-By: Jean Boussier <jean.boussier@gmail.com>
Extend the `.attribute` class method to accept a `:default` option for
its list of attributes:
```ruby
class Current < ActiveSupport::CurrentAttributes
attribute :counter, default: 0
end
```
Internally, `ActiveSupport::CurrentAttributes` will maintain a
`.defaults` class attribute to determine default values during instance
initialization.
Support for the new `action_dispatch.show_exceptions` values was
introduced in [e28f147][]. Alongside the change to introduce new values
(like `:all`, `:rescuable`, `:none`), the default behavior was changed
for `Rails.env.test?`.
Prior to that commit, the `test` environment's default value was `false`
(introduced in [d898a4b][]) (which corresponds to the new `:none`
setting).
The new default behavior has some unintended negative side effects that
impact the feedback loop at the core of test-driven development.
When errors are rescued and transformed into HTML pages, the context of
the cause of failure is obscured by additional layers of information.
First, this commit adds more prominent entries to the Upgrading and
Configuring guides, as well as the 7.1 Release Notes to document the
details of the configuration and its new values.
Next, this commit adds more documentation around the change in default
behavior. To start, it mentions the new value in the sections for the
affected test types: Controller, Integration, and System.
[e28f147]: e28f147329
[d898a4b]: d898a4ba42
When calling `render` with a `:renderable` argument, ensure that the
object responds to `#render_in`. If it doesn't, raise an
`ArgumentError`.
This commit also adjusts the `ArgumentError` that when a `:partial`
argument isn't Active Model compatible. Prior to this commit, the
message used `:` as a prefix to `to_partial_path`. This commit replaces
that with a `#` prefix to denote that it's expected to be an instance
method on the object.
Previously, `parent` was added as one of the RESTRICTED_CLASS_METHODS as
part of a commit (94b7328b08) in 2014 that stopped Rails `enum`s from being
able to redefine important class methods.
At the time, Rails monkey-patched `Module` with a `parent` class method
that returned a module's containing module if it was nested.
However, in October 2020 (167b4153ca) in Rails 6.1, this method was
deprecated in favour of a renamed method `module_parent`. As such, the
`parent` method doesn't need to be a restricted class method any more.
Now that we require Ruby 3.1, we can assume `Process._fork` is
defined on MRI, hence we can trust that our decorator will
reliably detect forks so we no longer need to check the if
the pid changed in critical spots.
Dorian Marié