In particular, if the only specification attached is the MODIFIES line,
then the automatic machinery will cope with proving the modifies result.
So, now rule out those with DONT_TRANSLATE and at least one fnspec.
Give Strengthen its own theory and a much more robust and general
implementation. However take away its ability to do elimination, maybe
to be restored.
Introduce a new theory, WPBang, for applying wp safe rules, with possible
attribute wp! (attribute yet to be implemented).
Still testing out both adjustments.
Why this is suddenly a problem now, when there hasn't been a change to
this file in years is completely unclear. Nonetheless, I need a green
build.
The error was:
*** Duplicate fact declaration "dc_20081211.dc_20081211.test_modifies"
vs. "dc_20081211.dc_20081211.test_modifies" (line 42 of
"~/repos/v/l4v/tools/c-parser/testfiles/dc_20081211.thy")
*** At command "lemma" (line 42 of
"~/repos/v/l4v/tools/c-parser/testfiles/dc_20081211.thy")
Green build except for:
CParserTest (WTF Duplicate fact declaration "dc_20081211.dc_20081211.test_modifies")
AutoCorresSEL4 (waiting on result)
There is still a carefully managed sorry in Schedule_R, waiting on the C
parser FNSPEC+DONT_TRANSLATE fix.
In Schedule_C:
(**** FIXME FIXME FIXME ***)
(* As per JIRA VER-464, the C Parser does not handle
DONT_TRANSLATE+MODIFIES+FNSPEC correctly. This is the spec given in util.h
in seL4 for clz. We do not get that spec back at present.
In order to have a working build until the C parser is fixed, we sorry this
proof. My apologies.
*)
Added word_log2 and word_clz (inline for now, will migrate them out to
lib later).
Proved most important properties of word_log2 and some basic
count leading zeros properties (word_clz). The former were painful.
Thanks to Thomas, we have a nice tactic for dealing with complicated
obj_at' predicates in conclusion: normalise_obj_at'
Inline code from a Markdown source (`like this`) is typically translated
without the assistance of Pygments. As a result we don't get automatic
subscript and superscript support, and need to roll our own. This translation
is pretty blunt and fragile. Expect it to fall over in a TeX error if you pass,
e.g., a "\<^bsub>" without a closing "\<^esub>".