Don't crash if inspect.signature() fails on a function during stubgen.

[hawkinsp]

Use a maximally permissive type instead.

[wjakob]

Hi @hawkinsp—For posterity, can you explain in what kind of situation signature generation might fail?

[hawkinsp]

Sure. In general I might have put anything in my nanobind module, even values not produced by nanobind.

That is the case here:

In [1]: import inspect, jaxlib.utils

In [2]: inspect.signature(jaxlib.utils.safe_map)
...
File ~/.local/share/uv/python/cpython-3.13.2-macos-aarch64-none/lib/python3.13/inspect.py:2368, in _signature_from_builtin(cls, func, skip_bound_arg)
   2366 s = getattr(func, "__text_signature__", None)
   2367 if not s:
-> 2368     raise ValueError("no signature found for builtin {!r}".format(func))
   2370 return _signature_fromstr(cls, func, s, skip_bound_arg)

ValueError: no signature found for builtin <built-in function safe_map>

That attribute originates from: https://github.com/jax-ml/jax/blob/dbe98ecb816e277caf45e512cf8225f9d80ca9e0/jaxlib/utils.cc#L367

  m.attr("safe_map") = nb::steal<nb::object>(
      PyCFunction_NewEx(&safe_map_def, /*self=*/nullptr, module_name.ptr()));

i.e., it is a nanobind module, but one of the functions in it is not a nanobind function.

(Why do this? It's because there is a small but measurable cost to the nanobind argument dispatch for variadic functions, as here. I want to make sure we use the vectorcall protocol without explicitly forming tuples as nb::args would do.)

[hawkinsp]

(Edit: copied the wrong error, now fixed).

[wjakob]

Thanks!

[makslevental]

FYI I get a similar sort of error on py3.10 and for v2.7.0:

  File "/Users/maksimlevental/dev_projects/stuff/cmake-build-debug-internalcmake-1/_deps/nanobind-src/src/stubgen.py", line 431, in put_function
    sig_str = f"{name}{self.signature_str(signature(fno))}"
  File "/Users/maksimlevental/.pyenv/versions/3.10.18/lib/python3.10/inspect.py", line 3254, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped,
  File "/Users/maksimlevental/.pyenv/versions/3.10.18/lib/python3.10/inspect.py", line 3002, in from_callable
    return _signature_from_callable(obj, sigcls=cls,
  File "/Users/maksimlevental/.pyenv/versions/3.10.18/lib/python3.10/inspect.py", line 2565, in _signature_from_callable
    raise ValueError('callable {!r} is not supported by signature'.format(obj))
ValueError: callable <nanobind.nb_func object at 0x108e45cf0> is not supported by signature

I dropped a breakpoint and while obj.__signature__ is non-existent, obj.__nb_signature__ is a reasonable signature string.

[makslevental]

@wjakob can we get a point release with this fix - it's blocking usage of this feature (auto stubgen) in MLIR because we rely on PyPI for getting nanobind in CI.

[wjakob]

@makslevental Can't you make a pyproject.toml (or other distribution method) dependency on a specific branch/commit? This is what I usually do when one of my own project depends a specific very recent commit.

[wjakob]

(To be clear, I plan to make a release soon, but there are some other changes which I want to review and merge first. It might still take 1-2 weeks).

[makslevental]

@makslevental Can't you make a pyproject.toml (or other distribution method) dependency on a specific branch/commit

The issue is we're using artifact hashes for CI https://github.com/llvm/llvm-project/blob/main/.ci/all_requirements.txt#L198 which aren't supported (ironically) by git+https://... dependencies. But actually I just realized I could reference the archive that GitHub creates ie https://github.com/wjakob/nanobind/archive/53dce4e297c7ead9190a6b637b9fe6406c82aa53.zip and that'll be hashed. So I'll try to do that.

(To be clear, I plan to make a release soon, but there are some other changes which I want to review and merge first. It might still take 1-2 weeks).

Either way, I/we can wait for this. Thanks.

[makslevental]

Ah unfortunately the archive doesn't work either because of the robin-map submodule. Oh well. Anyway we'll wait.

[david-fong]

@makslevental see #403

[kwk]

@wjakob and @hawkinsp I wonder if this patch can be backported to nanobind 2.8 and then a new nanobind 2.8.x release will be made? In Fedora we're facing a situation where we cannot build LLVM using only system packages since MLIR bumped their nanobind dependency to 2.9. According to @makslevental this patch is the one that is needed by MLIR and was only available in 2.9 and not 2.8. If there was a new 2.8.x release with this patch (and what else is needed), then we can do a minor release update in already released nanobind version on Fedora. And then you can build LLVM with MLIR without the need to update to 2.9.

NOTE: This doesn't belong here but I would kindly ask MLIR folks to lower their requirement to 2.8 if this patch gets backported.

UPDATE: I revoke my request. We're talking about a different solution downstream.