You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each of these has its own copy of code to allow setting a ValidationLevel, and some have other pass-specific configuration. There is no common interface - the idea of a "pass" is purely conceptual. They then run via ValidationLevel::run_validated_pass with a callback (leading to quite a complicated signature, and possibly fun with the borrow-checker).
We could improve on this via:
A trait Pass which could be roughly, fn run(h: &mut impl HugrMut) -> Result<(), Self::Error> (plus associated type Error)
A ValidatingPass<P: Pass>(P, ValidationLevel) that wraps another pass with something like the current ValidationLevel but without ValidationLevel::None. We could have a single ValidationPassError<E> that reports either an error in validation (before/after) or an underlying error E
Some kind of "SequencePass" that wraps a bunch of other passes (I think this would have to use dyn so maybe just two arbitrary passes) - and we can add methods to trait Pass that combine Passes e.g. and_then(other: impl Pass) -> impl Pass. This would combine with the previous to allow validation before/after a number of passes but not at steps inbetween.
At present we have a bunch of things that call themselves Passes - ConstantFoldPass, MonomorphizePass, RemoveDeadFuncsPass.
Each of these has its own copy of code to allow setting a
ValidationLevel
, and some have other pass-specific configuration. There is no common interface - the idea of a "pass" is purely conceptual. They then run viaValidationLevel::run_validated_pass
with a callback (leading to quite a complicated signature, and possibly fun with the borrow-checker).We could improve on this via:
trait Pass
which could be roughly,fn run(h: &mut impl HugrMut) -> Result<(), Self::Error>
(plus associated typeError
)ValidatingPass<P: Pass>(P, ValidationLevel)
that wraps another pass with something like the current ValidationLevel but without ValidationLevel::None. We could have a singleValidationPassError<E>
that reports either an error in validation (before/after) or an underlying errorE
dyn
so maybe just two arbitrary passes) - and we can add methods totrait Pass
that combine Passes e.g.and_then(other: impl Pass) -> impl Pass
. This would combine with the previous to allow validation before/after a number of passes but not at steps inbetween.The text was updated successfully, but these errors were encountered: