[1.7.x] Fixed #22216 -- Added Form.non_field_errors to form API doc.

Backport of d2f4553d from master

docs/ref/forms/api.txt

@@ -173,7 +173,8 @@ from a view.
 
 The ``field`` argument is the name of the field to which the errors
 should be added. If its value is ``None`` the error will be treated as
-a non-field error as returned by ``Form.non_field_errors()``.
+a non-field error as returned by :meth:`Form.non_field_errors()
+<django.forms.Form.non_field_errors>`.
 
 The ``error`` argument can be a simple string, or preferably an instance of
 ``ValidationError``. See :ref:`raising-validation-error` for best practices
@@ -182,6 +183,14 @@ when defining form errors.
 Note that ``Form.add_error()`` automatically removes the relevant field from
 ``cleaned_data``.
 
+.. method:: Form.non_field_errors()
+
+This method returns the list of errors from :attr:`Form.errors
+<django.forms.Form.errors>`  that aren't associated with a particular field.
+This includes ``ValidationError``\s that are raised in :meth:`Form.clean()
+<django.forms.Form.clean>` and errors added using :meth:`Form.add_error(None,
+"...") <django.forms.Form.add_error>`.
+
 Behavior of unbound forms
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 

docs/ref/forms/validation.txt

@@ -85,8 +85,8 @@ overridden:
   Note that any errors raised by your ``Form.clean()`` override will not
   be associated with any field in particular. They go into a special
   "field" (called ``__all__``), which you can access via the
-  ``non_field_errors()`` method if you need to. If you want to attach
-  errors to a specific field in the form, you need to call
+  :meth:`~django.forms.Form.non_field_errors` method if you need to. If you
+  want to attach errors to a specific field in the form, you need to call
   :meth:`~django.forms.Form.add_error()`.
 
   Also note that there are special considerations when overriding
@@ -331,7 +331,7 @@ form's ``clean()`` method, in which case you can use
 :meth:`~django.forms.Form.add_error()`. Note that this won't always be
 appropriate and the more typical situation is to raise a ``ValidationError``
 from , which is turned into a form-wide error that is available through the
-``Form.non_field_errors()`` method.
+:meth:`Form.non_field_errors() <django.forms.Form.non_field_errors>` method.
 
 Cleaning and validating fields that depend on each other
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

docs/topics/testing/tools.txt

@@ -1274,7 +1274,8 @@ your test suite.
 
     ``field`` is the name of the field on the form to check. If ``field``
     has a value of ``None``, non-field errors (errors you can access via
-    ``form.non_field_errors()``) will be checked.
+    :meth:`form.non_field_errors() <django.forms.Form.non_field_errors>`) will
+    be checked.
 
     ``errors`` is an error string, or a list of error strings, that are
     expected as a result of form validation.
@@ -1295,7 +1296,8 @@ your test suite.
 
     ``field`` is the name of the field on the form to check. If ``field``
     has a value of ``None``, non-field errors (errors you can access via
-    ``form.non_field_errors()``) will be checked.
+    :meth:`form.non_field_errors() <django.forms.Form.non_field_errors>`) will
+    be checked.
 
     ``errors`` is an error string, or a list of error strings, that are
     expected as a result of form validation.