Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

go/parser: invalid block comment end position with CRLF line endings #42646

Closed
incansvl opened this issue Nov 11, 2020 · 6 comments
Closed

go/parser: invalid block comment end position with CRLF line endings #42646

incansvl opened this issue Nov 11, 2020 · 6 comments
Labels
FrozenDueToAge
Milestone
gopls/v0.5.4

Comments

@incansvl
Copy link

What version of Go, VS Code & VS Code Go extension are you using?

go: go1.15.4 windows/amd64
VSCode: 1.51.0
Extension: 0.18.1
Env:

set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\coev\AppData\Local\go-build
set GOENV=C:\Users\coev\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\coev\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\coev\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\coev\Documents\Development\eprom\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\coev\AppData\Local\Temp\go-build248616018=/tmp/go-build -gno-record-gcc-switches

Share the Go related settings you have added/edited

{
    "go.useLanguageServer": true
}

(Note: the above is strange, because in the extension settings UI the option "Go: Use Language Server" is NOT selected?? However toggling this setting does not change the behaviour of the bug)

Describe the bug

Starting with a go file that includes a section of code commented out as a block with /* and */, when I save the file VSCode alters the file before saving corrupting the code. This does not happen if the code does not contain the block comment.

Expected behaviour: Save the code as displayed

Steps to reproduce the behavior:

  1. Set up VSCode with the Go 0.18.1 extension (bug reproduced both with and without other extensions loaded)
  2. Rename the test case file "vscode_go_save_bug_before_saving.go.txt" to remove the ".txt" extension and open it
  3. Save the file (File->Save or ctrl-S)
  4. The file is damaged BEFORE save, so it is corrupted both on disk and on screen in the editor. The result is shons in file vscode_go_save_bug_after_saving.go.txt (again, remove the .txt extension)

vscode_go_save_bug_before_saving.go.txt
vscode_go_save_bug_after_saving.go.txt
@stamblerre
Copy link
Contributor

What is the output of gopls version?

@incansvl
Copy link
Author

I had already upgraded the gopls extension by the time I saw your reply, so I'm afraid I don't know what version it was originally.

Having run the Go: Install/Update Tools command I thought the console said the plugin had been updated to v1.51.1, however a few minutes later, after a few unsuccessful test-saves of the test go file, I go a prompt to upgrade gopls, but the "upgrade" then said it had installed v0.5.3, so I now realise the 1.51.1 must have been the version of VSCode itself.

None of these changes have fixed the original problem, VSCodeis still mangling the file sytax whenever a go file with a block comment is saved. I checked, and commenting out the same block with multiple "//" single line comment rather than the "/* */" block comments works ok, so it does seem to be the block comment syntax that is the issue.

I also tried disabling the gopls "Use Language Server" setting. If I disable this in BOTH the Workspace and User settings, then saving works as expected, but if gopls is enabled in either setting the problem manifests.

@stamblerre stamblerre transferred this issue from golang/vscode-go Nov 16, 2020
@stamblerre stamblerre changed the title VSCode alters/corrupts source file on save if code contains a block comment x/tools/gopls: corrupted file with block comment and CRLF line endings Nov 16, 2020
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Nov 16, 2020
@gopherbot gopherbot added this to the Unreleased milestone Nov 16, 2020
@stamblerre
Copy link
Contributor

Thank you for following up--I was able to reproduce this with CRLF line endings. You can try changing your line endings (in the right bottom corner of the VS Code window) to LF to avoid this problem in the meantime (gofmt defaults to LF anyway).

@stamblerre
Copy link
Contributor

stamblerre commented Nov 16, 2020 •
edited

This appears to be another instance of a go/parser bug with CRLF line endings. See the repro case here: https://play.golang.org/p/4Sb0-kywzTw. The parser reports that the comment ends 2 lines above its actual end.

Related to #41197.

/cc @findleyr

@stamblerre stamblerre changed the title x/tools/gopls: corrupted file with block comment and CRLF line endings go/parser: invalid block comment end position with CRLF line endings Nov 16, 2020
@stamblerre stamblerre removed Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Nov 16, 2020
@incansvl
Copy link
Author

I'm using a Windows machine for this development so it will be using CRLF line endings by default I expect. I will try changing to LF.

I have been seeing other code-altering behaviours too, such as include statements (quite possibly erroneous ones as i'm new to Go coding) being deleted on save. Maybe there is a "correct by deleting" default behaviour in the auto-linter I'm not aware of.

@gopherbot
Copy link

Change https://golang.org/cl/270879 mentions this issue: internal/lsp: fix end positions for multi-line comments with CRLF lines

@stamblerre stamblerre modified the milestones: Unreleased, gopls/v0.5.4 Nov 18, 2020
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Dec 6, 2020
gopls: update to 0.5.5.
d5e1c1d 
0.5.5

This is a patch release to fix two bugs in gopls/v0.5.4.

Fixes

Excessive reloading of packages outside of GOPATH or a module

File corruption with CRLF line endings and //-style comments

golang/go#42646 was supposed to have been fixed in gopls/v0.5.4,
but it was not. golang/go#42923 was reported and fixed.

0.5.4

Features

Opening a project that contains a module in a subdirectory

Previously, gopls required that you open your editor exactly at or
below the module root (the directory containing the go.mod). Now,
you can open a directory that contains exactly one module in a
subdirectory, and gopls will work as expected. For details on
multi-module workspaces, see below.

Removal of the granular go.mod upgrade codelenses

Previously, we offered a code lens to suggest upgrades for each
require in a go.mod file. In anticipation of changes that limit
the amount that gopls accesses the network, we have decided to
remove and reevaluate this feature. Users had mentioned that the
code lenses cluttered their go.mod files, especially if they didn't
actually want to upgrade. golang/go#38339 tracks the work to revamp
this feature. An "Upgrade all dependencies" code lens should still
appear at the top of your go.mod file.

Improved error message reports

Previously, critical error messages were reported as message pop-up
that would re-trigger as you type. Many users would find this
annoying. We have changed the approach to show error messages as
progress reports, which should be less intrusive and appear more
like status bars.

Improved memory usage for workspaces with multiple folders

We are now using a coarser cache key for package type information.
If you use the gopls daemon, this may reduce your total memory
usage.

Experimental

Multi-module workspace support

The proposal described in golang/go#32394 is still in development
and off by default. See our progress by tracking the multi-module
workspace milestone and project.

Enable multi-module workspace support by adding the following to
your settings:

"gopls": { "experimentalWorkspaceModule": true, }

With this setting, you will be able to open a directory that contains
multiple modules or a directory that contains nested modules.

Give this a try if you're interested in this new feature, but please
note that it is still very experimental. Please file issues if you
encounter bugs.

Fixes

File corruption with CRLF line endings and /**/-style comments

Previously, when you organized the imports in a file with CRLF line
endings and multi-line comments, the formatter might output incorrect
content for the file, rendering it invalid Go code. This issue has
popped up a number of times, but we believe it has finally been
fixed for good. If you are using Windows with CRLF line ending,
please report any regressions. For full details, see golang/go#42646.
@golang golang locked and limited conversation to collaborators Nov 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
gopls/v0.5.4
Development

No branches or pull requests
3 participants
@stamblerre @gopherbot @incansvl