[v0.2.717] error: column is beyond end of line #801
Comments
|
Hi, thanks for the bug report, we have a guide on troubleshooting, if you follow this then you should end up with some more logs to help diagnose: https://templ.guide/commands-and-tools/ide-support#troubleshooting-1 |
|
For some reason, the plugin creates an empty log file. [Info - 12:41:42] 2024/06/22 12:41:42 Created View (#1)
directory=/home/marco/Documents/vscode/website
view_type="GoMod"
root_dir="file:///home/marco/Documents/vscode/website"
go_version="go version go1.22.4 linux/amd64"
build_flags=[]
env={GOOS:linux GOARCH:amd64 GOCACHE:/home/marco/.cache/go-build GOMODCACHE:/home/marco/go/pkg/mod GOPATH:/home/marco/go GOPRIVATE: GOFLAGS: GO111MODULE: GoVersion:22 GoVersionOutput:go version go1.22.4 linux/amd64
ExplicitGOWORK: EffectiveGOPACKAGESDRIVER:}
env_overlay=[]
[Info - 12:41:43] 2024/06/22 12:41:43 go/packages.Load #1
view_id="1"
snapshot=0
directory=/home/marco/Documents/vscode/website
query=[/home/marco/Documents/vscode/website/... builtin]
packages=12
duration=200.058423ms
[Error - 12:41:47] Request textDocument/codeAction failed.
Message: column is beyond end of line
Code: 0
[Error - 12:42:04] Request textDocument/codeAction failed.
Message: column is beyond end of line
Code: 0
[Info - 12:42:13] 2024/06/22 12:42:13 background imports cache refresh starting
[Info - 12:42:13] 2024/06/22 12:42:13 background refresh finished after 204.122742ms |
|
I'm running into the same issue, also running the latest commit because of the LSP crashing. It happens with this simple template ( think the Doctype triggers it ). I've ran the diagnostics steps, these are my logs And this is my |
|
@advdv These logs are interesting. It seems that a publish diagnostic notification is being triggered for a go file |
|
@joerdav I've setup a full repo that triggers the error for me: https://github.com/crewlinker/templ-reproduce Logs with this project: and |
|
I've narrowed this down then just to vscode, none of this happens in the nvim client! Will do some more digging. |
|
But struggling to reproduce actually even in vscode. My vscode version is older though so maybe that's it, will update. |
|
@joerdav today I opened my VSCode and the explorer looks like this, maybe it's a hint as to what is going on. I'm pretty sure that this was not like this yesterday. But I've also removed other extensions so it's hard for me to say why/when it happened: Screen.Recording.2024-06-26.at.06.01.54.mov |
|
I've updated everything this morning to the latest tagged versions:
|
|
Great! Glad it's working, as for the explorer, generated files are now displayed as children of the templates. This can be overridden if it isn't desirable for you. |
|
@joerdav sorry, I've just ran again into this issue again with the latest version. Edit: here are the latest logs from the 'templ-reproduce' repo I've uploaded. I've updated the repo to the latest version. |
|
I think this is a legit issue, see #817 |
|
I installed the fix but I'm still having the same issue unfortunately. |
|
Sadly this still happens for me with the fixes in #817, using version It seems to trigger in particular when the cursor moves through different contexts, e.g. |
|
Also for me this doesn't solve the issue unfortunately. Let me know if there is anything else I can provide to make it easier to fix this |
|
OK, I've updated gopls with: And: And I've updated VS Code to v1.90.2. And I can reproduce the issue easily. However, there's nothing really useful in the logs. I'll add some more detail to help me debug. |
|
OK, with the extra logging I could see that the templ file code position wasn't being re-written to the Go code position, because the position within the templ file was not actually a Go expression, so the LSP was sending through the position within the templ file, hence it being outside of what gopls knows about. This didn't happen previously, so I assume that an update to VS Code and/or gopls has surfaced the behaviour. If someone can confirm the fix for them, I'll push a new release. |
|
Works for me. Might be a different issue though. |
Same for me in NeoVim: 
|
|
Yay, the error was fixed for me too! But autocomplete is also not working for me in VS Code. At one point (before this error message became a permanent issue for me), autocomplete worked. |
|
Yes, I see that. Thanks. The LSP is returning results but they're not showing in editors any more. I need to do some more investigating. Could be that gopls has changed its result shape or some other value is being set differently. The templ LSP tests are still passing, so it makes me think it's likely that the gopls behaviour has changed. |
|
It does seem to still pop up under certain conditions. I could only get it to show by selecting text as shown, but after a few times of trying to nail down the exact conditions I couldn't get it to show up again.
|
|
Hello I have the same issue, if I revert gopls to version 0.15.3 with |
this only work for nvim |
It's about the LSP, the editor is irrelevant. |
Owh sorry my bad, after reopen my vscode that work properly |
|
I've tracked down the issue. In {
"detail": "func(c complex128, fmt byte, prec int, bitSize int) string",
"documentation": {
"kind": "markdown",
"value": "FormatComplex converts the complex number c to a string of the form (a+bi) where a and b are the real and imaginary parts, formatted according to the format fmt and precision prec.\n\nThe format fmt and precision prec have the same meaning as in FormatFloat. It rounds the result assuming that the original was obtained from a complex value of bitSize bits, which must be 64 for complex64 and 128 for complex128.\n"
},
"filterText": "FormatComplex",
"insertTextFormat": 2,
"kind": 3,
"label": "FormatComplex",
"sortText": "00001",
"textEdit": {
"newText": "FormatComplex(${1:})",
"range": {
"end": {
"character": 73,
"line": 105
},
"start": {
"character": 73,
"line": 105
}
}
}
}But in v16, they've changed shape: {
"detail": "func(c complex128, fmt byte, prec int, bitSize int) string",
"documentation": {
"kind": "markdown",
"value": "FormatComplex converts the complex number c to a string of the form (a+bi) where a and b are the real and imaginary parts, formatted according to the format fmt and precision prec.\n\nThe format fmt and precision prec have the same meaning as in FormatFloat. It rounds the result assuming that the original was obtained from a complex value of bitSize bits, which must be 64 for complex64 and 128 for complex128.\n"
},
"filterText": "strconv.FormatComplex",
"insertTextFormat": 2,
"kind": 3,
"label": "strconv.FormatComplex",
"sortText": "00001",
"textEdit": {
"insert": {
"end": {
"character": 72,
"line": 105
},
"start": {
"character": 65,
"line": 105
}
},
"newText": "strconv.FormatComplex(${1:})",
"replace": {
"end": {
"character": 76,
"line": 105
},
"start": {
"character": 65,
"line": 105
}
}
}
}The LSP library I use (I forked it a while ago so that I didn't have to wait for PRs to get merged to make changes), doesn't support that structure: https://github.com/go-language-server/protocol/blob/dd685d4561a3ff05f82d25b51346f3c83ce5f918/language.go#L260 So, I need to update the protocol library to support a union of both types. I have it working locally. |
|
I've updated protocol in a-h/protocol@1e461c1 And I've updated templ in 26c1d79 On the "end of line" thing, I think there's another potential way that it could happen where if you've got an invalid line, the templ generation can't happen, so the Go mapping might not have updated, resulting in an out-of-bounds position being sent. I've added a commit to bc6e65a |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Getting this error in vscode output
I'm running a patch version to work around the upcoming fix for the panic
Is there any way I could get a nice stacktrace so that I can find which file and what is causing this particular error?
I don't even know which template to share because I don't know what is causing the error.
Thank you
The text was updated successfully, but these errors were encountered: