Problem
The browser playground exposed a completion behavior that appears to come from a native-vs-WASM difference in slang's syntax recovery for incomplete SystemVerilog code. Like #186 reported.
For an incomplete named port connection like:
module child(output wire y);
endmodule
module top;
child u0(
.
);
endmodule
with completion requested immediately after the dot, the native path and the WASM path do not classify the context the same way.
Observed Behavior
In the native server path, completion context detection sees the incomplete . as a recovered NamedPortConnection and classifies the position as:
PortConnectionName, source = Ast(NamedPortConnection)
In the browser/WASM path, the server receives the same text line and offset, but context detection falls back to parser expected syntax:
PortConnection, source = Parser
That broader context produces full port-connection snippets such as:
Because Monaco has already inserted the trigger character ., accepting the completion produces:
Why This Needs Investigation
The immediate completion case can be handled by using the LSP trigger character: when the trigger is . and slang reports ExpectedPortConnection, Vide should complete the port name after the dot instead of inserting another full .port(...) snippet.
However, the underlying difference is broader than this one completion item. Other IDE features may also depend on slang recovering incomplete AST nodes consistently across native and WASM builds, especially completion contexts that run while the user is in the middle of typing invalid or partial syntax.
Suggested Investigation
Compare native and wasm32-unknown-emscripten behavior for the same incomplete snippets:
SyntaxTree::from_text
SyntaxTree::expected_syntax_at_offset
find_node_at_offset::<NamedPortConnection>
- token before/after the cursor
- covering element at the cursor
Start with incomplete named port connections, then audit nearby completion contexts that rely on recovered AST nodes rather than only parser expected syntax.
The goal is to determine whether the difference comes from slang itself, the Emscripten build configuration, allocator / ABI assumptions, optimization flags, or how Vide initializes/parses files in the browser server path.
Problem
The browser playground exposed a completion behavior that appears to come from a native-vs-WASM difference in slang's syntax recovery for incomplete SystemVerilog code. Like #186 reported.
For an incomplete named port connection like:
with completion requested immediately after the dot, the native path and the WASM path do not classify the context the same way.
Observed Behavior
In the native server path, completion context detection sees the incomplete
.as a recoveredNamedPortConnectionand classifies the position as:In the browser/WASM path, the server receives the same text line and offset, but context detection falls back to parser expected syntax:
That broader context produces full port-connection snippets such as:
Because Monaco has already inserted the trigger character
., accepting the completion produces:..y(expr)Why This Needs Investigation
The immediate completion case can be handled by using the LSP trigger character: when the trigger is
.and slang reportsExpectedPortConnection, Vide should complete the port name after the dot instead of inserting another full.port(...)snippet.However, the underlying difference is broader than this one completion item. Other IDE features may also depend on slang recovering incomplete AST nodes consistently across native and WASM builds, especially completion contexts that run while the user is in the middle of typing invalid or partial syntax.
Suggested Investigation
Compare native and
wasm32-unknown-emscriptenbehavior for the same incomplete snippets:SyntaxTree::from_textSyntaxTree::expected_syntax_at_offsetfind_node_at_offset::<NamedPortConnection>Start with incomplete named port connections, then audit nearby completion contexts that rely on recovered AST nodes rather than only parser expected syntax.
The goal is to determine whether the difference comes from slang itself, the Emscripten build configuration, allocator / ABI assumptions, optimization flags, or how Vide initializes/parses files in the browser server path.