LSP - gopls command error

[Urkem]

Describe the bug
In version v0.2.771 when starting the VS Code extension the following templ.log is generated

{"level":"info","ts":"2024-08-24T07:10:33+02:00","caller":"lspcmd/main.go:76","msg":"lsp: starting up..."}
{"level":"info","ts":"2024-08-24T07:10:33+02:00","caller":"lspcmd/main.go:83","msg":"lsp: starting gopls..."}
{"level":"info","ts":"2024-08-24T07:10:33+02:00","caller":"lspcmd/main.go:96","msg":"creating gopls client"}
{"level":"info","ts":"2024-08-24T07:10:33+02:00","caller":"lspcmd/main.go:101","msg":"creating proxy"}
{"level":"info","ts":"2024-08-24T07:10:33+02:00","caller":"lspcmd/main.go:106","msg":"creating templ server"}
{"level":"info","ts":"2024-08-24T07:10:33+02:00","caller":"lspcmd/main.go:115","msg":"starting debug http server","addr":"localhost:7575"}
{"level":"info","ts":"2024-08-24T07:10:33+02:00","caller":"lspcmd/main.go:124","msg":"listening"}
{"level":"error","ts":"2024-08-24T07:10:33+02:00","caller":"pls/main.go:100","msg":"gopls command error","error":"fork/exec /home/urosm/go/bin: permission denied","stacktrace":"github.com/a-h/templ/cmd/templ/lspcmd/pls.newProcessReadWriteCloser.func1\n\t/home/urosm/go/pkg/mod/github.com/a-h/[email protected]/cmd/templ/lspcmd/pls/main.go:100"}
{"level":"info","ts":"2024-08-24T07:10:33+02:00","caller":"lspcmd/main.go:132","msg":"goplsConn closed"}
{"level":"info","ts":"2024-08-24T07:10:33+02:00","caller":"lspcmd/main.go:134","msg":"shutdown complete"}

Permissions for gopls did not change between versions

ls -l /home/urosm/go/bin/gopls
-rwxr-xr-x 1 urosm urosm 33014453 Aug 24 06:37 /home/urosm/go/bin/gopls

Downgrading do v0.2.747 fixed the issue.

To Reproduce
Run the latest templ version with the VS Code extension, running templ lsp works in both versions.

Desktop

• OS: Linux
• templ: v0.2.771
• Go: go1.23.0 linux/amd64
• gopls: v0.16.1

[a-h]

Ah, I see it.

https://github.com/a-h/templ/blame/13f712b3766bc9d186213622b1ecd43a63b59afb/cmd/templ/lspcmd/pls/main.go

You don't have gopls on your path, so it's getting past the LookPath section of FindGopls, but I made a change that sets the executableName to the result, even if there's an error.

This meant that when the locations are constructed, the path becomes /home/urosm/go/bin instead of /home/urosm/go/bin/gopls.

This behaviour is relatively hard to test because it uses the state of the overall operating system - environment variables, files at particular paths etc. hence the bug.

I'll push a new release. Just out of interest, are you running Linux, or are you actually running Windows Subsystem for Linux?

[Urkem]

I'm using Arch Linux Linux 6.10.6-arch1-1.

Yea you are right I only have /home/urosm/go/bin in my path not /home/urosm/go/bin/golps didn't think of checking it since the logs pointed out permission issues.

[a-h]

The new templ info command provides some information about the state of environments.

On my Mac it shows this:

(✓) os [ goos=darwin goarch=arm64 ]
(✓) go [ location=/run/current-system/sw/bin/go version=go version go1.22.5 darwin/arm64 ]
(✓) gopls [ location=/Users/adrian/go/bin/gopls version=golang.org/x/tools/gopls v0.16.1 ]
(✓) templ [ location=/Users/adrian/go/bin/templ version=v0.2.773 ]