You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
State Machine view: a call declared in a subclass's spec shows the superclass's diagram without the call, and marks no states #173
Impact: when a state error is on a method declared in a subclass's external spec, but the state set is declared in a superclass's spec, the State Machine view shows the superclass's diagram without the failing method, and it marks no states. It shows only "Invalid method call at line N". In that case the diagram can't explain the error.
Minimal reproducer: the spec and client from liquid-java/liquidjava#456 (state set on java.awt.Window, setUndecorated on java.awt.Frame, host.pack(); host.setUndecorated(true);). The extension main @ 80bed18 server was built against verifier main @ 19991d36.
Actual: the error's stateMachines has one machine, java.awt.Window, with transitions dispose and pack only, and errorContext: null. The view shows the Window diagram with no actual or expected state and no setUndecorated edge.
Expected: the receiver's class (java.awt.Frame), with the inherited state set and the methods from both specs (dispose, pack, setUndecorated). It should mark displayable as the actual state, notDisplayable as the expected one, and setUndecorated as the failing call. That is what the view shows when the same methods are in one @ExternalRefinementsFor("java.awt.Frame") interface: machine java.awt.Frame, with errorContext {calledMethod: setUndecorated, possibleStates: [displayable], acceptedStates: [notDisplayable]}.
Where.StateRefinementErrorDTO builds the machines with StateMachineParser.parseAll(<declaration file>, receiverClass) (liquidjava-fsm). It reads only the declaration's file and the class that declares the state set. Merging the specs of the receiver's superclasses would fix the diagram.
The null errorContext may also come from the verifier side. The verifier gives no state hints in the same case (liquid-java/liquidjava#456), so check whether its StateErrorContext is missing too.
Real-world scenario. One of the exercises for the error-message study is LITIENGINE's GameWindow, which calls setUndecorated(true) on a displayable frame. For that exercise the State Machine tab shows java.awt.Window with no states marked, and the fix (dispose() first) can't be read from it.
In VS Code (LITIENGINE study exercise, verifier main @ 19991d36, extension main @ 80bed18). The State Machine tab shows java.awt.Window without setUndecorated, with no states marked:
Activity