* The directive option ``:noindex:`` was renamed to ``:no-index:``.
* The directive option ``:noindexentry:`` was renamed to ``:no-index-entry:``.
* The directive option ``:nocontentsentry:`` was renamed to ``:no-contents-entry:``.
The previous names are retained as aliases, but will be deprecated
and removed in a future version of Sphinx (9.0 or later).
* Generic classes can be documented with ``.. py:class::`` using PEP 695 syntax:
.. code:: rst
.. py:class:: Sequence[T]
* Generic functions can be documented with ``.. py:function::`` using PEP 695 syntax:
.. code:: rst
.. py:function:: foo[T](x: T)
* Default values for type bounds are supported.
Co-authored-by: Adam Turner <9087854+aa-turner@users.noreply.github.com>
The new ``python_display_short_literal_types`` configuration option
for the ``py`` domain controls display of PEP 586 ``Literal`` types.
The 'short' format is inspired by PEP 604, using the bitwise OR operator
to distinguish the possible legal values for the argument.
Previously, ``nested_parse_with_titles`` always passed ``0`` as the input
offset when invoking ``nested_parse``. When parsing the content of a
directive, as is a common use case for ``nested_parse_with_titles``,
this leads to incorrect source file/line number information, as it
does not take into account the directive's ``content_offset``, which is
always non-zero.
This issue affects *all* object descriptions due to GH-10887. It also
affects the ``sphinx.ext.ifconfig`` extension.
The ``py:module`` and ``js:module`` directives employed a workaround for
this issue, by wrapping the calls to ``nested_parse_with_title`` with
``switch_source_input``. That worked, but was more complicated (and
likely less efficient) than necessary.
This commit adds an optional ``content_offset`` parameter to
``nested_parse_with_titles``, and fixes callers to pass the appropriate
content offset when needed.
This commit eliminates the now-unnecessary calls to
``switch_source_input`` and instead specifies the correct ``content_offset``.
Resolved merge conflicts:
sphinx/ext/extlinks.py
sphinx/ext/napoleon/docstring.py
(and removed from the latter a now unused import for flake8 F401
compliance)
To support creating hyperlinks to container types naturally, py domain
should take fully-qualified typehints for them. But nobody wants to
show "typing." module name on the signature. So this suppresses them
automatically.
Now python domain supports the "~" prefix at the beginning of the
typehints of the function signatures:
.. py:function:: func(x: ~typing.Dict)
It's rescognized as the same as python reference roles do
(ex. :py:class:`~typing.Dict`).