[Mlir-commits] [mlir] [mlir-c] Add mlirOperationGetParentWithName (PR #206533)

[Maksim Levental]

makslevental wrote:

Review of `testGetParentWithName` (`mlir/test/CAPI/ir.c`):

**\[minor] The test never proves the "nearest ancestor" / "first parent" semantics.** The docstring and impl (`for (parent = getParentOp(); parent; parent = parent->getParentOp()) if (...) return parent;`) promise the *closest* matching ancestor. But the IR built here has the chain `arith.constant` -> `func.func` -> `builtin.module`, where every queried name (`func.func`, `builtin.module`) appears exactly once. So an implementation bug that returned the *outermost* match instead of the nearest would still pass all four asserts — the distinguishing behavior is vacuously covered.

Suggest adding a case with a repeated name in the ancestor chain, e.g. a nested `builtin.module` (or nested `scf.execute_region`/`scf.for`) so that a query returns the inner one and `mlirOperationEqual` distinguishes it from the outer same-named op. That is the only assertion that would actually catch a regression in the walk ordering.

Minor coverage notes (optional): no case exercises a top-level op whose `getParentOp()` is null (e.g. calling on `moduleOp` itself -> expect null), which is the boundary the `parent;` loop guard protects.

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