All these options take a single non-negative number as an argument where giving zero explicitly disables the respective limit. For time limits the number is interpreted as the number of milliseconds, and for resource limits it indicates the amount of *resources*.
The limits configured using :ref:`tlimit <lbl-option-tlimit>` and :ref:`rlimit <lbl-option-rlimit>` restrict time and resource usage over the whole lifetime of the :cpp:class:`solver <cvc5::Solver>` object, respectively.
-In contrast to that, :ref:`tlimit-per <lbl-option-tlimit-per>` and :ref:`rlimit-per <lbl-option-rlimit-per>` apply to every check individually (:cpp:func:`checkSat <cvc5::Solver::checkSat>`, :cpp:func:`checkSatAssuming <cvc5::Solver::checkSatAssuming>`, :cpp:func:`checkEntailed <cvc5::Solver::checkEntailed>`, etc).
+In contrast to that, :ref:`tlimit-per <lbl-option-tlimit-per>` and :ref:`rlimit-per <lbl-option-rlimit-per>` apply to every check individually (:cpp:func:`checkSat <cvc5::Solver::checkSat>`, :cpp:func:`checkSatAssuming <cvc5::Solver::checkSatAssuming>`, etc).
Except for the overall time limit (see below), the limits are checked by cvc5 itself. This means that the solver remains in a safe state after a limit has been reached.
Due to the way cvc5 checks these limits (see below), cvc5 may not precisely honor per-call time limits: if a subroutine requires a long time to finish without spending resources itself, cvc5 only realizes afterwards that the timeout has (long) passed.
context::CDO<size_t> d_globalDefineFunLemmasIndex;
/**
* The list of assumptions from the previous call to checkSatisfiability.
- * Note that if the last call to checkSatisfiability was an entailment check,
- * i.e., a call to checkEntailed(a1, ..., an), then d_assumptions contains
- * one single assumption ~(a1 AND ... AND an).
*/
std::vector<Node> d_assumptions;
/** Whether we did a global negation of the formula. */
*
* Note that the per-call timer only ticks away when one of the
* SolverEngine's workhorse functions (things like assertFormula(),
- * checkEntailed(), checkSat(), and simplify()) are running.
+ * checkSat(), and simplify()) are running.
* Between calls, the timer is still.
*
* When an SolverEngine is first created, it has no time or resource
/**
* Whether or not a notifyCheckSat call has been made, which corresponds to
- * when a checkEntailed() or checkSatisfiability() has already been
+ * when a checkSatisfiability() has already been
* made through the SolverEngine. If true, and incrementalSolving is false,
* then attempting an additional checks for satisfiability will fail with
* a ModalException during notifyCheckSat.
bool d_needPostsolve;
/**
- * Most recent result of last checkSatisfiability/checkEntailed in the
+ * Most recent result of last checkSatisfiability in the
* SolverEngine.
*/
Result d_status;