Changing Runtimes

[markdiener10]

Hello, is there a fairly quick way to bring linter "staticcheck" into synchronization with the installed golang compiler on a local machine.

I am making runtime and language syntax changes and compiling and linking new versions of the golang compiler but the new compiler works on my Mac M1 laptop under VSCode, but the linter is triggering the following errors:

sample.go:3:16: illegal character U+0023 '#' (compile)
sample.go:8:2: expected ';', found 'EOF' (compile)

Of course, the legacy version of the linter is not aware of my language syntax changes (which are working in the debugger) but triggering warnings by the linter in VSCode.

How can I trigger staticcheck to rebuild itself using the modified golang environment with new golang language syntax so that it follows with the custom golang compiler?

Any comments appreciated.

[markdiener10]

Maybe something like:

go rebuild honnef.co/go/tools/cmd/staticcheck@latest --compiler=/Users/godev/newcompiler/bin

go install honnef.co/go/tools/cmd/staticcheck@latest

Or if necessary, git clone, rebuild staticcheck locally.

[dominikh]

If you are changing the syntax of Go, then it is not enough to do so in the compiler, you also need to update go/scanner, go/parser, and go/ast, or Staticcheck (or any other tool) will not be able to parse your code.

[markdiener10]

Hello Dominikh:

Yes, those changes to scanner/parser/ast were effected successfully and running 100% correctly in the delve debugger inside VSCode. But the linter was triggering illegal character warnings that I know want staticcheck to interpret correctly. My question was how to trigger an update to staticcheck to bring it into sync with the updated compiler and the other tools.

Should I just clone the staticcheck repo and build it and run it locally?

[markdiener10]

Kind of skip the whole "go install" step and build it locally from source?

[dominikh]

As long as the correct (your modified) version of Go is in PATH, just reinstalling Staticcheck with go install should do the trick. The same has to be the case when running it. There's really nothing special in that regard, just build it with the right version of Go, and make sure it'll invoke the right version of Go. Whether you use go install on the module path for that, or build it locally, shouldn't matter much.

Of course you'll also want to make sure that VSCode is using the correct binary for Staticcheck — I believe the vscode-go extension installs Staticcheck for you, so it might be using a different binary.