Override specs are incorrectly adjudged unsat when they just don't match
sauclovian-g opened this issue · comments
It seems that if you have an override spec with multiple assertions in its precondition, and more than one of them fails to be true when we attempt to apply the override, SAW generates this message:
The conjunction of these overrides' preconditions was unsatisfiable, meaning your override can never apply. You probably have unintentionally specified mutually exclusive/inconsistent preconditions.
(If there is only one failing assertion, the override just fails to match.)
In this case it is not (necessarily at least) true that the override's precondition is unsatisfiable; it is just unsatisfiable in combination with the current execution context, which in turn just means that the preconditions weren't met, and SAW should print accordingly. Claiming that the override itself is unsatisfiable sends one off in completely the wrong direction.
I don't have a simple example but one can probably be constructed. A complex example can be generated by going to the formal-verso tree, commenting out the vecobj_len assertion on line 34 of CustomTypes2.cry, commenting out the minor_of_val part of is_u32 on line 503 of Values.cry, and running saw on custom_types2.saw. (As of commit GaloisInc/formal-verso@231d915)