It prevents this bug:
```python
viewcode can't import None, failed with error "__import__() argument 1 must be str, not None"
Traceback (most recent call last):
File "/usr/local/lib/python3.5/dist-packages/sphinx/ext/viewcode.py", line 28, in _get_full_modname
return get_full_modname(modname, attribute)
File "/usr/local/lib/python3.5/dist-packages/sphinx/util/__init__.py", line 263, in get_full_modname
__import__(modname)
TypeError: __import__() argument 1 must be str, not None
```
The function is used from many builders which combines multiple
doctrees to single one (e.g. LaTeX, singlehtml and so on).
To deprecate it might cause big troubles for 3rd party builders.
So I withdraw the deprecation.
Since #3022 (Sphinx 1.5) more footnotes are hyperlinked but it became
impossible for Sphinx user to pass option ``hyperfootnotes=false`` to
package ``hyperref``. Release 1.0 of LaTeX package ``footnotehyper``,
which serves as bugfix replacement to older package ``footnote``, is
compatible with ``hyperfootnotes=false``, hence it is again possible to
Sphinx user to completely disable hyperlinking of footnotes, if ever
needed.
Moved #3465 here, to address this in `stable` instead.
This fixes a problem with the Python domain object nesting. Because only one
object name was stored in `ref_context`, and reset to `None` in `after_content`,
nesting broke if you put anything after a nested class:
```rst
.. py:class:: Parent
.. py:method:: foo()
This wouldn't resolve: :py:meth:`bar`
.. py:class:: Child
In the `after_content` method, the object is reset to `None`, so
anything after this in the same nesting is considered to be top level
instead.
.. py:method:: bar()
This is top level, as the domain thinks the surrounding object is `None`
```
This depends on #3519 and can be rebased after that is merged into stable
Fixes#3065
Refs #3067
Using `python -msphinx` as the default for SPHINXBUILD in the
Makefile/make.bat ensures that whatever virtual environment is currently
active (if any) gets picked up. In the current situation, imaging that
we are working on project $foo which is also installed system-wide,
but we want to build docs for a venv-installed version; that sphinx
is installed system-wide but not in the current environment, and that
e.g. conf.py imports $foo (e.g. to retrieve a version string). Then
sphinx-build will resolve to the globally installed version, and the
global (wrong) version of $foo will be imported as well.
With this fix, `make html` will do everything in the correct virtualenv
(if any). This switch is similar in spirit to e.g. the deprecation of
the `pyvenv` script in Py3.6, in favor of `python -mvenv`.
These are just the passing test cases for the domains currently. I am going to
patch up issues with nesting on both domains to start, so these are the test
cases I'll be testing against. I'll see about addressing the other core
domains, or at very least the cpp domain, with similar tests if this looks
okay.
So far, these tests only test against methods/functions for the basic nesting
structure. More complete tests will test additional domain roles.
Refs #662
