Refs #36485 -- Removed unnecessary parentheses in :meth: and :func: roles in docs.

docs/ref/forms/api.txt

@@ -157,7 +157,7 @@ instances.
 Use this method anytime you need to identify an error by its ``code``. This
 enables things like rewriting the error's message or writing custom logic in a
 view when a given error is present. It can also be used to serialize the errors
-in a custom format (e.g. XML); for instance, :meth:`~Form.errors.as_json()`
+in a custom format (e.g. XML); for instance, :meth:`~Form.errors.as_json`
 relies on ``as_data()``.
 
 The need for the ``as_data()`` method is due to backwards compatibility.
@@ -193,11 +193,11 @@ directly in HTML.
 .. method:: Form.errors.get_json_data(escape_html=False)
 
 Returns the errors as a dictionary suitable for serializing to JSON.
-:meth:`Form.errors.as_json()` returns serialized JSON, while this returns the
+:meth:`Form.errors.as_json` returns serialized JSON, while this returns the
 error data before it's serialized.
 
 The ``escape_html`` parameter behaves as described in
-:meth:`Form.errors.as_json()`.
+:meth:`Form.errors.as_json`.
 
 .. method:: Form.add_error(field, error)
 
@@ -298,8 +298,8 @@ Returns the initial data for a form field. It retrieves the data from
 Callable values are evaluated.
 
 It is recommended to use :attr:`BoundField.initial` over
-:meth:`~Form.get_initial_for_field()` because ``BoundField.initial`` has a
-simpler interface. Also, unlike :meth:`~Form.get_initial_for_field()`,
+:meth:`~Form.get_initial_for_field` because ``BoundField.initial`` has a
+simpler interface. Also, unlike :meth:`~Form.get_initial_for_field`,
 :attr:`BoundField.initial` caches its values. This is useful especially when
 dealing with callables whose return values can change (e.g. ``datetime.now`` or
 ``uuid.uuid4``):
@@ -1315,7 +1315,7 @@ Attributes of ``BoundField``
         datetime.datetime(2021, 7, 27, 9, 5, 54)
 
     Using :attr:`BoundField.initial` is recommended over
-    :meth:`~Form.get_initial_for_field()`.
+    :meth:`~Form.get_initial_for_field`.
 
 .. attribute:: BoundField.is_hidden
 
@@ -1517,7 +1517,7 @@ If not defined as a class variable, ``bound_field_class`` can be set via the
 constructor.
 
 For compatibility reasons, a custom form field can still override
-:meth:`.Field.get_bound_field()` to use a custom class, though any of the
+:meth:`.Field.get_bound_field` to use a custom class, though any of the
 previous options are preferred.
 
 You may want to use a custom :class:`.BoundField` if you need to access some

docs/ref/forms/fields.txt

@@ -414,7 +414,7 @@ Checking if the field data has changed
 The ``has_changed()`` method is used to determine if the field value has changed
 from the initial value. Returns ``True`` or ``False``.
 
-See the :class:`Form.has_changed()` documentation for more information.
+See the :class:`Form.has_changed` documentation for more information.
 
 .. _built-in-fields:
 
@@ -1631,7 +1631,7 @@ only requirements are that it implement a ``clean()`` method and that its
 
 You can also customize how a field will be accessed by overriding
 :attr:`~django.forms.Field.bound_field_class` or override
-:meth:`.Field.get_bound_field()` if you need more flexibility when creating
+:meth:`.Field.get_bound_field` if you need more flexibility when creating
 the ``BoundField``:
 
 .. method:: Field.get_bound_field(form, field_name)

docs/ref/forms/validation.txt

@@ -83,12 +83,12 @@ overridden:
   called, you also have access to the form's ``errors`` attribute which
   contains all the errors raised by cleaning of individual fields.
 
-  Note that any errors raised by your :meth:`Form.clean()` override will not
+  Note that any errors raised by your :meth:`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
   :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()`.
+  :meth:`~django.forms.Form.add_error`.
 
   Also note that there are special considerations when overriding
   the ``clean()`` method of a ``ModelForm`` subclass. (see the
@@ -99,7 +99,7 @@ These methods are run in the order given above, one field at a time. That is,
 for each field in the form (in the order they are declared in the form
 definition), the ``Field.clean()`` method (or its override) is run, then
 ``clean_<fieldname>()``. Finally, once those two methods are run for every
-field, the :meth:`Form.clean()` method, or its override, is executed whether
+field, the :meth:`Form.clean` method, or its override, is executed whether
 or not the previous methods have raised errors.
 
 Examples of each of these methods are provided below.
@@ -335,7 +335,7 @@ Cleaning and validating fields that depend on each other
 Suppose we add another requirement to our contact form: if the ``cc_myself``
 field is ``True``, the ``subject`` must contain the word ``"help"``. We are
 performing validation on more than one field at a time, so the form's
-:meth:`~Form.clean()` method is a good spot to do this. Notice that we are
+:meth:`~Form.clean` method is a good spot to do this. Notice that we are
 talking about the ``clean()`` method on the form here, whereas earlier we were
 writing a ``clean()`` method on a field. It's important to keep the field and
 form difference clear when working out where to validate things. Fields are

docs/ref/forms/widgets.txt

@@ -226,7 +226,7 @@ foundation for custom widgets.
 
     This abstract class cannot be rendered, but provides the basic attribute
     :attr:`~Widget.attrs`. You may also implement or override the
-    :meth:`~Widget.render()` method on custom widgets.
+    :meth:`~Widget.render` method on custom widgets.
 
     .. attribute:: Widget.attrs