This PR continues further the work of properly separating custom contracts in the AST in order to maintain more run-time information and be able, in the long run, to perform operations like boolean or on a larger class of contracts and to provide better error messages when contracts (in particular parametric contracts) are misused.
Note that this is a backward-incompatible change on paper, because before one could apply a custom contract built from a predicate as a function (taking a label and a value, and returning a new value). However, in practice, it's neither officially supported nor recommended - users are requested to use std.contract.apply to manipulate contracts - and thus we don't expect much actual breakage to happen. If there is breakage, we can always special case the evaluation of CustomContract::Predicate to act as a function in the evaluator.
Follow-up of #1954. Related to #1466 and #1460.
This PR continues further the work of properly separating custom contracts in the AST in order to maintain more run-time information and be able, in the long run, to perform operations like boolean
oron a larger class of contracts and to provide better error messages when contracts (in particular parametric contracts) are misused.Note that this is a backward-incompatible change on paper, because before one could apply a custom contract built from a predicate as a function (taking a label and a value, and returning a new value). However, in practice, it's neither officially supported nor recommended - users are requested to use
std.contract.applyto manipulate contracts - and thus we don't expect much actual breakage to happen. If there is breakage, we can always special case the evaluation ofCustomContract::Predicateto act as a function in the evaluator.