… in DialectTransform.cpp (NFC)

… in ExecutionEngineModule.cpp (NFC)

…(NFC)

… in IRAffine.cpp (NFC)

…tes.cpp (NFC)

… in IRAttributes.cpp (NFC)

….cpp (NFC)

…NFC)

…e.cpp (NFC)

…Core.cpp (NFC)

… in IRTypes.cpp (NFC)

… in Pass.cpp (NFC)

…thing.cpp (NFC)

…nTypes.cpp (NFC)

This function isn't exposed in any header and unused in the codebase.

…deDialectGen.cpp (NFC)

Correct few typos: 'seperate' -> 'separate' .

…rmatGen.cpp (NFC)

Historical context: `PyMlirContext::liveOperations` was an optimization
meant to cut down on the number of Python object allocations and
(partially) a mechanism for updating validity of ops after
transformation. E.g. during walking/transforming the AST. See original
patch [here](https://reviews.llvm.org/D87958).

Inspired by a
[renewed](llvm/llvm-project#139721 (comment))
interest in llvm/llvm-project#139721 (which has
become a little stale...)

<p align="center">
<img width="504" height="375" alt="image"
src="https://github.com/user-attachments/assets/0daad562-d3d1-4876-8d01-5dba382ab186"
/>
</p>

In the previous go-around
(llvm/llvm-project#92631) there were two issues
which have been resolved

1. ops that were "fetched" under a root op which has been transformed
are no longer reported as invalid. We simply "[formally
forbid](llvm/llvm-project#92631 (comment))"
this;
2. `Module._CAPICreate(module_capsule)` must now be followed by a
`module._clear_mlir_module()` to prevent double-freeing of the actual
`ModuleOp` object (i.e. calling the dtor on the
`OwningOpRef<ModuleOp>`):

     ```python
    module = ...
    module_dup = Module._CAPICreate(module._CAPIPtr)
    module._clear_mlir_module()
    ```
- **the alternative choice** here is to remove the `Module._CAPICreate`
API altogether and replace it with something like `Module._move(module)`
which will do both `Module._CAPICreate` and `module._clear_mlir_module`.

Note, the other approach I explored last year was a [weakref
system](llvm/llvm-project#97340) for
`mlir::Operation` which would effectively hoist this `liveOperations`
thing into MLIR core. Possibly doable but I now believe it's a bad idea.

The other potentially breaking change is `is`, which checks object
equality rather than value equality, will now report `False` because we
are always allocating `new` Python objects (ie that's the whole point of
this change). Users wanting to check equality for `Operation` and
`Module` should use `==`.

…blgen.cpp (NFC)

llvm/llvm-project#155114 broke op hashing
(because the python objects ceased to be reference equivalent). This PR
fixes by binding `OperationEquivalence::computeHash`.

…end (#156624)

This commit moves the "element" param of `DICompositeType` to the end of
the parameter list. This is required as there seems to be a bug in the
attribute parser that breaks a print + parse roundtrip.

Related ticket: llvm/llvm-project#156623

…atGen.cpp (NFC)

…inferable result types (#156818)

Currently in MLIR python bindings, operations with inferable result
types (e.g. with `InferTypeOpInterface` or `SameOperandsAndResultType`)
will generate such builder functions:

```python
def my_op(arg1, arg2 .. argN, *, loc=None, ip=None):
  ... # result types will be inferred automatically
```

However, in some cases we may want to provide the result types
explicitly. For example, the implementation of interface method
`inferResultTypes(..)` can return a failure and then we cannot build the
op in that way. Also, in the C++ side we have multiple `build` methods
for both explicitly specify the result types and automatically inferring
them.

In this PR, we change the signature of this builder function to:

```python
def my_op(arg1, arg2 .. argN, *, results=None, loc=None, ip=None):
  ... # result types will be inferred automatically if results is None
```

If the `results` is not provided, it will be inferred automatically,
otherwise the provided result types will be utilized. Also, `__init__`
methods of the generated op classes are changed correspondingly. Note
that for operations without inferable result types, the signature remain
unchanged, i.e. `def my_op(res1 .. resN, arg1 .. argN, *, loc=None,
ip=None)`.

---

Previously I have considered an approach like `my_op(arg, *, res1=None,
res2=None, loc=None, ip=None)`, but I quickly realized it had some
issues. For example, if the user only provides some of the arguments—say
`my_op(v1, res1=i32)`—this could lead to problems. Moreover, we don’t
seem to have a mechanism for inferring only part of result types. A
unified `results` parameter seems to be more simple and straightforward.

…(#162016)

… os directly (#162014)

Change `emitSummaryAndDescComments` to directly write to the output
stream, avoiding creating large intermediate strings.

…ind (#161230)

Inspired by this comment
llvm/llvm-project#157930 (comment)
(and long-standing issues related to finding nanobind/pybind in the
right place), this PR moves to using `FetchContent_Declare` to get the
nanobind dependency. This is pretty standard (see e.g.,
[IREE](https://github.com/iree-org/iree/blob/cf60359b7443b0e92e15fb6ffc011525dc40e772/CMakeLists.txt#L842-L848)).
This PR also removes pybind which has been deprecated for almost a year
(llvm/llvm-project#117922) and which isn't
compatible (for whatever reason) with `FetchContent_Declare`.

---------

Co-authored-by: Jacques Pienaar <[email protected]>

This allows to define multiple interface methods with the same name but
different arguments.

We're shadowing the Python builtin function `globals` in `ir.py` and
therefore anywhere someone does `from mlir.ir import *`. So hide it.

…hon (#162591)

`PassManager::enableStatistics` seems currently missing in both C API
and Python bindings. So here we added them in this PR, which includes
the `PassDisplayMode` enum type and the `EnableStatistics` method.

… (#162526)

For a pattern like this:

    Pat<(MyOp $x, $x),
        (...),
        [(MyCheck $x)]>;

The old implementation generates:

    Pat<(MyOp $x0, $x1),
        (...),
        [(MyCheck $x0),
         ($x0 == $x1)]>;

This is not very straightforward, because the $x name appears in the
source pattern; it's attempting to assume equality check will be
performed as part of the source pattern matching.

This commit moves the equality checks before the other constraints,
i.e.:

    Pat<(MyOp $x0, $x1),
        (...),
        [($x0 == $x1),
         (MyCheck $x0)]>;