Deprecated Items
This appendix attempts to document the things in SAW that have been deprecated and removed over recent releases, in more detail than will fit in the change log and release notes.
Upcoming
The following elements are expected to be deprecated in SAW 1.6 such that they will warn when used, but have not yet been tagged:
The type
SetupValue(an old name forLLVMValue)The type
CrucibleMethodSpec(an old name forLLVMSpec)The type
CrucibleSetup(an old name forLLVMSetup)
The following experimental element is expected to be deprecated in SAW 1.6 such that it will be hidden by default, but has not yet been tagged:
The experimental builtin
crucible_llvm_verify_x86(an old name forllvm_verify_x86), which was left in place in SAW 1.5 due to some downstream uses that needed to be migrated first.
Migration for all of these is as simple as updating the name.
Warning When Used
The following elements are currently deprecated and warn when used; this has happened since SAW 1.5 was released, so they will be that way in SAW 1.6. They are expected to be hidden by default in SAW 1.7.
The
prove_extcorebuiltin; you can just useprove_printinstead now.The
add_prelude_eqsandadd_cryptol_eqsbuiltins; useadd_core_thmsinstead.The
assume_unsatbuiltin, which was informally deprecated years ago; useadmitinstead.admittakes an extra string argument that’s supposed to state why you’re admitting the theorem without proof.
The following elements were deprecated as of SAW 1.5, and currently warn. They will be hidden by default when we remove Boolector from what4-solvers, which will not happen before SAW 1.6; after that point the time frame depends mostly on the maintenance burden.
The commands related to the Boolector solver, which has been replaced upstream with Bitwuzla. All
boolectorcommands have equivalentbitwuzlacommands.
The following elements were deprecated as of SAW 1.5 (or earlier), currently warn, but are expected to be hidden by default in SAW 1.6:
The commands related to the CVC4 solver; proofs should be migrated to CVC5. Each
cvc4builtin has a correspondingcvc5builtin. If you have proofs that work withcvc4but time out incvc5, and you cannot find another solver that can handle them instead, please file an issue (with us or CVC5 upstream as seems best).The
external_aig_solverbuiltin, which was renamed toarbitrary_aig.The
external_cnf_solverbuiltin, which was renamed toarbitrary_cnf.The
w4_offline_smtlib2builtin, which was renamed tooffline_w4_smtlib2for consistency.The
llvm_structbuiltin; the current name for it isllvm_alias, because it looks up typedef names. If you are trying to create an LLVM struct type from its contents, as many historical callers were found to be, you wantllvm_struct_typeinstead.The old
coqnames of the Rocq backend; changecoqtorocq.The many old
cruciblenames of LLVM backend functions; e.g.crucible_nullis nowllvm_null. Most of these names have been outdated for years.Similarly, the
crucible_java_extractbuiltin, which is an old name forjvm_extract.
Removed
The following elements have been removed entirely:
The
addsimp'andaddsimps'builtins, which added unproven rewrite rules to aSimpset. Don’t do that; it’s borrowing trouble. If you can’t prove your rewrite rules, for whatever, reason, useadmitexplicitly and then use the ordinaryaddsimpand/oraddsimpsbulitins to add them toSimpsets.The
crucible_setup_val_to_termbuiltin. This was a partial inverse forllvm_term; that is, it turned anLLVMValuevalue back to aTermif it was one that could be represented. In general LLVM specs should be written so they lift values fromTermtoLLVMValueand not the other way around.The unused type
JavaSetup; any stray references to it should be changed toJVMSetup.The
extract_uninterpbuiltin. This was a way to rewrite aTermto make functions uninterpreted (generalize it over all functions that are functions in place of specific functions with definitions) and also extract the uses of those functions for further processing. This depended on problematic internal functionality, and also relied on being able to identify which applications of a given function are actually the same, which is difficult in general and not the right approach.The Heapster, MRSolver, and Monadify features, which proved unmaintainable and inconsistent with efforts to build SAW an assurance case.
The
sbv_uninterpretedandread_sbvbuiltins and theirUninterptype. This was code for importing from an obsolete file format.The
callccbuiltin, whose behavior was erratic, whose internal implementation was insupportable, and which had only one known use that was itself better done some other way.
Also, the following SAWScript language-level behavior has been removed:
It used to be possible to update top-level variable bindings by just binding the same variable again. This would update some uses and not others depending on the then-very-dodgy evaluation semantics of SAWScript. Now if you bind the same variable again, it just shadows the old variable in the namespace and does not replace it.
For uses that really need the mutability behavior, you can now, at the top level only, do
let rebindable ..., which lets you bind a variable that you can update with anotherlet rebindable ..., and the semantics of the update are predictable.