Skip to content

Attach the receiver's states to state refinement errors - #421

Merged
CatarinaGamboa merged 1 commit into
mainfrom
feat/state-error-context
Oct 24, 2026
Merged

CatarinaGamboa merged 1 commit into
mainfrom
feat/state-error-context

Conversation

@CatarinaGamboa

Copy link
Copy Markdown
Collaborator

Why

The VS Code extension shows a state machine with the rejected call highlighted. Today liquidjava-fsm works out the receiver's possible and accepted states again by reading the text of the error's expected and found predicates. The verifier has already computed both with the SMT solver, and the text reading can disagree with it, for example with guarded from clauses, old(...) or several state sets. This PR exposes the verifier's answer, so fsm can go back to only drawing the diagram.

What

StateRefinementError#getContext() returns a StateErrorContext, or null when the states could not be computed:

Field Example
receiver f (as written; this if implicit)
receiverClass testSuite.ErrorStateHintCallSequence
method read() (same format as the hints)
possibleStates [["created"]]
acceptedStates [["open"]], or null when they depend on the arguments
complete whether every method that changes the state is known

Each state lists its name in every state set, in declaration order, e.g. ["closed", "locked"]. The states stay combined because projecting them onto each set separately would mark states as accepted that are not.

To support this, State now keeps its per-set names, and name() still joins them with " and " for the hints. Hints and the category already reach clients through LJDiagnostic.

Tests

TestStateErrorContext covers a single state set, several state sets, a path-dependent state, an argument-dependent transition (accepted states unknown, machine incomplete) and a class without a state set (no context). mvn test: 492 tests pass.

🤖 Generated with Claude Code

StateRefinementError now carries a StateErrorContext with the receiver,
its class, the called method, the states the receiver can be in, the
states that allow the call (per state set) and whether the state machine
is complete, so clients can show the verifier's answer instead of
re-deriving it from the predicates' text.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@CatarinaGamboa
CatarinaGamboa merged commit 440097e into main Oct 24, 2026
1 check passed
CatarinaGamboa added a commit to liquid-java/vscode-liquidjava that referenced this pull request Oct 25, 2026
## Why
Until now, the state machine view got the receiver's possible and
accepted states from liquidjava-fsm, which re-read the error's
`expected` and `found` predicates as text. The verifier now computes
those states with the SMT solver and reports them on
`StateRefinementError#getContext()` (liquid-java/liquidjava#421). fsm
0.2.0 dropped its error context and only draws diagrams
(liquid-java/liquidjava-fsm#12). This PR switches the view to the
verifier's answer, so the diagram never contradicts the error next to
it.

## What
**Dependencies:** liquidjava-verifier 0.0.36, liquidjava-fsm 0.2.0 and
Spoon 11.5.0, the version the verifier now uses.

**Server**
- `StateRefinementErrorDTO` builds the diagram with
`StateMachineParser.parse(declaration file, context.receiverClass())`,
so a file that declares several classes shows the receiver's class.
- The new `StateMachineDTO` and `StateErrorContextDTO` keep the shape
the webview already reads (`stateMachine.errorContext`). The error
context now has `calledMethod`, `receiver`, `possibleStates`,
`acceptedStates`, `validStates` and `invalidStates`.
- The verifier names each state in every state set. The diagram shows
the first set, and a state is marked so that the marks are never wrong:
- It is **valid** only if the call is accepted in *every* possible
combination with that state.
  - It is **invalid** only if the call is accepted in *none* of them.
- Otherwise it stays unmarked. When the accepted states depend on the
arguments, nothing is marked.
  - With one state set, this gives the same marks as before.

**Client**
- `getStateErrorFocus` uses the server's lists directly. The fallbacks
to `definiteFoundState` and `actualStates` are gone, and so are
`expectedCondition` and `foundCondition`, which nothing displayed.

**Fixed:** the `setHint` test, which broke when hints became a list
(liquid-java/liquidjava#410).

Output for the fsm study fixtures (DatagramSocket and tree node),
serialized by the server:
```json
{"calledMethod":"receive","receiver":"socket","possibleStates":["bound","closed"],"acceptedStates":["unbound","bound","connected"],"validStates":["bound"],"invalidStates":["closed"]}
{"calledMethod":"getFirstChild","receiver":"root","possibleStates":["childrenAllowed"],"acceptedStates":["maybeHasChildren"],"validStates":[],"invalidStates":["childrenAllowed"]}
```
These are the same marks the view showed before for these examples.

## Follow-ups
- One diagram per `@StateSet` (#115, #116,
liquid-java/liquidjava-fsm#8), e.g. ImageWriteParam.
- Send the hints as a list (with their kind) and the error category.
- Cache the diagram per class instead of parsing the file for each
error.

## Tests
- Server: `mvn test`, 27 tests pass, including the new
`StateErrorContextDTOTest`: one state set, several sets with a partly
accepted state, and unknown accepted states.
- Client: `vitest`, 71 tests pass, and `tsc` is clean.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant