Ambiguous type references when classes share the same name

[DanCardin]

I think it's very much related to the same problem described here: https://github.com/readthedocs/sphinx-autoapi/issues/364.

In attempting to make a reproducible example for it, I noticed a lack of the expected error, but instead that the wrong class was linked.

Take the following setup:

├── source
│  ├── conf.py
│  └── index.rst
└── wat
   ├── __init__.py
   ├── file1.py
   └── file2.py

# conf.py
extensions = [
    "sphinx.ext.autodoc",
    "autoapi.extension",
]

autoapi_type = "python"
autoapi_dirs = [".."]
autoapi_generate_api_docs = False
autodoc_typehints_format = "fully-qualified"

# index.rst
Test
====

.. autoapimodule:: wat.file1
   :members: Foo

.. autoapimodule:: wat.file2
   :members: Other

# file1.py
class Foo:
    pass

# file2.py
class Foo:
    pass

class Other:
    def foo(self, foo: Foo) -> Foo:
        return foo

i.e. file1.Foo is standalone with no references to it. file2.Foo is clearly referenced directly by file2.Other in the same file.

It does not error, like I am encountering in a real project (link if relevant), but instead it silently creates a link to the wrong Foo

I had thought perhaps that autodoc_typehints_format = 'fully-qualified' might be relevant here, which is why I included it in the conf.py, although it doesn't appear to have an effect.

---

Relative to my real-world example/the above linked issue, this is clearly not the same circumstance, because this is not erroring. but the code-scenario used to produce it is very much similar/the same.

In both cases, it seems like just making sure that the correct object (file2.Foo in this case) is "accessible", in that it's been documented by autoapi

Expected behavior

In the above outlined scenario, I would not expect it to silently link to the wrong object, regardless of whether there is a same-named object documented elsewhere. I would expect this case to either silently produce no link or else produce no link and then warn that there was no autodoc'd Foo reference to link to.

Perhaps in the linked issue/real project, I would expect the same behavior also. The "more than one target found for cross-reference" error message is mostly just confusing because it implies that there is an ambiguous documentation reference, when in fact the reference is being autogenerated by type hints.