[Mlir-commits] [mlir] [mlir][ODS] Add namespace filtering to `-gen-enum-*` (PR #89627)

[Mehdi Amini]

joker-eph wrote:

> I see your point yes. As in, DialectBEnums.td that is conceptually part of DialectB that depends on DialectA will not see DialectAEnums.td since there is no reason for that file to ever include any TableGen file from DialectA, right?

Yes.

> I don't mind changing the description. At least upstream it hasn't been that big of an issue as most upstream dialects don't include the TD files of another dialect. Defining enums in anything but a dedicated *Enums.td is sadly not uncommon however (git grep EnumAttr shows many such places). 

This is the only known pattern that works. I haven't audited upstream, but in general this gets put in place when needed.
For example the Arith dialect enums are defined in ArithBase.td and this file is included then by: Affine/IR/AffineOps.td,  Arith/IR/ArithOps.td, Complex/IR/ComplexOps.td, Math/IR/MathOps.td, MemRef/IR/MemRefOps.td, and Vector/IR/VectorOps.td.

LLVM dialect has `LLVMEnums.td`, Linalg has `LinalgEnums.td`, and `LinalgTransformEnums.td`, Mesh dialect has `MeshBase.td`, etc.
So it seems to me that this is actually quite common? 

Other cases aren't really needed, for example the MPI dialect does not split the enum, but these should be considered "internal" (for example `MPI_CodeErrRoot` does not have uses outside of MPI, and if someone needs it, then it's just a refactoring away).

> We can view these as being bugs in need of fixing or a need for a convention to be established and documented, but that seems like a larger discussion than this PR.

Well: this could also make this PR not needed, so it's not totally beyond the scope here :)

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