This is making a tablegen crash with a more friendly error.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp | ||
---|---|---|
478 | Should this be named assertNameInvariants? Or do we plan on adding more checks here? | |
479 | Could we use something like DenseMap<StringRef, StringRef>? Where the value of the dense map would be the type of the existing entity? That way we could construct one message that covers all possible overlap cases, i.e. something like: DenseMap<StringRef, StringRef> existingNames; auto recordName = [&](StringRef name, StringRef type) { if (name.empty()) return; StringRef &nameType = existingNames[name]; if (!nameType.empty()) { if (nameType == type) { PrintFatalError( op.getLoc(), llvm::formatv( "op has two {0}s with the same name: '{1}'", nameType, name)); } else { PrintFatalError( op.getLoc(), llvm::formatv( "op is using the same name for a {0} and a {1}: '{2}'", nameType, type, name)); } } nameType = type; }; for (int i : llvm::seq<int>(0, op.getNumOperands())) recordName(op.getOperand(i).name, "operand"); ... |
Move the invariant checking on the Operator class construction and check for region/successor overlap as well
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp | ||
---|---|---|
478 | I thought I'd leave it open to more invariants as we see fit? |
Should this be named assertNameInvariants? Or do we plan on adding more checks here?