[all-commits] [llvm/llvm-project] 287448: [MLIR][Python] Migrate `result(infer_type=True)` t...

[Twice via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2874480930113855d3a433aeaf6ece4db0027bb3
      https://github.com/llvm/llvm-project/commit/2874480930113855d3a433aeaf6ece4db0027bb3
  Author: Twice <twice at apache.org>
  Date:   2026-04-14 (Tue, 14 Apr 2026)

  Changed paths:
    M mlir/docs/Bindings/Python.md
    M mlir/python/mlir/dialects/ext.py
    M mlir/test/python/dialects/ext.py
    M mlir/test/python/dialects/transform_op_interface.py
    M mlir/test/python/integration/dialects/bf.py

  Log Message:
  -----------
  [MLIR][Python] Migrate `result(infer_type=True)` to a new field specifier (#191849)

Currrently the signature of `result(..)` is:
```python
result(*, infer_type: bool = False, default_factory: Callable[[], Any] | None = None, kw_only: bool = False) -> Result
```

so when users use `result(infer_type=True)`, the type checkers will
still get `kw_only=False` (from the signature), but actually the
`kw_only` should be `True` (it should follow the value of `infer_type`).
users can use `result(infer_type=True, kw_only=True)` but it's
unnecessarily verbose.

So it may introduce an incompatibility when we start to use
`dataclass_transform`. currently it's fine because we just don't use
`dataclass_transform`. But when we use, we may require a breaking
change.

This PR migrates such use to a new field specifier named
`infer_result()`.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications