Repository navigation
Conversation
metif12
force-pushed
the
feat/walkthrough-debug
branch
from
October 9, 2026 19:27
ce1285c to
6e1f3fc
Compare
`v -check`, `v vet -W` and `v fmt -verify` are the three gates the rest of a change hangs on. The v-workflow skill documents them as the two that gate everything else, and none of them was reachable from the extension — a user had to find a terminal. Each works on the active file when one is open, and on the workspace otherwise, matching how Run and Test already behave. All three surface through the `vls` problem matcher, so a failure lands in the Problems panel at the right line rather than only in the task output. The flags were verified against the compiler rather than assumed: | command | clean | problem | |---|---|---| | `v -check file.v` | exit 0 | exit 1 | | `v vet -W file.v` | exit 0 | exit 1 on warnings | | `v fmt -verify file.v` | exit 0 | exit 1 when not formatted | `v vet -W` is the one to use in CI, since it treats warnings as errors. The task enum grows to six actions, and every enum entry now has a description — a bare word in a task picker gives a user no idea what it runs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was no onboarding. Tasks, CodeLens, coverage and the agent commands were only discoverable from the README, so a user who did not read it had no way to learn that `V: Check` or the coverage status item existed. The walkthrough has three steps, each completing when the command it describes has been run: 1. install V 2. build, run and test 3. check, vet and format That means the walkthrough walks a new user through the extension's own commands rather than asking them to read documentation first, and it is also the natural home for the agent features when those land. The agents step is deliberately absent. It would describe `v mcp` and `v skills`, which are not on this branch, and a walkthrough step for a command that does not exist is worse than no step. It can be added when vlang#558 and vlang#559 merge. A test checks the walkthrough rather than trusting it: every step must have a title, a description and a media file that exists in the repository, and every completion event must name a declared command. I confirmed it catches something by pointing a step at a missing file and watching it fail, then reverting.
The Check/Vet commit removed prod from the taskSpec type, the workspace spec, the title, the dash-guard and activeBuildTaskSpec, while vTasks, the manifest, the provider and the tests all still assume it - the bundle cannot even build. The commit message celebrates six actions but the manifest it ships lists seven with prod, so the deletion reads as accidental loss, not intent. Restores the upstream lines verbatim. Suite: bundle builds; only the six known Windows failures remain.
Fourth step pointing at walkthrough/debugging.md: default launch config, Debug Main lens, pretty printers, gdb requirement, troubleshooting pointer. No completionEvents: the debug commands live on the debugger stack, and the manifest test requires named commands to exist, so the step checks off manually. Lands after the debugger stack.
metif12
force-pushed
the
feat/walkthrough-debug
branch
from
October 10, 2026 04:46
6e1f3fc to
e809227
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #562 (needs the tasks PR first); lands after the
debugger stack #567–#578, whose commands the new step names.
P1-1's open note said the walkthrough should gain a debugging step
once D1 lands. Fourth step with
walkthrough/debugging.md: defaultlaunch configuration, Debug Main lens, pretty printers, gdb
requirement, troubleshooting pointer. No
completionEvents— thedebug commands live on the debugger stack and the manifest test
requires named commands to exist, so the step checks off manually.
Includes a blocking repair found on the way: #562's own commit
removed
prodfrom the taskSpec type, spec, title andactiveBuildTaskSpecwhile vTasks, the manifest, the provider andthe tests all still assume it, so the test bundle cannot build.
The commit message celebrates six actions but the manifest it ships
lists seven with prod; the deletion reads as accidental loss, so the
upstream lines are restored verbatim (separate commit). Suite: bundle
builds; only the 6 known Windows failures remain.