Check your installed extensions to get the version of the VS Code Go extension
Share the Go related settings you have added/edited
Run Preferences: Open Settings (JSON) command to open your settings.json file.
Share all the settings with the go. or ["go"] or gopls prefixes.
Describe the bug
Starting vscode with a go project with a workspace including: "go.buildFlags": ["-o='built/output.wasm'"] the go extension complains that "go list" doesn't support the "-o" flag.
The error is:
Error loading workspace: err: exit status 2: stderr: flag provided but not defined: -o usage: go list [-f format] [-json] [-m] [list flags] [build flags] [packages] Run 'go help list' for details. : packages.Load error
A clear and concise description of what you expected to happen.
...I'd expect the workspace to load w/o any complain, since the "-o" flag should be used in "go build"
The text was updated successfully, but these errors were encountered:
@squeeze69 What is the goal of adding -o into the go.buildFlags? The build flags are used to build/vet/test every package in the project and I am afraid -o doesn't fit there. The vscode go extension doesn't run go build any longer, that means, even with the workaround cl/325889 tries to do, it will not do what you expect. I agree that the settings documentation needs to clarify this fact.
If your goal is to run go build and produce the output, I think VSCode's Task may be a better fit for the problem. https://code.visualstudio.com/docs/editor/tasks. It's unfortunate that VSCode doesn't support "Run task on save" feature natively so currently you may need to depend on third-party extensions, or manually invoke the build task (for example, if you place the go build task as the "build" kind, default task, you can trigger it with Cmd+Shift+B on mac). What do you think?
Hi, it could be an interesting workaround, thanks, but the current settings were ok before a go plugin update (I really don't remember when it stopped working).
BTW, IMHO, every build flag accepted by the build command should be allowed, not a subset common to go list, etc... Maybe a filter would be enough? Or a new setting go.testBuildFlags which override go.buildFlags in test cases (only if present, of course)?