[Mlir-commits] [mlir] [mlir][tblgen] Error on unsubstituted $_self in op trait predicates (PR #227263)

llvmlistbot at llvm.org llvmlistbot at llvm.org
Tue Sep 29 19:13:54 PDT 2026


LiRvs-Miria wrote:

@joker-eph Thanks for the review — both points are fair.

Background: I develop an out-of-tree MLIR dialect for IEC 61499, an industrial control language, and hit this exact failure while writing a PredOpTrait that used `$_self` out of habit from constraint context. The generated `$_self<no-subst-found>` C++ took a while to trace back to the ODS definition, which motivated this patch. That origin also explains the narrow framing: I only had evidence for the `$_self` case.

You're right that the mechanism is not `$_self`-specific: tgfmt appends `kMarkerForNoSubst` to any unbound placeholder (custom names, `$_builder`, out-of-range positionals), and the check I added already matches the marker generically — only the diagnostic message overclaims `$_self`.

On scope: there are 100+ tgfmt call sites across the generators, so checking at each emit site isn't practical. Would you prefer:

1. keeping the check where it is but generalizing the diagnostic (report the actual unbound placeholder, with the `$_op`/`!subst` advice only for `$_self`); or
2. moving the check into tgfmt itself (Format.cpp), so any unbound placeholder in user-authored templates is diagnosed centrally? One complication: `canUniqueAttrConstraint()`/`canUniquePropConstraint()` (CodeGenHelpers.cpp) speculatively format constraints and rely on the marker to decide whether constraints can be deduplicated, so those callers would need an opt-out from a hard error.

I'm happy to implement whichever direction you prefer.

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


More information about the Mlir-commits mailing list