[mlir:python] Types created by `mlir_type_subclass` are ignored by `nanobind`'s `stubgen`

[ingomueller-net]

If we expose an mlir::Type to Python using mlir_type_subclass (like here), nanobind's stubgen does not create any output for that class. This is unlike functions using nb::class_ (like this example).

I believe that stubgen only creates typing information for a class if the type(.) of the class object is a subclass of type (according to this test), which isn't the case for how mlir_type_subclass currently works.

[llvmbot]

@llvm/issue-subscribers-mlir

Author: Ingo Müller (ingomueller-net)

If we expose an `mlir::Type` to Python using `mlir_type_subclass` (like [here](https://github.com/llvm/llvm-project/blob/6a30076/mlir/lib/Bindings/Python/DialectGPU.cpp#L33)), `nanobind`'s [`stubgen`](https://nanobind.readthedocs.io/en/latest/typing.html#stub-generation) does not create any output for that class. This is unlike functions using `nb::class_` (like [this example](https://nanobind.readthedocs.io/en/latest/api_core.html#_CPPv4I0DpEN8nanobind6class_3defER6class_PKcRR4FuncDpRK5Extra).

I believe that stubgen only creates typing information for a class if the type(.) of the class object is a subclass of type (according to this test), which isn't the case for how mlir_type_subclass currently works.

[ingomueller-net]

@hawkinsp: Maybe you are also interested?

[llvmbot]

@llvm/issue-subscribers-mlir-python

Author: Ingo Müller (ingomueller-net)

If we expose an `mlir::Type` to Python using `mlir_type_subclass` (like [here](https://github.com/llvm/llvm-project/blob/6a30076/mlir/lib/Bindings/Python/DialectGPU.cpp#L33)), `nanobind`'s [`stubgen`](https://nanobind.readthedocs.io/en/latest/typing.html#stub-generation) does not create any output for that class. This is unlike functions using `nb::class_` (like [this example](https://nanobind.readthedocs.io/en/latest/api_core.html#_CPPv4I0DpEN8nanobind6class_3defER6class_PKcRR4FuncDpRK5Extra).

I believe that stubgen only creates typing information for a class if the type(.) of the class object is a subclass of type (according to this test), which isn't the case for how mlir_type_subclass currently works.

[ingomueller-net]

Actually, the test I suspected is taken as it should. The problem is rather that the generated type is in the importlib._bootstrap module instead of the module from the dialect that is given to mlir_type_subclass.

[ingomueller-net]

I just created #127584, which I believe fixes this problem.