[llvm] [mlir] [MLIR][Python] reland (narrower) type stub generation (PR #157930)
Ingo Müller via llvm-commits
llvm-commits at lists.llvm.org
Mon Dec 1 03:36:02 PST 2025
ingomueller-net wrote:
A bunch of `pyright` checks are [failing](https://github.com/substrait-io/substrait-mlir-contrib/actions/runs/19820704706/job/56782197537?pr=176) after this commit. I believe at least the following are due to problems in the MLIR code base, though I don't understand exactly how they are related to this PR:
* `error: "__getitem__" method not defined on type "RegionSequence" (reportIndexIssue)`
Indeed, `RegionSequence` inherits from `Slicable`, which says in its documentation that it binds `__len__` and `__getitem__` but not through nanobind. I guess that this the reason why no stubs are generated for these two dunder methods.
* `error: Object of type "object" is not callable`
Indeed, `register_operation` returns an `nb::object`. Since it is meant to be a decorator, I think it should return a `Callable`. It returns an object created from `nb::cpp_function`, which (curiously, IMO) does *not* return an `nb::callable` but an `nb::object`. I tried fixing this with a manually crafted `nb::sig(.)` -- that makes the error go away and -- curiously -- all other errors as well. This could mean that `pyright` is broken by the new signature, so it's not clear to me if that's a proper fix.
* `error: Import symbol "X" has type "type[Y]", which is not assignable to declared type "type[Z]"`
This is almost certainly a consequence of the previous problem but since my attempt to fix it removed *all* error reports, I don't fully trust it.
@makslevental: What's your take? What's the best way to deal with this?
https://github.com/llvm/llvm-project/pull/157930
More information about the llvm-commits
mailing list