This is the first task in #774. It doesn't add any new functionality, is just a refactor to put exprs in Contract.
It's a bit of a mess and the rest of the tasks in #774 will clean it up.
The type checker and the transforms are changed the most. Anywhere we used to need a Predicate reference we now pretty much also need a Contract reference. For the type checker, which likes to update types in-place as they're resolved, and for the transforms, which are obviously making wholesale changes to the predicates, this is a bit of a borrowing nightmare. Consequently a lot of the time instead of passing pred: &Predicates around we're now passing pred_name: &strs and the predicate is fetched on demand from the contract by name.
This isn't ideal and so the next task is to put the Predicates into a slotmap and refer to them generally by PredKey instead of &Predicate or by name.
But this PR is a change which touches a lot of the code and rebasing/merging against it is already a pain. (If #780 is merged first then this will get conflicts, but then vice versa. It might be easier to merge this one first, as the smaller PR is easier to reason about -- I can fix the conflicts.)
This is the first task in #774. It doesn't add any new functionality, is just a refactor to put
exprsinContract.It's a bit of a mess and the rest of the tasks in #774 will clean it up.
The type checker and the transforms are changed the most. Anywhere we used to need a
Predicatereference we now pretty much also need aContractreference. For the type checker, which likes to update types in-place as they're resolved, and for the transforms, which are obviously making wholesale changes to the predicates, this is a bit of a borrowing nightmare. Consequently a lot of the time instead of passingpred: &Predicates around we're now passingpred_name: &strs and the predicate is fetched on demand from the contract by name.This isn't ideal and so the next task is to put the
Predicates into aslotmapand refer to them generally byPredKeyinstead of&Predicateor by name.But this PR is a change which touches a lot of the code and rebasing/merging against it is already a pain. (If #780 is merged first then this will get conflicts, but then vice versa. It might be easier to merge this one first, as the smaller PR is easier to reason about -- I can fix the conflicts.)