The delegation methods to named scope are defined when `method_missing`
is invoked on the relation.

Since #29301, the receiver in the named scope is changed to the relation
like others (e.g. `default_scope`, etc) for consistency.

Most named scopes would be delegated from relation by `method_missing`,
since we don't allow scopes to be defined which conflict with instance
methods on `Relation` (#31179). But if a named scope is defined with the
same name as any method on the `superclass` (e.g. `Kernel.open`), the
`method_missing` on the relation is not invoked.

To address the issue, make the delegation methods to named scope is
generated in the definition time.

Fixes #34098.

`scoping` stashes the reciever and then returning that as `klass.all`.
`all.scoping` has no effect to the public behavior, so it is redundant.

The receiver in a scope was changed from `klass` to `relation` itself
for all scopes (named scope, default_scope, and association scope)
behaves consistently.

In addition. Before 5.2, if both an AR model class and a Relation
instance have same named methods (e.g. `arel_attribute`,
`predicate_builder`, etc), named scope doesn't respect relation instance
information.

For example:

```ruby
class Post < ActiveRecord::Base
  has_many :comments1, class_name: "RecentComment1"
  has_many :comments2, class_name: "RecentComment2"
end

class RecentComment1 < ActiveRecord::Base
  self.table_name = "comments"
  default_scope { where(arel_attribute(:created_at).gteq(2.weeks.ago)) }
end

class RecentComment2 < ActiveRecord::Base
  self.table_name = "comments"
  default_scope { recent_updated }
  scope :recent_updated, -> { where(arel_attribute(:updated_at).gteq(2.weeks.ago)) }
end
```

If eager loading `Post.eager_load(:comments1, :comments2).to_a`,
`:comments1` (default_scope) respects aliased table name, but
`:comments2` (using named scope) may not work correctly since named
scope doesn't respect relation instance information. See also 801ccab2.

But this is a breaking change between releases without deprecation.
I decided to bring back private class methods accessibility in named
scope.

Fixes #31740.
Fixes #32331.

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.

A relation includes `klass`, so it can not be used as it is if current
class is different from `current_scope.klass`. It should be created new
relation by current class to respect the klass and STI constraint.

Fixes #17603.
Fixes #23576.

Follow up of #29834.

Fixes #30266.

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

Currently the receiver in a scope is `klass`, not `relation`.
I think it is a strange because the receiver in `default_scope` and a
scope on association is `relation`.
I fixed to the receiver is to be a `relation` properly for consistency.

As @matthewd's suggestion, if `klass` has no default scope, it will more
faster.

Some methods were added to public API in
5b14129d and they should be not part of
the public API.

Mainly around `nil`

[ci skip]

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

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.

The focus of this change is to make the API more accessible.
References to method and classes should be linked to make it easy to
navigate around.

This patch makes exzessiv use of `rdoc-ref:` to provide more readable
docs. This makes it possible to document `ActiveRecord::Base#save` even
though the method is within a separate module
`ActiveRecord::Persistence`. The goal here is to bring the API closer to
the actual code that you would write.

This commit only deals with Active Record. The other gems will be
updated accordingly but in different commits. The pass through Active
Record is not completely finished yet. A follow up commit will change
the spots I haven't yet had the time to update.

/cc @fxn

Adds a paragraph to the documentation of the `ActiveRecord::Scoping::Named.scope` method,
explaining that the method is intended to return an ActiveRecord::Relation object to be
composable with other scopes.

In the case that in the case that `nil` or `false` are returned, the method returns
an `all` relation instead.
This unexpected behaviour is mentioned in #19249 #14256 #21465 and #21882 and wasn't
documented at all. This commit adds this documentation.

Instead use .scope_attributes? consistently in ActiveRecord to check whether
there are attributes currently associated with the scope.

Move the implementation of .scope_attributes? and .scope_attributes to
ActiveRecord::Scoping because they don't particularly have to do specifically
with Named scopes and their only dependency, in the case of
.scope_attributes?, and only caller, in the case of .scope_attributes is
contained in Scoping.

It looks like the only reason `current_scope` was thread local on
`base_class` instead of `self` is to ensure that when we call a named
scope created with a proc on the parent class, it correctly uses the
default scope of the subclass. The reason this wasn't happening was
because the proc captured `self` as the parent class, and we're not
actually defining a real method. Using `instance_exec` fixes the
problem.

Fixes #18806

Relation#merge checks if the argument is an array and the only possible
returns of build_default_scope is nil or a Relation.

Doing this we can raise an ArgumentError when Relation#merge receive a
nil value.

This changes the actual exception `NoMethodError: undefined method `call'
for #<ActiveRecord::Relation []>` to a `ArgumentError` when try to define
a scope without a callable.

This reverts commit 9a1abedc, reversing
changes made to c72d6c91.

Conflicts:
	activerecord/CHANGELOG.md
	activerecord/test/models/comment.rb

This change break integration with activerecord-deprecated_finders so
I'm reverting until we find a way to make it work with this gem.

Changed the call to a scope block to be evaluated with instance_eval.
The result is that ScopeRegistry can use the actual class instead of base_class when
caching scopes so queries made by classes with a common ancestor won't leak scopes.

Similar to dangerous attribute methods, a scope name conflict is
dangerous if it conflicts with an existing class method defined within
`ActiveRecord::Base` but not its ancestors.

See also #13389.

*Godfrey Chan*, *Philippe Creux*

The deprecation message was removed on 50cbc03d but the code was not.

Removed tests from deprecated code.

The previous implementation was necessary in order to support stuff
like:

    class Post < ActiveRecord::Base
      default_scope where(published: true)
      scope :ordered, order("created_at")
    end

If we didn't evaluate the default scope at the last possible moment
before sending the SQL to the database, it would become impossible to
do:

    Post.unscoped.ordered

This is because the default scope would already be bound up in the
"ordered" scope, and therefore wouldn't be removed by the
"Post.unscoped" part.

In 4.0, we have deprecated all "eager" forms of scopes. So now you must
write:

    class Post < ActiveRecord::Base
      default_scope { where(published: true) }
      scope :ordered, -> { order("created_at") }
    end

This prevents the default scope getting bound up inside the "ordered"
scope, which means we can now have a simpler/better/more natural
implementation of default scoping.

A knock on effect is that some things that didn't work properly now do.
For example it was previously impossible to use #except to remove a part
of the default scope, since the default scope was evaluated after the
call to #except.

See #9869 and #9929.

The problem arises from the following example:

    class Project < ActiveRecord::Base
      scope :completed, -> { where completed: true }
    end

    class MajorProject < Project
    end

When calling:

    MajorProject.where(tasks_count: 10).completed

This expands to:

    MajorProject.where(tasks_count: 10).scoping {
      MajorProject.completed
    }

However the lambda for the `completed` scope is defined on Project. This
means that when it is called, `self` is Project rather than
MajorProject. So it expands to:

    MajorProject.where(tasks_count: 10).scoping {
      Project.where(completed: true)
    }

Since the scoping was applied on MajorProject, and not Project, this
fails to apply the tasks_count condition.

The solution is to make scoping apply across STI classes. I am slightly
concerned about the possible side-effects of this, but no tests fail and
it seems ok. I guess we'll see.

Introduced in f1082b85.
Full changelog in 9f007d7f.

[ci skip]

Currently Post.active.inactive will result in Post.inactive since
the last where clause wins when scopes are merged.

This pull request will merge all scopes ( barring defaul scope)
using AND.

The default scope will be overridden if another scope acts on the
same where clause.

closes #7365

Closes #8804 [ci skip]

Sometimes, on Mac OS X, programmers accidentally press Option+Space
rather than just Space and don’t see the difference. The problem is
that Option+Space writes a non-breaking space (0XA0) rather than a
normal space (0x20).

This commit removes all the non-breaking spaces inadvertently
introduced in the comments of the code.