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

x/tools/gopls: editing a file with a path that does not exist on disk crashes with Sublime Text #41779

Closed
kortschak opened this issue Oct 4, 2020 · 3 comments
Labels
Milestone

Comments

@kortschak
Copy link
Contributor

@kortschak kortschak commented Oct 4, 2020

What did you do?

Edit a file that does not exist on disk.

Sublime Text has persistent state even for files that are not stored as normal files on the file system. This clearly confuses gopls.

This can be recreated by opening a new file, editing and then deleting it on disk, then editing the open non-existent file.

What did you expect to see?

No crash.

What did you see instead?

A crash.

gopls: panic: assignment to entry in nil map
gopls: 
gopls: goroutine 13122 [running]:
gopls: golang.org/x/tools/internal/lsp.(*Server).didChange(0xc0002fa3c0, 0xeebc00, 0xc0143d60f0, 0xc0143e6030, 0x0, 0x0)
gopls: /home/user/src/golang.org/x/tools/internal/lsp/text_synchronization.go:124 +0x2e5
gopls: golang.org/x/tools/internal/lsp.(*Server).DidChange(0xc0002fa3c0, 0xeebc00, 0xc0143d60f0, 0xc0143e6030, 0xc0143e6030, 0x0)
gopls: /home/user/src/golang.org/x/tools/internal/lsp/server_gen.go:36 +0x49
gopls: golang.org/x/tools/internal/lsp/protocol.serverDispatch(0xeebc00, 0xc0143d60f0, 0xeff6a0, 0xc0002fa3c0, 0xc0143e6000, 0x7f8d18d8ef60, 0xc0143d6090, 0x0, 0xed90e0, 0xc0132b86e0)
gopls: /home/user/src/golang.org/x/tools/internal/lsp/protocol/tsserver.go:120 +0x1a7e
gopls: golang.org/x/tools/internal/lsp/protocol.ServerHandler.func1(0xeebc00, 0xc0143d60f0, 0xc0143e6000, 0x7f8d18d8ef60, 0xc0143d6090, 0x3e6b94b61, 0x1342dc0)
gopls: /home/user/src/golang.org/x/tools/internal/lsp/protocol/protocol.go:63 +0xc5
gopls: golang.org/x/tools/internal/lsp/lsprpc.handshaker.func1(0xeebc00, 0xc0143d60f0, 0xc0143e6000, 0x7f8d18d8ef60, 0xc0143d6090, 0x0, 0x0)
gopls: /home/user/src/golang.org/x/tools/internal/lsp/lsprpc/lsprpc.go:557 +0x452

Build info

golang.org/x/tools/gopls v0.5.1
    golang.org/x/tools/gopls@(devel)
    github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
    github.com/google/go-cmp@v0.5.1 h1:JFrFEBb2xKufg6XkJsJr+WbKb4FQlURi5RUcBveYu9k=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/mod@v0.3.0 h1:RM4zey1++hCTbCVQfnWeKs9/IEsaBLA8vTkd0WVtmH4=
    golang.org/x/sync@v0.0.0-20200625203802-6e8e738ad208 h1:qwRHBd0NqMbJxfbotnDhm2ByMI1Shq4Y6oRJo21SGJA=
    golang.org/x/tools@v0.0.0-20200930165741-f1523d29dbb9 => ../
    golang.org/x/xerrors@v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
    honnef.co/go/tools@v0.0.1-2020.1.5 h1:nI5egYTGJakVyOryqLs1cQO5dO0ksin5XXs2pspk75k=
    mvdan.cc/gofumpt@v0.0.0-20200802201014-ab5a8192947d h1:t8TAw9WgTLghti7RYkpPmqk4JtQ3+wcP5GgZqgWeWLQ=
    mvdan.cc/xurls/v2@v2.2.0 h1:NSZPykBXJFCetGZykLAxaL6SIpvbVy/UFEniIfHAa8A=
@kortschak
Copy link
Contributor Author

@kortschak kortschak commented Oct 4, 2020

@cespare Has suggested a fix for this in #41777 (comment), alternatively, a change to didChange that adds a conditional map initialisation would work.

	...
	if s.changedFiles == nil {
		s.changedFiles = make(map[span.URI]struct{})
	}
	s.changedFiles[uri] = struct{}{}
	return nil
}
@gopherbot
Copy link

@gopherbot gopherbot commented Oct 4, 2020

Change https://golang.org/cl/259457 mentions this issue: x/tools/internal/lsp: avoid passing nil source.Snapshot to IsGenerated

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 5, 2020

Change https://golang.org/cl/259618 mentions this issue: internal/lsp: unconditionally create changedFiles map

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants