[Mlir-commits] [mlir] [mlir][python] Make test stubgen depend on _mlirRegisterEverything (PR #235462)

[llvmlistbot at llvm.org]

aidint wrote:

> This isn't correct; _site_initialize tries to import _mlirRegisterEverything and gracefully fails if it's not available

You are right, my description is a little bit misleading. As you said, it _tries_ to import `_mlirRegisterEverything`. The issue doesn't happen with fresh builds, but with incremental builds. When a stale build is still on disk, the import succeeds and loads the stale `_mlirRegisterEverything`, so the fallback can't handle this scenario.

The module itself doesn't need `_mlirRegisterEverything`, but once `_mlirRegisterEverything` is built into the same `_mlir_libs` directory, importing the module through the package loads it, so there's an implicit dependency.

> Is this an issue you're seeing only in generating this stub?

Yes. This doesn't happen with `_mlir` because stubgen doesn't import `mlir._mlir_libs` for it. It also doesn't happen with the standalone package, as `_mlirRegisterEverything` is not built into its package.

If I'm not mistaken `mlir_generate_type_stubs` takes the module name and passes it to `stubgen.py` as `--module`, and then the module is loaded via `importlib.import_module`:

https://github.com/wjakob/nanobind/blob/a47983000e9dda68177fc1fd426f7147d785c2c0/src/stubgen.py#L1652

In the case of `mlir._mlir_libs._mlirPythonTestNanobind`, importing it first imports the parent package `mlir._mlir_libs`, so its `__init__.py` executes and tries to import `_mlirRegisterEverything`. That's how a stale `_mlirRegisterEverything` gets imported.

https://github.com/llvm/llvm-project/pull/235462