Spurious violation of an obvious temporal property

In the specification below, it appears that TLC silently ignores the third conjunct of the Spec definition. For this input I would expect either (1) no violation reported or (2) an error message indicating that TLC can’t check the specification as written.

(In this case, it is entirely possible that I have misunderstood the specification I wrote down. However, my intuition is that any property in the specification is a trivially-true temporal property.)

TrivialTemporalViolation.tla:

---- MODULE TrivialTemporalViolation ----

EXTENDS Naturals

VARIABLE x

Spec ==
    /\ x = 1
    /\ [][x' = x+1]_x
    /\ [](x = 1) \* harsh restriction that forbids behaviors where x changes

Liveness ==
    [](x = 1)

=========================================

TrivialTemporalViolation.cfg:

SPECIFICATION Spec
PROPERTY Liveness

$ tlc2 -deadlock TrivialTemporalViolation
TLC2 Version 2.15 of Day Month 20??
Running breadth-first search Model-Checking with fp 8 and seed -4070785743065743379 with 1 worker on 4 cores with 3641MB heap and 64MB offheap memory [pid: 62947] (Mac OS X 10.14.6 x86_64, Azul Systems, Inc. 11.0.1 x86_64, MSBDiskFPSet, DiskStateQueue).
Parsing file /Users/cloncari/sw/src/tla-examples/TrivialTemporalViolation.tla
Parsing file /private/var/folders/k0/tw__ldzn7r19gby9d93tffh40000gn/T/Naturals.tla
Semantic processing of module Naturals
Semantic processing of module TrivialTemporalViolation
Starting... (2020-10-29 17:58:21)
Computing initial states...
Finished computing initial states: 1 distinct state generated at 2020-10-29 17:58:21.
Error: Invariant Liveness is violated.
Error: The behavior up to this point is:
State 1: <Initial predicate>
x = 1

State 2: <Action line 9, col 11 to line 9, col 18 of module TrivialTemporalViolation>
x = 2

2 states generated, 2 distinct states found, 0 states left on queue.
The depth of the complete state graph search is 2.
Finished in 00s at (2020-10-29 17:58:21)

[lemmy]

I’ve already started looking at SpecProcessor.java on how to make TLC issue a warning. SpecProcessor could reject formulas starting with the box operator followed only by a state-level formula S, i.e. []S. This still allows meaningful fairness constraints such as weak fairness ([]<>(ENABLED <<A>>_v => <<A>>_v). However, this would miss variants of []S such as ~<>~S. Perhaps, this is good enough given that TLC errors with “<> followed by action not of form <>_v” for a spec formula Init /\ ~<>~[Next]_v.

[Calvin-L]

Looks good to me!