For now argument forwarding doesn't allow some keywords like `true` as a
method name.

To bypass the issue, fallback to `define_method` if method names are
Ruby reserved keywords.

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

```ruby
class Works
  def true(*args)
    puts(*args)
  end
end

Works.new.true 1, 2, 3
# => 1, 2, 3

class WontWork
  def true(...)
    puts(...)
  end
end
```

```
% ruby a.rb
a.rb:12: syntax error, unexpected ..., expecting ')'
  def true(...)
a.rb:13: unexpected ...
a.rb:15: syntax error, unexpected `end', expecting end-of-input
```

We fixed `generate_relation_method` to address kwargs warnings at
#38038, but I missed generated named scopes also need the same fix.

Test case has picked from #39196.
Co-authored-by: NJohn Hawthorn <john@hawthorn.email>

Positional hash argument should not be dup-ed.

This patch has two main portions:

1. Add SQL comment support to Arel via Arel::Nodes::Comment.
2. Implement a Relation#annotate method on top of that.

== Adding SQL comment support

Adds a new Arel::Nodes::Comment node that represents an optional SQL
comment and teachers the relevant visitors how to handle it.

Comment nodes may be added to the basic CRUD statement nodes and set
through any of the four (Select|Insert|Update|Delete)Manager objects.

For example:

    manager = Arel::UpdateManager.new
    manager.table table
    manager.comment("annotation")
    manager.to_sql # UPDATE "users" /* annotation */

This new node type will be used by ActiveRecord::Relation to enable
query annotation via SQL comments.

== Implementing the Relation#annotate method

Implements `ActiveRecord::Relation#annotate`, which accepts a comment
string that will be appeneded to any queries generated by the relation.

Some examples:

    relation = Post.where(id: 123).annotate("metadata string")
    relation.first
    # SELECT "posts".* FROM "posts" WHERE "posts"."id" = 123
    # LIMIT 1 /* metadata string */

    class Tag < ActiveRecord::Base
      scope :foo_annotated, -> { annotate("foo") }
    end
    Tag.foo_annotated.annotate("bar").first
    # SELECT "tags".* FROM "tags" LIMIT 1 /* foo */ /* bar */

Also wires up the plumbing so this works with `#update_all` and
`#delete_all` as well.

This feature is useful for instrumentation and general analysis of
queries generated at runtime.

This deprecates using class level querying methods if the receiver scope
regarded as leaked, since #32380 and #35186 may cause that silently
leaking information when people upgrade the app.

We need deprecation first before making those.

This reverts #32380, since this may cause that silently leaking
information when people upgrade the app.

We need deprecation first before making this.

Active Record uses `scoping` to delegate to named scopes from relations
for propagating the chaining source scope. It was needed to restore the
source scope in named scopes, but it was caused undesired behavior that
pollute all class level querying methods.

Example:

```ruby
class Topic < ActiveRecord::Base
  scope :toplevel, -> { where(parent_id: nil) }
  scope :children, -> { where.not(parent_id: nil) }
  scope :has_children, -> { where(id: Topic.children.select(:parent_id)) }
end

# Works as expected.
Topic.toplevel.where(id: Topic.children.select(:parent_id))

# Doesn't work due to leaking `toplevel` to `Topic.children`.
Topic.toplevel.has_children
```

Since #29301, the receiver in named scopes has changed from the model
class to the chaining source scope, so the polluting class level
querying methods is no longer required for that purpose.

Fixes #14003.

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

Due to inconsistent behavior when chaining scopes and one scope named after a Relation method

Validation code added in 2 places:

- scope, to prevent problematic scope names.
- enum, cause it tries to auto define scope.

https://travis-ci.org/rails/rails/jobs/263617099#L769-L775

This reverts commit 3420a145, reversing
changes made to afb66a5a.

Since b644964b `ActiveRecord::Relation` includes `Enumerable` so
delegating `collect`, `all?`, and `include?` are also unneeded.
`collect` without block returns `Enumerable` without preloading by that.
We should use `load` rather than `collect` for force loading.

assert [1, 3].includes?(2) fails with unhelpful "Asserting failed" message

assert_includes [1, 3], 2 fails with "Expected [1, 3] to include 2" which makes it easier to debug and more obvious what went wrong

Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces

Fix all violations in the repository.

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

Changing the order of method chaining `merge` and other query
method such as `joins` should produce the same result.

```ruby
class Topic < ApplicationRecord
  scope :safe_chaininig,   -> { joins(:comments).merge(Comment.newest) }
  scope :unsafe_chaininig, -> { merge(Comment.newest).joins(:comments) } #=> NoMethodError
end
```

[ci skip]

Unlike `one?` and `none?`, `empty?` has interactions with methods
outside of enumerable. It also doesn't fit in the same vein.
`Topic.any?` makes sense. `Topic.empty?` does not, as `Topic` is not a
container.

Fixes #24808
Close #24812

This reverts commit f6db31ec.

Reason:
Scope names can very easily conflict, particularly when sharing Concerns
within the team, or using multiple gems that extend AR models.

It is true that Ruby has the ability to detect this with the -w option, but the
reality is that we are depending on too many gems that do not care about Ruby
warnings, therefore it might not be a realistic solution to turn this switch on
in our real-world apps.