Link mentioned functions instead of using literals (#8045)

Author: timhoffm

doc/en/assert.rst

@@ -74,7 +74,7 @@ Assertions about expected exceptions
 ------------------------------------------
 
 In order to write assertions about raised exceptions, you can use
-``pytest.raises`` as a context manager like this:
+:func:`pytest.raises` as a context manager like this:
 
 .. code-block:: python
 
@@ -123,7 +123,7 @@ The regexp parameter of the ``match`` method is matched with the ``re.search``
 function, so in the above example ``match='123'`` would have worked as
 well.
 
-There's an alternate form of the ``pytest.raises`` function where you pass
+There's an alternate form of the :func:`pytest.raises` function where you pass
 a function that will be executed with the given ``*args`` and ``**kwargs`` and
 assert that the given exception is raised:
 
@@ -144,8 +144,8 @@ specific way than just having any exception raised:
     def test_f():
         f()
 
-Using ``pytest.raises`` is likely to be better for cases where you are testing
-exceptions your own code is deliberately raising, whereas using
+Using :func:`pytest.raises` is likely to be better for cases where you are
+testing exceptions your own code is deliberately raising, whereas using
 ``@pytest.mark.xfail`` with a check function is probably better for something
 like documenting unfixed bugs (where the test describes what "should" happen)
 or bugs in dependencies.

doc/en/skipping.rst

@@ -259,7 +259,7 @@ These two examples illustrate situations where you don't want to check for a con
 at the module level, which is when a condition would otherwise be evaluated for marks.
 
 This will make ``test_function`` ``XFAIL``. Note that no other code is executed after
-the ``pytest.xfail`` call, differently from the marker. That's because it is implemented
+the :func:`pytest.xfail` call, differently from the marker. That's because it is implemented
 internally by raising a known exception.
 
 **Reference**: :ref:`pytest.mark.xfail ref`
@@ -358,7 +358,7 @@ By specifying on the commandline:
     pytest --runxfail
 
 you can force the running and reporting of an ``xfail`` marked test
-as if it weren't marked at all. This also causes ``pytest.xfail`` to produce no effect.
+as if it weren't marked at all. This also causes :func:`pytest.xfail` to produce no effect.
 
 Examples
 ~~~~~~~~

doc/en/warnings.rst

@@ -265,7 +265,7 @@ Asserting warnings with the warns function
 
 
 
-You can check that code raises a particular warning using ``pytest.warns``,
+You can check that code raises a particular warning using func:`pytest.warns`,
 which works in a similar manner to :ref:`raises <assertraises>`:
 
 .. code-block:: python
@@ -293,7 +293,7 @@ argument ``match`` to assert that the exception matches a text or regex::
       ...
     Failed: DID NOT WARN. No warnings of type ...UserWarning... was emitted...
 
-You can also call ``pytest.warns`` on a function or code string:
+You can also call func:`pytest.warns` on a function or code string:
 
 .. code-block:: python
 
@@ -328,10 +328,10 @@ Alternatively, you can examine raised warnings in detail using the
 Recording warnings
 ------------------
 
-You can record raised warnings either using ``pytest.warns`` or with
+You can record raised warnings either using func:`pytest.warns` or with
 the ``recwarn`` fixture.
 
-To record with ``pytest.warns`` without asserting anything about the warnings,
+To record with func:`pytest.warns` without asserting anything about the warnings,
 pass ``None`` as the expected warning type:
 
 .. code-block:: python
@@ -360,7 +360,7 @@ The ``recwarn`` fixture will record warnings for the whole function:
         assert w.filename
         assert w.lineno
 
-Both ``recwarn`` and ``pytest.warns`` return the same interface for recorded
+Both ``recwarn`` and func:`pytest.warns` return the same interface for recorded
 warnings: a WarningsRecorder instance. To view the recorded warnings, you can
 iterate over this instance, call ``len`` on it to get the number of recorded
 warnings, or index into it to get a particular recorded warning.
@@ -387,7 +387,7 @@ are met.
                 pytest.fail("Expected a warning!")
 
 If no warnings are issued when calling ``f``, then ``not record`` will
-evaluate to ``True``.  You can then call ``pytest.fail`` with a
+evaluate to ``True``.  You can then call :func:`pytest.fail` with a
 custom error message.
 
 .. _internal-warnings:

src/_pytest/recwarn.py

@@ -115,7 +115,7 @@ def warns(
     one for each warning raised.
 
     This function can be used as a context manager, or any of the other ways
-    ``pytest.raises`` can be used::
+    :func:`pytest.raises` can be used::
 
         >>> import pytest
         >>> with pytest.warns(RuntimeWarning):