Skip to content

Record constructor signatures on initial state transitions - #1

Merged
CatarinaGamboa merged 1 commit into
mainfrom
feat/112-constructor-signatures
Oct 6, 2026
Merged

CatarinaGamboa merged 1 commit into
mainfrom
feat/112-constructor-signatures

Conversation

@CatarinaGamboa

Copy link
Copy Markdown
Contributor

Summary

Record the constructor signature on each initial state transition so the VS Code diagram can show which constructor leads to each state. This covers overloaded constructors, conditional constructor postconditions, interface declarations for external refinements, and constructors that use the default first state.

Supports liquid-java/vscode-liquidjava#112. The matching extension change is in a separate PR.

Verification

  • mvn test passed: 20 tests, including overloaded constructors that reach the same state and constructors without explicit state annotations.
  • A locally built server and VS Code webview rendered both new MultipleInitialStates() and new MultipleInitialStates(int) on their respective arrows.

Integration note

The extension currently depends on the published liquidjava-fsm 0.1.0 artifact. For local end-to-end testing, install this branch with mvn install before rebuilding the extension server. A new FSM artifact version and corresponding server dependency update will be needed before the extension change can be released.

String className, String firstState) {
Collection<? extends CtExecutable<?>> constructors = getConstructorElements(ctType, className);
if (constructors.isEmpty()) {
String implicitConstructor = ctType instanceof CtClass<?> ? "new " + className + "()" : null;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the "new" + className really necessary? It's a bit verbose, especially when there are a lot of constructors.

Image

How about just constructor(params) or just (params)?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this is the most accurate description, but its true that it might be a bit verbose, I would say to keep this and then see if its too verbose for the most complex examples we can reduce it

@CatarinaGamboa
CatarinaGamboa merged commit 27d6ab2 into main Oct 6, 2026
CatarinaGamboa added a commit to liquid-java/vscode-liquidjava that referenced this pull request Oct 20, 2026
## Summary

Show the constructor signature on each initial state machine arrow. Keep
conditional postconditions available under the existing Expand
Conditions toggle, and accept responses from older servers that lack
signature metadata.

Implements the diagram side of #112. Parser metadata comes from
liquid-java/liquidjava-fsm#1.

## Verification

- Client webpack compile and server Maven build passed.
- Headless VS Code diagnostic smoke test passed.
- In a live VS Code webview built with the FSM parser branch, the state
machine rendered `new MultipleInitialStates()` and `new
MultipleInitialStates(int)` on separate initial arrows.

## Local review

1. Check out liquid-java/liquidjava-fsm#1 and run `mvn install` there.
2. Check out this PR, then run `npm ci` and `npm run build:server` in
`client`.
3. Open `client` in VS Code and press F5. In the Extension Development
Host, open a Java class with overloaded state-refined constructors and
view its State Machine tab.

The server still pins the published FSM 0.1.0 dependency. Maven must use
the locally installed parser build for this test; a new FSM artifact
version and server dependency update are needed before release.

---------

Co-authored-by: Claude Opus 5.5 (1M context) <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.

2 participants