Repository navigation
Windows: Imperfect operation #495
Description
Activity
I can't even compile VLS. When I run
v .I get:handlers.v:468:24: error: unexpected `or` block, the field `range` is not an Option or a Resultv --versiongives:V 0.5.1 0c3183cWith latest
V 0.5.1 9f57c74it compiles clean on Linux.There is a lot of "churn" in V right now. If you hit a problem,
v upand try again.I spent some time on this and got somewhere concrete. I could not reproduce the
VS Code popup itself — I have no editor here — but I found a failure mode on
Windows that produces exactly the reported shape, and it is silent.What "starts but never becomes active" looks like underneath
Highlighting does not need the V compiler: syntax colouring comes from the
client grammar, and semantic tokens come from VLS's own index. Completion, hover,
signature help and go to definition all do need it. They go through the
compiler like this:['-w', '-check', '-nocolor', '-vls-mode', '-line-info', '<file>:<line>:<col>', <target>]
-vls-modeand-line-infoare implemented by V's V1 compatibility compiler.
When that compiler is missing, the V launcher refuses and exits without compiling
anything. On my Windows machine that is the whole output of that command:`-vls-mode` requires the compatibility compiler, but no usable V 0.5.2 fallback was found and make is unavailable. Install make, then run `make v1` in `C:\Users\me\v`.VLS did not recognise that message. It only ever looked for a line reading
unknown option `-line-info`, so this refusal read as "the compiler had
nothing to say". The result: the language server starts and indexes normally, and
every compiler-backed request comes back empty forever, with nothing printed
anywhere. Highlighting works, the completion popup never appears. That is the
shape described here.It is a Windows-specific trap, because on Windows the V1 fallback is a separate
build step rather than somethingmakeproduces for you.How to check in about a minute
In your project directory, with your
v:v -vls-mode -line-info main.v:1:1 main.v- If it prints
requires the compatibility compileror`make v1` failed,
that is this bug. - If it prints JSON, your
-line-infopath is fine and the cause is elsewhere —
please say so and I will keep digging.
If it is the first case, the repair is in the message itself: install
make, then
runmake v1in your V source directory.Fix
#529 recognises the refusal, retires the
compiler-backed lookups instead of retrying them per keystroke, and sends one
window/showMessagenaming the repair. So a VLS in this state now says why
instead of just doing nothing.What I changed while getting here
Running the suite on Windows first turned up that
masteris not green, on any
platform, and never has been for the currentmaster:PR Problem #528 v fmt -verifyfails on 17 files, so CI dies before the test step on all three platforms#526 index_test.vandhandlers_test.vdo not compile —index_max_file_bytesbecameu64in #521 butstring.repeattakesint#527 The one Windows-only test failure: the Sublime Text handshake test interpolates a native path straight into a JSON string, and \Uis not a valid escape, so the handshake never ran on Windows at allThat last one matters here: it means the stdio handshake had no Windows coverage,
which is why #495 was hard to chase from the test suite. With it passing, the
handshake is verified on Windows.With all four applied the Windows suite is
5 passed, 1 failed, and the remaining
failure is three tests that need the V1 compatibility compiler — which is the very
thing this issue is about.Happy to keep going if you can confirm which of the two cases you are in.
- If it prints
Correction to my comment above, now that I have a working V1 compatibility
compiler on this machine.I wrote: "With all four applied the Windows suite is
5 passed, 1 failed, and the
remaining failure is three tests that need the V1 compatibility compiler — which
is the very thing this issue is about."That was true when I wrote it, but it undersold the result. Once
v1_fallback.exe
existed, those three tests passed as well:OK compilation_test.v OK index_test.v OK interop_test.v OK integration_test.v OK handlers_test.v OK lsp_test.v Summary for all V _test.v files: 6 passed, 6 total.So all four PRs together are fully green on Windows, and
masteris not — it does
not compile two of its own test files and its CI dies at the formatting gate
before the test step ever runs.I also used the missing fallback to check #529
against this exact condition rather than only against a stub. With
v1_fallback.exeremoved, a realrun_v_line_infocall now produces:{"jsonrpc":"2.0","method":"window/showMessage","params":{"type":2,"message":"vls: the V compiler on PATH cannot serve completion, hover, signature help, or go to definition, because its V1 compatibility compiler is missing. Install `make`, then run `make v1` in your V source directory, or point `v.vls.command` at a V that has it. Diagnostics and formatting are unaffected."}}Before that change the same situation said nothing at all.
Verified on Windows with a full editor round-trip. I could not reproduce the dead-popup symptom, and I found no vls defect behind it.
Environment
- Windows, VS Code 1.140.0, extension
vlanguage.vscode-vlang0.2.1 - V 0.5.2 (
bb0d229) - vls built from
upstream/master(436058d), and again from my fork with my open PRs merged. Identical behaviour in both, which is what rules my changes out.
Both popups appear, and the server works end to end
From vls's own log for the session:
VLS: negotiated positionEncoding=utf-16 VLS: watched-files registration acknowledged; watcher events drive index freshness RECV: textDocument/didOpen (main.v) main.v:14:2: error: unknown function: unused_broken_callThat error is produced by the V compiler and surfaced by vls as a diagnostic, so
didOpen-> compile ->publishDiagnosticsall work on V 0.5.2 here.What I did not verify: the completion popup itself inside VS Code. I confirmed completion over the same stdio transport by requesting it directly (a member access returns the real members
x,y,str), but I did not confirm the popup in the editor. So this is not a claim that your symptom is fixed on 0.5.1.One hypothesis that matches your symptom exactly, and is silent
If the V on PATH cannot reach the
-line-infochecker and also has no V1 compatibility compiler, vls answers from its own index instead of from the compiler, and says nothing. That produces exactly what you describe: code highlighting fine, popups dead, no error anywhere. PR #529 adds an explicit message for that case.So for the commit where you saw only
V Language Server is starting., it would help to have:- the output of
v version - whether a V1 compatibility compiler exists in your V directory (
v1_fallback.exe, or the equivalent on your platform) - whether
v -vandv -vls-modesucceed
Separate trap, not your symptom
Launching VS Code with a single file path and no folder loads no workspace settings, so
v.vls.commandstays unset and VLS fails with a genericFailed to start VLS. See output for details.Easy to hit, unrelated to the popup problem.- Windows, VS Code 1.140.0, extension
Follow-up to my previous comment: I have now verified the part I said I had not, namely the completion popup inside VS Code. It works.
Triggering a member completion at
p.(line 13) in the editor, vls's log shows the request and its own response:RECV: {"id":95,... "method":"textDocument/completion", "position":{"line":13,"character":2}} SEND: {"id":95,"result":{"isIncomplete":false,"items":[ {"kind":5,"label":"x","detail":"x int"}, {"kind":5,"label":"y","detail":"y int"}, {"kind":2,"label":"norm2","detail":"fn (p Point) norm2() int","insertText":"norm2()"}, {"kind":2,"label":"str","detail":"fn (x Point) str() string"}]}}The popup renders those four entries with the correct kinds, and the deliberate
unknown function: unused_broken_call()on the neighbouring line comes through as a diagnostic at the same time. 16 completion and 15 hover requests went over the wire in that session, so this is not a cached response.So on this machine, with V 0.5.2 (
bb0d229), VS Code 1.140.0 and extension 0.2.1, the full path works both for diagnostics and for popups:didOpen-> compile ->publishDiagnosticstextDocument/completion-> member list from the V compilertextDocument/hover-> results
Same result from a build of
upstream/master(436058d) as from my fork with my PRs merged.That does not close your report, because your failing case was V 0.5.1 and commit
5dd162f, which I have not reproduced. The question from my previous comment is still the one I would act on: whatv versionreports on that machine, and whether a V1 compatibility compiler is present in the V directory. If V cannot reach the-line-infochecker and has no V1 fallback, popups die silently while highlighting keeps working, which matches your description exactly. PR #529 makes that case announce itself instead of failing quietly.If anyone with the failing setup can post that
v versionoutput, that is enough to tell whether it is the same cause or a different one.Thanks for the detailed report. The silent failure you describe was fixed by #529 — VLS now detects the missing compatibility compiler and reports it instead of going quiet.
To close this out, could you share:
v version- whether a
v1compat compiler exists next to yourvbinary - the output of
v -vls-mode -line-info main.v:1:1 main.v
As far as I can tell, VLS no longer works correctly on Windows in V version 0.5.1 and later.
When the extension is launched, you will typically see two popups. These enable code highlighting (immediately) and popup functionality (after any changes have been made to the code).
It worked fine up to version 0.5.0, but in version 0.5.1, the popup function sometimes works and sometimes doesn’t.
In commit
5dd162f, only the following single popup appears, and only code highlighting works. The popup function does not work at all.