Exclude missing marshal_dump and _dump methods from being delegated to
an object's delegation target via the delegate_missing_to extension.
This avoids unintentionally adding instance variables to an object
during marshallization, should the delegation target be a method which
would otherwise add them.

In current versions of Ruby, a bug exists in the way objects are
marshalled, allowing for instance variables to be added or removed
during marshallization (see https://bugs.ruby-lang.org/issues/15968).
This results in a corrupted serialized byte stream, causing an object's
instance variables to "leak" into subsequent serialized objects during
demarshallization.

In Rails, this behavior may be triggered when marshalling an object that
uses the delegate_missing_to extension, if the delegation target is a
method which adds or removes instance variables to an object being
marshalled - when calling Marshal.dump(object), Ruby's built in behavior
will check whether the object responds to :marshal_dump or :_dump, which
in turn triggers the delegation target method in the
responds_to_missing? function defined in
activesupport/lib/active_support/core_ext/module/delegation.rb

While future versions of Ruby will resolve this bug by raising a
RuntimeError, the underlying cause of this error may not be readily
apparent when encountered by Rails developers. By excluding marshal_dump
and _dump from being delegated to an object's target, this commit
eliminates a potential cause of unexpected behavior and/or
RuntimeErrors.

Fixes #36522

Remove dead code in duplicable.rb

Delete method definition in rails that is compatible with ruby defini…

* Add test asserting truncate returns unfrozen string

* Ensure strings returned from truncate are not frozen

This fixes an issue where strings too short to be truncated were
returned unfrozen, where as long-enough strings were returned
frozen. Now retuned strings will not be frozen whether or not
the string returned was shortened.

* Update changelog w/ new truncate behavior description

[Jordan Thomas + Rafael Mendonça França]

Before:
```ruby
(1..10).cover?(1...11) => false
```

After:
```ruby
(1..10).cover?(1...11) => true
```

See https://git.io/fjTtz for the commit against Ruby core that added
support for Range arguments, with similar handling of this case.

In #10634 the behavior of Time#advance was changed to maintain a
proleptic gregorian calendar for dates before calendar reform. However
it didn't full address dates a long time before calendar reform and
they gradually drift away from the proleptic calendar the further you
go back in time. Fix this by always converting the date to gregorian
before calling advance which sets the reform date to -infinity.

Also add tests for parametrize and transliterate

Accommodate case-insensitive filesystems and database collations.

Rails 6 requires Ruby 2.5, which introduces `FrozenError`
https://docs.ruby-lang.org/en/2.5.0/NEWS.html

Related to #31520

See https://travis-ci.org/rails/rails/jobs/470890129#L2361

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.

- Fix a few deprecation warnings
- Remove testing of `Hash#slice`
- Imporve test of `Hash#slice!`
- Remove mention about `Hash#slice` from the guide

Follow up #34761.

Since Rails 6 requires Ruby 2.5.

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

Follow up #34754.

- Adding a Float as a duration to a datetime would result in the Float
  being rounded. Doing something like would have no effect because the
  0.45 seconds would be rounded to 0 second.

  ```ruby
    time = DateTime.parse("2018-1-1")
    time += 0.45.seconds
  ```

  This behavior was intentionally added a very long time ago, the
  reason was because Ruby 1.8 was using `Integer#gcd` in the
  constructor of Rational which didn't accept a float value.

  That's no longer the case and doing `Rational(0.45, 86400)` would
  now perfectly work fine.

- Fixes #34008

Since Rails 6.0 will support Ruby 2.4.1 or higher
`# frozen_string_literal: true` magic comment is enough to make string object frozen.
This magic comment is enabled by `Style/FrozenStringLiteralComment` cop.

* Exclude these files not to auto correct false positive `Regexp#freeze`
 - 'actionpack/lib/action_dispatch/journey/router/utils.rb'
 - 'activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb'

It has been fixed by https://github.com/rubocop-hq/rubocop/pull/6333
Once the newer version of RuboCop released and available at Code Climate these exclude entries should be removed.

* Replace `String#freeze` with `String#-@` manually if explicit frozen string objects are required

 - 'actionpack/test/controller/test_case_test.rb'
 - 'activemodel/test/cases/type/string_test.rb'
 - 'activesupport/lib/active_support/core_ext/string/strip.rb'
 - 'activesupport/test/core_ext/string_ext_test.rb'
 - 'railties/test/generators/actions_test.rb'

[Gannon McGibbon + Eric Turner]

* Handle more unsafe String methods

* Fix codeclimate issue

* Revert stylistic change

[Janosch Müller + Rafael Mendonça França]

In Ruby 2.3 or later, `String#+@` is available and `+@` is faster than `dup`.

```ruby
# frozen_string_literal: true

require "bundler/inline"

gemfile(true) do
  source "https://rubygems.org"

  gem "benchmark-ips"
end

Benchmark.ips do |x|
  x.report('+@') { +"" }
  x.report('dup') { "".dup }
  x.compare!
end
```

```
$ ruby -v benchmark.rb
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]
Warming up --------------------------------------
                  +@   282.289k i/100ms
                 dup   187.638k i/100ms
Calculating -------------------------------------
                  +@      6.775M (± 3.6%) i/s -     33.875M in   5.006253s
                 dup      3.320M (± 2.2%) i/s -     16.700M in   5.032125s

Comparison:
                  +@:  6775299.3 i/s
                 dup:  3320400.7 i/s - 2.04x  slower

```

The method removes and returns the elements for which the block returns a true value.
If no block is given, an Enumerator is returned instead.

```
numbers = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
odd_numbers = numbers.extract! { |number| number.odd? } # => [1, 3, 5, 7, 9]
numbers # => [0, 2, 4, 6, 8]
```

- There was an issue inside controller tests where order params were not respected, the reason
  was because we were calling `Hash#to_query` which sorts the results lexicographically.
  1e4e1b62 fixed that issue by not using `to_query` but instead a utility function provided by rack.
- However with the fix came another issue where it's now no longer possible to do this

  ```
   post :foo, params: { user: User.first }

   # Prior to the patch the controller will receive { "user" => "1" }
   # Whereas now you get { "user": "#<User: ...>" }
  ```

  The fix in this PR is to modify `Hash#to_query` to sort only when it
  doesn't contain an array structure that looks something like "bar[]"

  Ref https://github.com/rails/rails/pull/33341#issuecomment-404039396

When multiplying or dividing a duration by a scalar, it's tempting to
operate directly on the duration's value in seconds and recompute the
parts from the result. However this loses information, as there are
multiple combinations of parts that map to any given number of seconds
(e.g. `2.weeks` or `336.hours`). This is especially problematic when
dealing with durations on the scale of months or years, as converting an
exact number of seconds to one of those intervals and then using the
resulting duration to modify a date will give the wrong result.

In the app I'm working on I've wished that index_by had a buddy that would
assign the hash value instead of the key multiple times.

Enter index_with. Useful when building a hash from a static list of
symbols. Before you'd do:

```ruby
POST_ATTRIBUTES.map { |attr_name| [ attr_name, public_send(attr_name) ] }.to_h
```

But now that's a little clearer and faster with:

````ruby
POST_ATTRIBUTES.index_with { |attr_name| public_send(attr_name) }
```

It's also useful when you have an enumerable that should be converted to a hash,
but you don't want to muddle the code up with the overhead that it takes to create
that hash. So before, that's:

```ruby
WEEKDAYS.each_with_object(Hash.new) do |day, intervals|
  intervals[day] = [ Interval.all_day ]
end
```

And now it's just:

```ruby
WEEKDAYS.index_with([ Interval.all_day ])
```

It's also nice to quickly get a hash with either nil, [], or {} as the value.

Follow up of #32605.

Follow up of #32034.

See #29632 for details. In short, it's possible to enter `LoadError#is_missing?` when `LoadError#path` returns `nil`, leading to `path.sub` throwing an none-to-helpful `NoMethodError`.

This tiniest of patch inserts `#to_s` before the `sub` call to make sure it succeeds. Affected surface area should be just as tiny since something has already gone wrong to get us into `#is_missing?` and the current behavior when `#path` returns `nil` seems clearly not intended.

[Gannon McGibbon + Neil Souza]

This autocorrects the violations after adding a custom cop in
3305c78dcd.