This reverts commit 52fddcc6.

52fddcc6 was to short-circuit `ensure_in_range` in `cast_value`. But that
caused a regression for empty string deserialization.

Since 7c6f3938, `ensure_in_range` is moved into `serialize`. As 52fddcc6
said, the absolute gain is quite small. So I've reverted that commit to
fix the regression.

This is a follow-up of #35310.

Currently `Topic.find_by(id: "not-a-number")` matches to a `id = 0`
record. That is considered as silently leaking information.

If non numeric string is given to find by an integer column, it should
not be matched to any record.

Related #12793.

That is considered as silently leaking information.
If type casting doesn't return any actual value, it should not be
matched to any record.

Fixes #33624.
Closes #33946.

Since `serialize` is passed user input args (from `where`, schema
default, etc), a helper should provide `serialize` if the helper also
provide `cast`.

Related #32624, 34cc301f, a741208f.

`value_from_multiparameter_assignment` defined by
`AcceptsMultiparameterTime` helper requires `default_timezone` method
which is defined at `TimeValue` helper.
Since `Date` type doesn't include `TimeValue`, I've extracted `Timezone`
helper to be shared by `Date`, `DateTime`, and `Time` types.

In master, tests pass because `bigdecimal/util` requires in
`active_support/xml_mini`.
But test fails in 5-2-stable because that require does not exist.
Ref: https://travis-ci.org/rails/rails/jobs/484627996#L1969

- If you had a PORO that acted like a Numeric, the validator would
  work correctly because it was previously using `Kernel.Float`
  which is implicitely calling `to_f` on the passed argument.

  Since rails/rails@d126c0d , we are now using `BigDecimal` which does
  not implicitely call `to_f` on the argument, making the validator
  fail with an underlying `TypeError` exception.

  This patch replate the `is_decimal?` check with `Kernel.Float`.
  Using `Kernel.Float` as argument for the BigDecimal call has two
  advantages:

  1. It calls `to_f` implicetely for us.
  2. It's also smart enough to detect that `Kernel.Float("a")` isn't a
     Numeric and will raise an error.
     We don't need the `is_decimal?` check thanks to that.

  Passing `Float::DIG` as second argument to `BigDecimal` is mandatory
  because the precision can't be omitted when passing a Float.
  `Float::DIG` is what is used internally by ruby when calling
  `123.to_d`

  https://github.com/ruby/ruby/blob/trunk/ext/bigdecimal/lib/bigdecimal/util.rb#L47

- Another small issue introduced in https://github.com/rails/rails/pull/34693
  would now raise a TypeError because `Regexp#===` will just return
  false if the passed argument isn't a string or symbol, whereas
  `Regexp#match?` will.

When assigning a hash to a time attribute that's missing a year
component (e.g. a `time_select` with `:ignore_date` set to `true`)
then the year defaults to 1970 instead of the expected 2000. This
results in the attribute changing as a result of the save.

Before:

    event = Event.new(start_time: { 4 => 20, 5 => 30 })
    event.start_time # => 1970-01-01 20:30:00 UTC
    event.save
    event.reload
    event.start_time # => 2000-01-01 20:30:00 UTC

After:

    event = Event.new(start_time: { 4 => 20, 5 => 30 })
    event.start_time # => 2000-01-01 20:30:00 UTC
    event.save
    event.reload
    event.start_time # => 2000-01-01 20:30:00 UTC

This file uses assert_valid_keys but it was not being required. You can
reproduce this error with a script that uses this feature by using those
requires:

    require 'active_model'
    require 'active_model/callbacks'

I reverted the wrong commit. Damn it.

This reverts commit f66a977f.

We had a discussion on the Core team and we don't want to expose this information
as a JSON endpoint and not by default.

It doesn't make sense to expose this JSON locally and this controller is only
accessible in dev, so the proposed access from a production app seems off.

This reverts commit 8eaffe7e, reversing
changes made to b6e4305c.

Related to https://github.com/rails/rails/pull/34817#issuecomment-451508668

Currently we sometimes find a redundant begin block in code review
(e.g. https://github.com/rails/rails/pull/33604#discussion_r209784205).

I'd like to enable `Style/RedundantBegin` cop to avoid that, since
rescue/else/ensure are allowed inside do/end blocks in Ruby 2.5
(https://bugs.ruby-lang.org/issues/12906), so we'd probably meets with
that situation than before.

https://bugs.ruby-lang.org/issues/14132

https://bugs.ruby-lang.org/issues/14133

Since Rails 6 requires Ruby 2.5.

https://github.com/ruby/ruby/blob/ruby_2_5/NEWS

Follow up #34754.

Thanks to ko1, passing block parameter to another method is
significantly optimized in Ruby 2.5.
https://bugs.ruby-lang.org/issues/14045

Thus we no longer need to keep this ugly hack.

Generally followed the pattern for https://github.com/rails/rails/pull/32034

* Removes needless CI configs for 2.4
* Targets 2.5 in rubocop
* Updates existing CHANGELOG entries for fewer merge conflicts
* Removes Hash#slice extension as that's inlined on Ruby 2.5.
* Removes the need for send on define_method in MethodCallAssertions.

If a klass has acceptance validation and then
`klass.undefine_attribute_methods` is happened before an attribute
method is called, infinit loop is caused on the `method_missing` defined
by the `LazilyDefineAttributes`.

https://travis-ci.org/rails/rails/jobs/467053984#L1409

To prevent the infinit loop, the `method_missing` should ensure
`klass.define_attribute_methods`.

Closes #34530.

[ci skip]

Fixes #34416

Related 34cc301f.

`QueryAttribute#value_for_database` calls only `type.serialize`, and
`Decimal#serialize` is a no-op unlike other attribute types.

Whether or not `serialize` will invoke `cast` is undefined in our test
cases, but it actually does not work properly unless it does so for now.

Reword first sentence of dep management and CVE section of
security guide. Also, reword and move gemspec notes above deps.

[ci skip]

[ci skip]

Previosly, `update_columns` would just take whatever keys you gave it
and tried to run the update query. Most likely this would result in an
error from the database. However, if the column actually did exist, but
was in `ignored_columns`, this would result in the method returning
successfully when it should have raised, and an attribute that should
not exist written to `@attributes`.

See https://english.stackexchange.com/questions/23218/anyone-has-or-anyone-have-seen-them

Ruby uses the original method name, so will show the __temp__ method
name in the backtrace. However, in the common case the method name
is compatible with the `def` keyword, so we can avoid the __temp__
method name in that case to improve the name shown in backtraces
or TracePoint#method_id.