vasilito
cb424d7448
verify-patch-sanity.py validates every active recipe .patch has internally- consistent hunk line counts — catching the 'malformed patch at line N' failure at commit/CI/preflight time instead of hours into a cook. This cycle hit that class three times (qtwaylandscanner, sddm, xwayland), each only discovered when cookbook tried to apply the patch. Running it across the repo found 29 latent malformed patches (validated against GNU patch: e.g. relibc/P3-sysv-ipc reproduces 'malformed patch at line 22'). They were harmless only because they sit in vendored recipes (baked, not re- applied) — but would fail on any version-bump re-derivation. --fix recounts the hunk headers (body untouched) and repaired all 29. Wired into build-preflight.sh (Phase 1.0D) and redbear-ci.yml, with a unit test (test-patch-sanity.sh). Skips archived/legacy trees and unvalidatable formats (empty placeholders, bare-@@ git hunks).
2.5 KiB
Constraints
[TOC]
Attribute / Type Constraints
When defining the arguments of an operation in TableGen, users can specify either plain attributes/types or use attribute/type constraints to levy additional requirements on the attribute value or operand type.
def My_Type1 : MyDialect_Type<"Type1", "type1"> { ... }
def My_Type2 : MyDialect_Type<"Type2", "type2"> { ... }
// Plain type
let arguments = (ins MyType1:$val);
// Type constraint
let arguments = (ins AnyTypeOf<[MyType1, MyType2]>:$val);
AnyTypeOf is an example for a type constraints. Many useful type constraints
can be found in mlir/IR/CommonTypeConstraints.td. Additional verification
code is generated for type/attribute constraints. Type constraints can not only
be used when defining operation arguments, but also when defining type
parameters.
Optionally, C++ functions can be generated, so that type/attribute constraints
can be checked from C++. The name of the C++ function must be specified in the
cppFunctionName field. If no function name is specified, no C++ function is
emitted.
// Example: Element type constraint for VectorType
def Builtin_VectorTypeElementType : AnyTypeOf<[AnyInteger, Index, AnyFloat]> {
let cppFunctionName = "isValidVectorTypeElementType";
}
The above example tranlates into the following C++ code:
bool isValidVectorTypeElementType(::mlir::Type type) {
return (((::llvm::isa<::mlir::IntegerType>(type))) || ((::llvm::isa<::mlir::IndexType>(type))) || ((::llvm::isa<::mlir::FloatType>(type))));
}
An extra TableGen rule is needed to emit C++ code for type/attribute
constraints. This will generate only the declarations/definitions of the
type/attribute constaraints that are defined in the specified .td file, but
not those that are in included .td files.
mlir_tablegen(<Your Dialect>TypeConstraints.h.inc -gen-type-constraint-decls)
mlir_tablegen(<Your Dialect>TypeConstraints.cpp.inc -gen-type-constraint-defs)
mlir_tablegen(<Your Dialect>AttrConstraints.h.inc -gen-attr-constraint-decls)
mlir_tablegen(<Your Dialect>AttrConstraints.cpp.inc -gen-attr-constraint-defs)
The generated <Your Dialect>TypeConstraints.h.inc respectivelly
<Your Dialect>AttrConstraints.h.inc will need to be included whereever you are
referencing the type/attributes constraint in C++. Note that no C++ namespace
will be emitted by the code generator. The #include statements of the
.h.inc/.cpp.inc files should be wrapped in C++ namespaces by the user.