Bogus violation when checking liveness property [](FALSE ~> P)

Originally report in http://discuss.tlapl.us/msg04237.html

------ MODULE Github604 ------
EXTENDS Naturals

VARIABLE x

Next == x' \in 0..3

Spec ==  x = 0 /\ [][Next]_x /\ WF_x(Next) \* F
====

For some fairness property F, and constant-level liveness properties with a state predicate P (P does not hold):

Property	Rewritten To	Violation?	Bogus?	Comment
<>TRUE	F /\ ~<>TRUE	y	y	proved by TLAPS
<>x \in Nat	F /\ ~<>(x \in Nat)	n	n	state-level
<>[]TRUE	F /\ ~<>[]TRUE	n	n
<>FALSE	F /\ ~<>FALSE	y	n
<>[]FALSE	F /\ ~<>[]FALSE	y	n
[](TRUE=><>P)	F /\ ~[](~TRUE \/ <>P)	n	n
TRUE~>P	F /\ ~[](~TRUE \/ <>P)	n	n
[](FALSE=><>P)	F /\ ~[](~FALSE \/ <>P)	y	y
FALSE~>P	F /\ ~[](~FALSE \/ <>P)	y	y
FALSE~>FALSE	F /\ ~[](~FALSE \/ <>FALSE)	y	y
FALSE~>TRUE	F /\ ~[](~FALSE \/ <>TRUE)	y	y
TRUE~>FALSE	F /\ ~[](~TRUE \/ <>FALSE)	y	n
TRUE~>TRUE	F /\ ~[](~TRUE \/ <>TRUE)	n	n

“Rewritten To” in tlc2.tool.liveness.Liveness.processLiveness(ITool) applying https://en.wikipedia.org/wiki/Material_implication_(rule_of_inference) in case of leads-to.

Note: A constant-level invariant such as TRUE, TLC happily checks the specification without raising a warning. An invariant []TRUE is level-checked as temporal formula and, thus, reject by TLC with Error: The invariant Inv is not a state predicate (one with no primes or temporal operators)..

Related: https://github.com/tlaplus/tlaplus/issues/302

[lemmy]

@Calvin-L Great, we came to the same conclusion: https://github.com/lemmy/tlaplus/commit/462c2c891609ab57e1313fa2cae8b22618f607f6#diff-f996d325dd68aa45c6ad7c13094052819b4ba3e92f661c9e846e87d5ed083a05L42-L51

[Calvin-L]

I spent an hour looking into this. I have a hypothesis about the cause, although my understanding of TLC’s liveness-checking code is very sketchy.

The problem goes away if you change this line in TBGraphNode’s constructor. Replace:

if (ln instanceof LNState) {

with

if (ln instanceof LNState || ln instanceof LNBool) {

---

I’ll try to explain why I think that line might be significant. Here’s the spec I’m using:

---- MODULE LeadsTo ----

EXTENDS Naturals

VARIABLE x

Init == x = 0

Inc ==
    /\ x < 5
    /\ x' = x + 1

Reset ==
    /\ x' = 0

Next ==
    \/ Inc
    \/ Reset

Property ==
   [](TRUE \/ <>(x=3)) \* <---- the property to check, equivalent to (FALSE ~> (x=3))

====

TLC proves the property by trying to satisfy the property’s negation. So, it starts from

~[](TRUE \/ <>(x=3))

Simplification converts this to:

<>FALSE

The TBGraphNode constructor ignores the FALSE constant, since it is only looking for state expressions. Somehow this causes the tableau-based prover to give erroneous results. Including FALSE in the set of notable state expressions fixes the problem.

An alternative fix might be to improve the simplifier to convert <>FALSE to FALSE… Although, my intuition says that the liveness checking code should work even if fed boolean constants, and the simplification is just an optimization. Or, put another way: the simplifier’s contract is that it produces logically-equivalent expressions. The liveness checker’s contract is that it produces correct output on any input it accepts. (Although, I’m prepared to accept that TLC’s design philosophy could be different from my intuition.)