profile
viewpoint

heschik/govim 0

govim is a Go development plugin for Vim8, written in Go

heschik/tools 0

[mirror] Go Tools

issue commentgolang/go

x/tools/gopls: 30s delay before completion menu popups

I reproduced this. Profile shows heavy usage in PathEnclosingInterval, which I think is a known problem.

netjune

comment created time in 3 days

issue commentgolang/go

x/tools/gopls: respect GOPRIVATE setting for links to documentation on hover

I think this is fixed?

stamblerre

comment created time in 4 days

issue commentgolang/go

x/tools/gopls: error when renaming interface method involving type aliases

This is an issue tracker, not a chat system, so generally I don't assume things are directed at me unless they @ me. I think you'd have better interactions if you made the same assumption and asked an actual question rather than just saying "So?". But that's up to you.

inliquid

comment created time in 4 days

issue commentgolang/go

x/tools/gopls: error when renaming interface method involving type aliases

I made that comment and renamed the issue because I'm fairly certain that the bug is related to the alias. I didn't fully investigate but it seemed like a useful fact for whoever ends up handling the bug.

Is that a problem somehow? Your comment comes off as rather aggressive and I don't really understand why.

inliquid

comment created time in 4 days

issue commentgolang/go

x/tools/gopls: don't download modules automatically

gopls needs all of your project's dependencies to be available, even if that means downloading them. It sounds like you need to set a proxy in go.toolsEnvVars.

kzhui125

comment created time in 4 days

issue commentgolang/go

x/tools/gopls: error when renaming interface method

M is a type alias: https://pkg.go.dev/go.mongodb.org/mongo-driver/bson?tab=doc#M.

inliquid

comment created time in 4 days

issue openedgolang/go

x/tools/gopls: repeats completion prefix for identifiers in comments

With gopls at tip, completing in comments doesn't overwrite the completion prefix. For example, in:

package main

// Foo<>
func FooDoesAThing() {}

you get a completion that yields

package main

// FooFooDoesAThing
func FooDoesAThing() {}

cc @clintjedwards

created time in 5 days

issue commentgolang/go

x/tools/gopls: ignore excluded or ignored files

I see. Whatever is done for this will need to be in sync with the go command's behavior, so I don't think we'd be able to ignore individual files anyway. The vscode issue was for ignoring directories, which should be much more clear and not have the problems you're worried about.

stamblerre

comment created time in 5 days

issue commentgolang/go

x/tools/gopls: ignore excluded or ignored files

@AndreasBackx I don't understand what that has to do with gopls. You may want to file a new issue, or at least explain exactly what you're looking for here.

stamblerre

comment created time in 5 days

issue commentgolang/go

x/tools/gopls: improve support for authoring cgo packages

@beakbeak Thanks! @mdempsky, see https://golang.org/cl/234878 for tests. I checked that at least one of them works fine with the real compiler. Given that much of the other C stuff works, I don't think this is on my end of things.

heschik

comment created time in 10 days

issue openedgolang/go

cmd/go: strange error message downloading golang.org/x/tools@master

What version of Go are you using (go version)?

<pre> $ go version go version devel +f7f9c8f2fb Wed May 20 15:57:15 2020 +0000 linux/amd64 </pre>

Does this issue reproduce with the latest release?

No.

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env ... GONOPROXY="github.com/heschik" GONOSUMDB="github.com/heschik" GOPRIVATE="github.com/heschik" GOPROXY="https://proxy.golang.org,direct" ...

</pre></details>

What did you do?

/tmp $ GO111MODULE=on ~/go/bin/go get golang.org/x/tools@master

What did you expect to see?

go: golang.org/x/tools master => v0.0.0-20200519205726-57a9e4404bf7

What did you see instead?

go get golang.org/x/tools@master: path does not match GOPRIVATE/GONOPROXY

created time in 11 days

issue commentgolang/go

x/tools/gopls: improve support for authoring cgo packages

Here's the current status: if you build gopls at master with tip Go, you should have a pretty good cgo authoring experience. The one bug I know of is autocomplete, which will offer symbols like _cgo_foo instead of C.foo.

One bump, though, is that it won't regenerate the cgo bindings unless you tell it to. To that end, there should be a "regenerate cgo" popup on top of the import "C" line in a file that uses cgo. You'll need to use it when you reference a new identifier from C, or change the magic comment in a way that affects the symbols Go can see.

To get set up, follow these instructions:

$ go get golang.org/dl/gotip
$ gotip download
[...]
Success. You may now run 'gotip'!
$ cd /
$ GO111MODULE=on gotip get golang.org/x/tools/gopls@master
$ gotip version
... devel +f7f9c8f ...
$ gotip version $(which gopls)
... devel +f7f9c8f ...

You don't need to use tip Go to work on your own project, just to build gopls.

Please leave a reaction on this comment if you try it out, and comment with any bugs you find.

heschik

comment created time in 11 days

issue openedgolang/go

x/tools/gopls: duplicates comment after imports on every save

https://golang.org/cl/233117 introduced a new bug where each save duplicates the comment immediately after the import block. I noticed this in go/packages/packages.go -- on every save a new copy of the "A LoadMode..." comment will be created.

@pjweinb

created time in 12 days

issue commentgolang/go

x/tools: multiple tests consistently failing on "-nocgo" builders

Cool. At least it's common code now!

I can add some cases to allowMissingTool. Presumably the -nocgo means cgo shouldn't work. Do you know what the deal is with the other three?

bcmills

comment created time in 13 days

CommitCommentEvent
CommitCommentEvent

issue commentgolang/go

x/tools/gopls: inconsistent vendoring issue breaks gopls

This error message comes straight from the go command, and I don't think go mod tidy is always the right solution. But Bryan and Jay should speak to that.

As for continuing, unfortunately gopls needs information from the go command to provide editor services and in this situation it simply can't get it. Turning off vendor mode might fix the problem, but I don't think gopls should be doing that of its own volition. It might result in downloading stuff, or it might make things worse.

@bcmills @jayconrod

evanmoses-okta

comment created time in 16 days

issue commentgolang/go

proxy.golang.org: don't cache /@latest for modules that no longer exist at the upstream head revision

One of the primary goals of the proxy is to protect users from flaky upstreams, in particular outages. Since the go command gives us no way to distinguish outages from deliberate actions, we are required to be conservative and not try to infer intent.

Adding new dependencies is not a trivial use case and it is not acceptable for the ecosystem to break the next time some origin server goes down for a day. I don't think that's negotiable but if you would like to argue that case, this is probably not the place to do it.

If the fix for #24031 isn't sufficient to cover the security use case that sounds like a critical problem with it. The vast majority of people are presumably not going to be tracking a branch.

I don't think this discussion is going anywhere and I think this issue should be closed.

bcmills

comment created time in 17 days

issue openedgolang/go

go/types: UsesCgo exposes mangled names

When UsesCgo is enabled, cgo symbols appear in the package as their mangled names, e.g. _CFunc_GoString. This breaks autocomplete in gopls for C symbols. Also, it exposes things that are implementation details, like the _cgo_ and __cgofn symbols.

We can try to fix this in gopls, but probably it'd be better in go/types. I'm not sure offhand how it'll work, given that each package needs its own version of "C". Maybe the package path could be rewritten to something specific?

created time in 17 days

issue commentgolang/go

proxy.golang.org: don't cache /@latest for modules that no longer exist at the upstream head revision

It's not even that. As far as I recall this is exactly the same behavior everything else gets. If a module goes from existing to failing to download, we'll continue to serve it for as long as we can. That goes for branches, tags, pseudoversions, everything.

bcmills

comment created time in 17 days

issue commentgolang/go

x/tools/cmd/goimports: return non-zero exit code if there's an offense

Makes sense to me. Would you like to send a CL?

khos2ow

comment created time in 18 days

issue commentgolang/go

proxy.golang.org: don't cache /@latest for modules that no longer exist at the upstream head revision

We can't tell whether a module version is on the default branch, so we would have to invalidate @latest on any commit to any branch that we became aware of. If we then experienced a transient failure refreshing @latest, that would break users.

I think this is a very specific workaround to a very specific problem that has better solutions and causes some amount of collateral damage. It certainly increases complexity. I would rather not do it.

bcmills

comment created time in 19 days

issue commentgolang/go

proxy.golang.org: don't cache /@latest for modules that no longer exist at the upstream head revision

Sorry, but I don't understand what the actual feature request here is. My best guess is:

module X has an @latest entry. module X/Y has an @latest entry. attempted fetches of module X/Y begin failing -- possibly because the origin is flaky, possibly because it's been deleted, or possibly because something is internally wrong with proxy.golang.org. module X continues to work.

In this situation, you're saying that we should assume that X/Y is failing because it's been deleted, check that a version of X later than the version of X/Y has been fetched, and forget the @latest for X/Y?

If that's wrong please be very specific about the proposal. I can't imagine a version of this that I think is a good idea so I'm struggling to understand the suggestion.

bcmills

comment created time in 20 days

issue commentgolang/go

proposal: x/tools/go/packages: add Dir and Target (and perhaps other) fields to Package struct

I thought Match wasn't implementable in Bazel?

matloob

comment created time in 20 days

issue commentgolang/go

x/tools/gopls: issue with named imports

https://cs.opensource.google/go/tools/+/master:internal/lsp/source/types_format.go;l=381;drc=b8428586f46299aff9dbc7b128617219c087700f doesn't return the cloned node, so it falls through and returns the original.

stamblerre

comment created time in 23 days

issue commentgolang/go

x/tools/gopls: issue with named imports

Commenting out https://cs.opensource.google/go/tools/+/master:internal/lsp/source/types_format.go;drc=b8428586f46299aff9dbc7b128617219c087700f;l=222 fixes the bug. I suspect https://cs.opensource.google/go/tools/+/master:internal/lsp/source/types_format.go;drc=b8428586f46299aff9dbc7b128617219c087700f;l=290 is writing to an un-cloned AST node.

stamblerre

comment created time in 23 days

issue commentgolang/go

x/tools/gopls: issue with named imports

I reduced the test case to these two files:

package mypkg

func One() {
}
package mypkg

import net_url "net/url"

func Two() *net_url.URL {
	return nil
}

One significant finding: if you save the second file while it's got the error, it actually gets rewritten to *url.URL. That strongly hints that the AST is getting messed with, possibly by an analyzer.

stamblerre

comment created time in 23 days

issue commentgolang/go

x/tools/go/packages: expose Deps field of a package

I see. That seems like more of a build system/implementation detail than information about the package, so I don't know if it's a fit for go/packages. But that's more of a question for @matloob.

aykevl

comment created time in 23 days

issue commentgolang/go

x/tools/go/packages: expose Deps field of a package

What do you mean when you say that packages implicitly depend on the runtime package? Naturally everything implicitly depends on the runtime for memory allocation and such, but those functions don't come in by a normal package dependency. Nothing should depend on the runtime package unless they explicitly import it, afaik.

aykevl

comment created time in 23 days

issue commentgolang/go

x/tools/gopls: panic when adding a comment at the end of a file

This area of the code has been a rich source of bugs, but I can't reproduce this one. If you can get the panic trace, I can probably fix it without a repro. I don't know how to do that in vim, sorry.

danieltrautmann

comment created time in a month

issue openedmicrosoft/vscode-go

Go To Symbol breaks after a few uses

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

  • Run go version to get version of Go
    • go version go1.14 linux/amd64
  • Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders
    • 1.44.0
  • Check your installed extensions to get the version of the VS Code Go extension
    • 1.14.1
  • Run go env GOOS GOARCH to get the operating system and processor architecture details
    • linux amd64

Share the Go related settings you have added/edited

    "go.useLanguageServer": true,
    "go.languageServerFlags": [
        "-rpc.trace", // for more detailed debug logging
        "serve",
        "--debug=localhost:6060", // to investigate memory usage, see profiles
    ],   
    "go.lintOnSave": "off", 
    "[go]": {
        // "editor.snippetSuggestions": "none",
        "editor.formatOnSave": true,
        "editor.codeActionsOnSave": {
            "source.organizeImports": true,
        }
    },
    "gopls": {
        "usePlaceholders": true, // add parameter placeholders when completing a function
        "matcher": "fuzzy",
        // Experimental settings
        "staticcheck": false,
        "verboseOutput": true,
    },

Describe the bug

Go To Symbol stops working after some number of uses with no obvious root cause. It just hangs, with a neverending progress spinner below the search bar.

Steps to reproduce the behavior:

Press ctrl-T to open the search bar. Type a bunch of letters in quickly. Press escape to close the search box, then repeat a few times. For me it always breaks within ~30 seconds of playing with it. When it's broken, it no longer sends workspace/symbol requests to gopls, so I think the problem must be on the VS Code side, perhaps some bug in cancellation handling.

Screenshots or recordings

I can learn how to take a recording if necessary.

created time in a month

issue commentgolang/go

x/tools/gopls: improve unimported completion ranking

The CL above didn't fix Rebecca's issue, but I don't want to leave this open as a magnet for every ranking complaint, so I'm inclined to leave it closed for now.

stamblerre

comment created time in a month

issue commentgolang/go

cmd/go: mod tidy takes excessive wall & CPU time statting irrelevant files

If I remove the last dep on a module from my project, how would gopls use go list -deps -test to discover that the module is now unused?

pwaller

comment created time in a month

issue closedgolang/go

x/tools/gopls: unimported completions not (consistently) offered

<!-- Please answer these questions before submitting your issue. Thanks! -->

What version of Go are you using (go version)?

<pre> $ go version go version devel +b1b67841d1 Tue Apr 28 21:46:16 2020 +0000 linux/amd64 $ go list -m golang.org/x/tools golang.org/x/tools v0.0.0-20200430040329-4b814e061378 $ go list -m golang.org/x/tools/gopls golang.org/x/tools/gopls v0.0.0-20200430040329-4b814e061378 </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="on" GOARCH="amd64" GOBIN="" GOCACHE="/home/myitcv/.cache/go-build" GOENV="/home/myitcv/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/myitcv/gostuff/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/myitcv/gostuff" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/myitcv/gos" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/govim/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build754553919=/tmp/go-build -gno-record-gcc-switches" </pre></details>

What did you do?

These steps are reduced from a more complex example:

export GOPATH=$(mktemp -d) 
cd $(mktemp -d) 
go mod init example.com/hello
go get -d github.com/rogpeppe/go-internal@v1.5.2
go get -d cuelang.org/go@v0.1.3-0.20200424192631-12927e83d318
go mod download
echo -e "package main\n\nfunc main() {\n\tpar\n}" > main.go

Then attempt completion after par in the main.go file

What did you expect to see?

Offered completion candidates for:

parse  "text/template/parse"
parser "go/parser"
par    "github.com/rogpeppe/go-internal/par"
parser "cuelang.org/go/cue/parser"

What did you see instead?

During repeated calls to completion, most of the time I only saw:

parse  "text/template/parse"
parser "go/parser"

Sometimes:

parse  "text/template/parse"
parser "go/parser"
par    "github.com/rogpeppe/go-internal/par"

But the cuelang.org/go/cue/parser package was never a candidate.

See the attached log file for the sequence of events: gopls_20200430_1402_02_716145697.log


cc @stamblerre @heschik

FYI @leitzler

closed time in a month

myitcv

issue commentgolang/go

x/tools/gopls: unimported completions not (consistently) offered

Not without a compelling rationale. Closing.

myitcv

comment created time in a month

issue commentgolang/go

x/tools/gopls: unimported completions not (consistently) offered

You could type parser.Pif you have even the faintest idea that you're looking for a Parse function, and it will give many more results for that.

Feel free to send a CL to increase the 5, but you're probably going to have to explain why you're confident that there won't be 10 (or however many) parser packages.

myitcv

comment created time in a month

issue commentgolang/go

x/tools/gopls: unimported completions not (consistently) offered

It's totally arbitrary, so of course it can be increased. See the description of https://golang.org/cl/218879 for more details. It may be that people are more willing to scroll through a list of completions than we expected, but I still generally think you should just keep typing?

myitcv

comment created time in a month

issue commentgolang/go

x/tools/gopls: improve unimported completion ranking

The imports-on-save path doesn't rank by module relevance; that's #36077.

If you already use testify in your project, it should be at the top of the rankings, because it should be in memory. I think the behavior in your screencast is simply be a scoring bug -- untyped completions are ending up before typed completions, which really shouldn't happen. @muirdm might have a guess here. I can try to reproduce it at some point, it might be pretty easy, but I don't have time right now.

Why can't the import reorg simply check each candidate against go.mod?

In general the answer to any question of the form "why can't X just Y" is going to be that it's harder than you think it is. I went into some detail above. If you want a full explanation of the architecture of the autocomplete feature, I would appreciate you asking more politely.

stamblerre

comment created time in a month

issue commentgolang/go

x/tools/gopls: unimported completions not (consistently) offered

Ranking is #38104.

Actually, I'm confused. I just looked at your log, and I see cuelang.org/go/cue/parser in response 3 and 6.

myitcv

comment created time in a month

issue commentgolang/go

x/tools/gopls: unimported completions not (consistently) offered

I can't reproduce this. There should be a total of 5 completion results (https://cs.opensource.google/go/tools/+/master:internal/lsp/source/completion.go;drc=8463f397d07cfd2b3f1442fb1daa5e6bc2178a6e;l=743) arbitrarily chosen from any packages that match the prefix. I often see the cue parser package.

myitcv

comment created time in a month

issue commentgolang/go

x/tools/gopls: prefer modules in `go.mod` when importing or ranking completion items

If you had only v2 in the go.mod, then it should have been selected.

hyangah

comment created time in a month

issue commentgolang/go

x/tools/gopls: prefer modules in `go.mod` when importing or ranking completion items

Dupe of #38104, AFAICT. For what it's worth, because loaded packages are fully scanned and sorted, this is likely to be less of a problem in a real project rather than a trivial main program.

hyangah

comment created time in a month

issue commentmicrosoft/vscode-go

Document and maintain standard library development setup

Happened to skim this bug. std/ prefixes would most likely be a consequence of adding a new package, or maybe just a new symbol to a package, while being in the wrong GOROOT.

FiloSottile

comment created time in a month

issue commentgolang/go

x/tools/cmd/goimports: put std, cmd packages in separate blocks

Not sure what you'd like me to do here. I can change it so that cmd/ is grouped with golang.org, but -local is the only way to get three groups, and in general goimports will never merge groups, so if you want to collapse down to two you're going to have to give it some help.

jayconrod

comment created time in a month

issue commentgolang/go

x/tools/cmd/goimports: put std, cmd packages in separate blocks

To be clear, do you really want it in three sections, or do you just want cmd/ grouped with golang.org/x? Because the latter seems like a bug that should be fixed. The former would be more of a job for -local.

jayconrod

comment created time in a month

issue commentgolang/go

x/tools/gopls: import organization sporadically failing

Yeah, it's strange but not gopls:

$ GOFLAGS='-tags foo' go mod tidy
go: parsing $GOFLAGS: non-flag "foo"

Feel free to file a cmd/go bug for that, though I feel like I've seen it somewhere.

atombender

comment created time in a month

issue commentgolang/go

x/tools/gopls: import organization sporadically failing

I tested the fix with your repro, so that's pretty surprising. Are you sure you have master? (Maybe GOPROXY=direct to avoid proxy.golang.org caching it?)

atombender

comment created time in a month

issue commentgolang/go

x/tools/gopls: import organization sporadically failing

Got it. Fix as soon as I write the test.

atombender

comment created time in a month

issue commentgolang/go

x/tools/gopls: import organization sporadically failing

Thanks for the repro. Somehow "-tags=dummy" is turning into just "-tags" and breaking all of our go invocations. I'll track it down.

atombender

comment created time in a month

issue commentfatih/vim-go

vim-go: no views in the session

We need much more specific detail about what the setup is here to do any real diagnosis. Right now, it looks like gopls is receiving very strange Linux-style paths (/d/timezone/go/src/ecp_service) despite running completely in Windows. What exactly is the "console emulator for Linux terminals on windows" and how exactly is vim being started?

manjitsinghm

comment created time in a month

issue openedgolang/go

x/build: increment internal/goversion at the beginning of the release cycle

internal/goversion determines what release tags are in effect. It should be incremented at the beginning of each cycle as part of unfreezing the tree, otherwise who knows when someone will remember to do it. (I just noticed a couple days ago, the week before the freeze. It's not clear to me anyone would have caught it before the beta.)

@dmitshur

created time in a month

issue commentgolang/go

x/tools/gopls: corrupted file= query with files of different cases

Are you more worried about the gratuitous Loads or the fact that the diagnostic got swallowed? I don't know how to write a test for the former, but the latter should be easy.

stamblerre

comment created time in a month

issue commentgolang/go

x/tools/gopls: signature help does not properly qualify types

IMO, if there's a problem here fully qualifying the path is not the right solution. If you're familiar with the API, the full path is just going to be an impediment to readability. If you're not, then the full path is not going to be enough to teach you how to use it.

What is the actual use case?

myitcv

comment created time in a month

issue commentgolang/go

cmd/compile: set prologue_end on every arch

...though that CL isn't merged yet.

derekparker

comment created time in a month

issue commentgolang/go

cmd/compile: set prologue_end on every arch

https://golang.org/cl/223297 did part of this. Any more planned for 1.15?

derekparker

comment created time in a month

issue commentgolang/go

x/tools/gopls: corrupted file= query with files of different cases

I tracked this down.

panic: GetFile on  /tmp/scratch/case-insensitive import collision
golang.org/x/tools/internal/lsp/cache.(*snapshot).GetFile
golang.org/x/tools/internal/lsp/source.clearReports
golang.org/x/tools/internal/lsp/source.Diagnostics
golang.org/x/tools/internal/lsp.(*Server).diagnose.func2

clearReports probably shouldn't register a file that doesn't already exist, and we should ideally not treat case-insensitive import collision: "example.com/foo/x" and "example.com/Foo/x" as an error in the file "case-insensitive import collision".

stamblerre

comment created time in a month

issue commentgolang/go

x/tools/cmd/goimports: -w leaves all edited files Read-Only on Windows

Since this behavior was released in 1.14, we need a fix in goimports regardless of future behavior. I changed the CL to update this bug rather than close it.

cmMcKeevek

comment created time in a month

issue commentgolang/go

x/tools/cmd/goimports: -w leaves all edited files Read-Only on Windows

@ianlancetaylor touched the doc last, so I'm curious if he has an opinion. But anyway, fine; I'll change goimports to stat the file and use its permissions for the WriteFile call.

cmMcKeevek

comment created time in a month

issue commentgolang/go

x/tools/cmd/fiximports: don't use .biz extension in testdata

These files are years old and we've never had a problem before AFAIK. I can review a change to rename them but I don't think I'm going to do it myself.

BertHooyman

comment created time in a month

issue commentgolang/go

x/tools/gopls: high memory consumption when used with a monorepo

I was able to reproduce a similar profile by simply opening the root of the Fyne project. Most of the memory is being used by the type checker:

Showing nodes accounting for 853.95MB, 88.04% of 969.98MB total
      flat  flat%   sum%        cum   cum%
  620.02MB 63.92% 63.92%   620.02MB 63.92%  go/types.(*Checker).recordTypeAndValue
   87.50MB  9.02% 72.94%    98.44MB 10.15%  go/parser.(*parser).parseOperand
   43.13MB  4.45% 77.39%   153.17MB 15.79%  go/parser.(*parser).parseElementList

That's a little surprising for Fyne which is a relatively small project. My best guess is that the problem is the GL libraries, which generate tens of thousands of lines of cgo.

Regardless, I don't see a gopls bug here; it appears to be general go/types memory usage as usual.

trapgate

comment created time in a month

issue commentgolang/go

x/tools/cmd/fiximports: don't use .biz extension in testdata

@bcmills @jayconrod is this a dupe of #36568? This is an error on directory creation rather than rename.

BertHooyman

comment created time in a month

issue commentgolang/go

x/tools/cmd/goimports: -w leaves all edited files Read-Only on Windows

From the WriteFile docs: "If the file does not exist, WriteFile creates it with permissions perm (before umask); otherwise WriteFile truncates it before writing." That would appear to me to say that perm is only used when creating the file.

From OpenFile: "If the file does not exist, and the O_CREATE flag is passed, it is created with mode perm (before umask)." Again, perm is not mentioned as used except during file creation.

cmMcKeevek

comment created time in a month

issue commentgolang/go

x/tools/cmd/goimports: -w leaves all edited files Read-Only on Windows

Right, I understand that it's intention to set readonly under at least some circumstances. That's your https://golang.org/cl/202439. My question is whether it's intentional to apply them when opening an existing file, rather than creating a new one.

cmMcKeevek

comment created time in 2 months

issue commentgolang/go

x/tools/cmd/goimports: -w leaves all edited files Read-Only on Windows

I think you're right; the file now has the 'R' (read only) attribute. I think this might be a Go bug; the documentation for ioutil.WriteFile and io.CreateFile state, or at least strongly imply, that the file mask only matters when the file is created. Here, it already exists. So why are the attributes being changed?

cmMcKeevek

comment created time in 2 months

issue commentgolang/go

x/tools/cmd/goimports: -w leaves all edited files Read-Only on Windows

I can't reproduce this. You probably have a virus scanner or some other system tool that's interfering.

cmMcKeevek

comment created time in 2 months

issue commentgolang/go

x/tools/gopls: frequent failures in TestSource/*/testdata/lsp/CompletionSnippets/address_68_11_1_placeholders

FWIW, I think the syscall candidates actually are more plausible here than the getFoo one. Without having done a thorough analysis it's hard to say but my feeling is that depth is a much stronger signal than imported-ness.

stamblerre

comment created time in 2 months

issue commentgolang/go

x/tools/gopls: fails to link some scheme-less URLs

cc @mvdan

heschik

comment created time in 2 months

issue openedgolang/go

x/tools/gopls: fails to link some scheme-less URLs

We use the Relaxed regex from XXX to find URLs to linkify. That regex accepts URLs without schemes like golang.org rather than http://golang.org, which we then parse with url.Parse. That works okay for most URLs. (From url.Parse: "Trying to parse a hostname and path without a scheme is invalid but may not necessarily return an error, due to parsing ambiguities.").

However, for at least some URLs with colons, e.g. 127.0.0.1:80, parsing fails ("first path segment in URL cannot contain colon") and the URL is not linkified. golang.org:8080 works for reasons I haven't dug into.

created time in 2 months

issue commentgolang/go

x/tools/gopls: using a lot of memory

It would be very, very surprising if recent versions of gopls hadn't written of those files to /tmp while using a problematic amount of memory. Can you triple-check that there isn't an old version anywhere, and that it's actually gopls using the memory?

ajeecai

comment created time in 2 months

issue closedgolang/go

x/tools/gopls: support case insensitive file systems

gopls doesn't support case-insensitive file systems. VS Code always sends lower-case drive letters, but if a user sets their GOPATH to C://bob/go, go list will return upper-case drive letters. At that point, gopls will think it did not get metadata for the given file, and it will not work correctly.

closed time in 2 months

stamblerre

issue commentgolang/go

x/tools/gopls: support case insensitive file systems

Check it on file open? But we can wait for the next complaint if any.

stamblerre

comment created time in 2 months

issue commentgolang/go

x/tools/gopls: improve unimported completion ranking

Forgot a trick, mailed https://golang.org/cl/226559 which should improve things significantly. We can revisit if there's more complaints. I can't think of any more quick fixes.

Haven't looked at the complete-ness of the results at all yet.

stamblerre

comment created time in 2 months

issue commentgolang/go

x/tools/gopls: improve unimported completion ranking

The goimports code makes no attempt to return a consistent set of results, so some randomness is expected when there are many candidates with equal prioritization. But these don't have equal priorities.

The problem is that when it scans the disk, it scans in priority order. But the cache iteration is in a random order, and gopls cancels the iteration as soon as it gets some number of results. There's currently no attempt to keep receiving results until it gets them at a high enough priority. I'm not sure what to do about this; the cache can't know priorities because it's not dependent on the go.mod, so we'd have to scan the entire cache, which could be slow. (We could stop after receiving "enough" hits at the highest priority, but generally speaking that won't happen.)

I'm not sure what to do about this.

stamblerre

comment created time in 2 months

issue commentgolang/go

go.dev: no repo link

On the page you linked to, there is a link to the repository under the "Source Code" header, next to the text "Repository:".

willfaught

comment created time in 2 months

issue commentgolang/go

x/tools/gopls: ignore vendor directories when running diagnostics

In module mode, it's guaranteed to be module root + /vendor. In GOPATH mode they could be anywhere, and also the user might want to edit them, so it's not obvious to me that they shouldn't be workspace packages. But certainly we can start with module mode.

I think we've also discussed debouncing file change events, which would probably be relevant to the go mod vendor case?

stamblerre

comment created time in 2 months

issue commentgolang/go

x/tools/gopls: sustained 100% cpu use from gopls for hours after editor interactions stop

OK. In that case I think a log would be the best next step -- all evidence points to the editor sending a never-ending stream of didChange notifications and we need to see what those are.

smarterclayton

comment created time in 2 months

issue commentgolang/go

x/tools/gopls: constant crashing with emacs-lsp

@stamblerre I'm not clear on what exactly happened, honestly. https://cs.opensource.google/go/tools/+/master:internal/lsp/cache/view.go;l=332;drc=521f4a0cd458c441dec3bafd8ba24526a6cb9b09 is supposed to have used the output of the go command to populate GOPATH, so why didn't it?

mikroskeem

comment created time in 2 months

issue commentgolang/go

x/tools/gopls: sustained 100% cpu use from gopls for hours after editor interactions stop

Any chance this is https://github.com/microsoft/vscode-go/issues/3109#issuecomment-600320476 ?

smarterclayton

comment created time in 2 months

issue commentgolang/go

x/tools/gopls: support case insensitive file systems

We have a report on Slack of VS Code using the wrong case for initialize and other file URIs, so I guess our work here is not done.

stamblerre

comment created time in 2 months

IssuesEvent

issue closedgolang/go

x/tools/internal/lsp/source: panic due to concurrent map access

From https://github.com/microsoft/vscode-go/issues/3026#issuecomment-600500853

cc @Greyh4t

gopls v0.3.3 go version 1.14 windows/amd64

fatal error: concurrent map iteration and map write
fatal error: concurrent map read and map write
fatal error: concurrent map iteration and map write

goroutine 9502 [running]:
runtime.throw(0xcda4c5, 0x26)
	C:/Go/src/runtime/panic.go:1112 +0x79 fp=0xc0014e5908 sp=0xc0014e58d8 pc=0x437da9
runtime.mapiternext(0xc0014e5bb8)
	C:/Go/src/runtime/map.go:853 +0x559 fp=0xc0014e5988 sp=0xc0014e5908 pc=0x410309
golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc0000e75c0, 0xc008be6f00, 0xc0014e5e00, 0x449e17, 0xc0014e5f10, ...)
	C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:70 +0xc1d fp=0xc0014e5d20 sp=0xc0014e5988 pc=0x793d8d
golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...)
	C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec fp=0xc0014e5f88 sp=0xc0014e5d20 pc=0xaba48c
runtime.goexit()
	C:/Go/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc0014e5f90 sp=0xc0014e5f88 pc=0x468a71
created by golang.org/x/tools/internal/lsp.(*Server).diagnose
	C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

<details>

[Info - 下午4:37:12] 2020/03/18 16:37:12 Build info

golang.org/x/tools/gopls v0.3.3 golang.org/x/tools/gopls@v0.3.3 h1:mTFqRDJQmpSsgDDWvbtGnSva1z9uX2XcDszSWa6DhBQ= github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ= github.com/sergi/go-diff@v1.0.0 h1:Kpca3qRNrduNnOQeazBd0ysaKrUJiIuISHxogkT9RPQ= golang.org/x/mod@v0.1.1-0.20191105210325-c90efee705ee h1:WG0RUwxtNT4qqaXX3DPA8zHFNm/D9xaBpxzHt1WcA/E= golang.org/x/sync@v0.0.0-20190423024810-112230192c58 h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU= golang.org/x/tools@v0.0.0-20200227200655-6862ededa516 h1:OX66ZzpltgCOuBSGdaeT77hS2z3ub2AB+EuGxvGRBLE= golang.org/x/xerrors@v0.0.0-20191011141410-1b5146add898 h1:/atklqdjdhuosWIl6AIbOeHJjicWYPqR9bpxqxYG2pA= honnef.co/go/tools@v0.0.1-2020.1.3 h1:sXmLre5bzIR6ypkjXCDI3jHPssRhc8KD/Ome589sc3U= mvdan.cc/xurls/v2@v2.1.0 h1:KaMb5GLhlcSX+e+qhbRJODnUUBvlw01jt4yrjFIHAuA=

Go info

go version go1.14 windows/amd64

set GO111MODULE= set GOARCH=amd64 set GOBIN= set GOCACHE=C:\Users\L\AppData\Local\go-build set GOENV=C:\Users\L\AppData\Roaming\go\env set GOEXE=.exe set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOINSECURE= set GONOPROXY= set GONOSUMDB= set GOOS=windows set GOPATH=C:\Users\L\Go set GOPRIVATE= set GOPROXY=https://goproxy.io set GOROOT=C:\Go set GOSUMDB=sum.golang.org set GOTMPDIR= set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set AR=ar set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD=d:\work\gocode\hids\jarvis\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 -fmessage-length=0 -fdebug-prefix-map=C:\Users\L\AppData\Local\Temp\go-build757331242=/tmp/go-build -gno-record-gcc-switches

[Info - 下午4:37:14] 2020/03/18 16:37:14 go/packages.Load snapshot = 0 query = [./... builtin] packages = 68 [Info - 下午4:37:15] 2020/03/18 16:37:15 132.0614ms for GOROOT=C:\Go GOPATH=C:\Users\L\Go GO111MODULE= GOPROXY=https://goproxy.io PWD=D:\work\gocode\hids\jarvis go [go env GOMOD] [Info - 下午4:37:16] 2020/03/18 16:37:16 382.0727ms for GOROOT=C:\Go GOPATH=C:\Users\L\Go GO111MODULE= GOPROXY=https://goproxy.io PWD=D:\work\gocode\hids\jarvis go [go list -modfile=C:\Users\L\AppData\Local\Temp\go.jarvis.778003387.mod -m -f {{.Path}} {{.Dir}} {{.GoMod}} {{.GoVersion}} {{range context.ReleaseTags}}{{if eq . "go1.14"}}{{.}}{{end}}{{end}} ] [Info - 下午4:37:16] 2020/03/18 16:37:16 255.3221ms for GOROOT=C:\Go GOPATH=C:\Users\L\Go GO111MODULE= GOPROXY=https://goproxy.io PWD=D:\work\gocode\hids\jarvis go [go list -modfile=C:\Users\L\AppData\Local\Temp\go.jarvis.778003387.mod -m -json ...] [Info - 下午4:37:46] 2020/03/18 16:37:46 background imports cache refresh starting [Info - 下午4:37:49] 2020/03/18 16:37:49 background refresh finished after 2.8194553s Error = <nil> [Info - 下午4:38:27] 2020/03/18 16:38:27 go/packages.Load snapshot = 3 query = [file=D:\work\gocode\hids\jarvis\found packages main (docker.go) and agent (master.go) in D:\work\gocode\hids\jarvis\test] packages = 0 fatal error: concurrent map iteration and map write fatal error: concurrent map read and map write fatal error: concurrent map iteration and map write [Info - 下午4:38:30] 2020/03/18 16:38:30 go/packages.Load snapshot = 3 query = [file=D:\work\gocode\hids\jarvis\found packages main (docker.go) and agent (master.go) in D:\work\gocode\hids\jarvis\test] packages = 0

goroutine 9502 [running]: runtime.throw(0xcda4c5, 0x26) C:/Go/src/runtime/panic.go:1112 +0x79 fp=0xc0014e5908 sp=0xc0014e58d8 pc=0x437da9 runtime.mapiternext(0xc0014e5bb8) C:/Go/src/runtime/map.go:853 +0x559 fp=0xc0014e5988 sp=0xc0014e5908 pc=0x410309 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc0000e75c0, 0xc008be6f00, 0xc0014e5e00, 0x449e17, 0xc0014e5f10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:70 +0xc1d fp=0xc0014e5d20 sp=0xc0014e5988 pc=0x793d8d golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec fp=0xc0014e5f88 sp=0xc0014e5d20 pc=0xaba48c runtime.goexit() C:/Go/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc0014e5f90 sp=0xc0014e5f88 pc=0x468a71 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 1 [syscall, locked to thread]: syscall.Syscall6(0x7ff95eae2410, 0x5, 0x4f0, 0xc00033f000, 0x1000, 0xc00051934c, 0x0, 0x0, 0x0, 0x0, ...) C:/Go/src/runtime/syscall_windows.go:201 +0xf2 syscall.ReadFile(0x4f0, 0xc00033f000, 0x1000, 0x1000, 0xc00051934c, 0x0, 0x7ffff800000, 0x2) C:/Go/src/syscall/zsyscall_windows.go:313 +0xd2 syscall.Read(0x4f0, 0xc00033f000, 0x1000, 0x1000, 0xc00ace47e0, 0xc, 0xc) C:/Go/src/syscall/syscall_windows.go:344 +0x6f internal/poll.(*FD).Read(0xc00007a000, 0xc00033f000, 0x1000, 0x1000, 0x0, 0x0, 0x0) C:/Go/src/internal/poll/fd_windows.go:513 +0x221 os.(*File).read(...) C:/Go/src/os/file_windows.go:220 os.(*File).Read(0xc000006010, 0xc00033f000, 0x1000, 0x1000, 0x6, 0x6, 0x6) C:/Go/src/os/file.go:116 +0x78 bufio.(*Reader).fill(0xc00036a180) C:/Go/src/bufio/bufio.go:100 +0x10a bufio.(*Reader).ReadSlice(0xc00036a180, 0xa8e80a, 0xc0003219c0, 0xe08aa0, 0xc008a22810, 0xbf94956036ef9cc4, 0x10e9171e81) C:/Go/src/bufio/bufio.go:359 +0x44 bufio.(*Reader).ReadBytes(0xc00036a180, 0xa, 0x0, 0xbf94956036ef9cc4, 0x10e9171e81, 0x131f9e0, 0xc008e98440) C:/Go/src/bufio/bufio.go:438 +0x81 bufio.(*Reader).ReadString(...) C:/Go/src/bufio/bufio.go:475 golang.org/x/tools/internal/jsonrpc2.(*headerStream).Read(0xc00035aaa0, 0xe08aa0, 0xc000367b90, 0xc00906f300, 0xc00036a1e0, 0xe08aa0, 0xc008a22810, 0x0, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/jsonrpc2/stream.go:104 +0x99 golang.org/x/tools/internal/jsonrpc2.(*Conn).Run(0xc00036a1e0, 0xe08aa0, 0xc000367b90, 0xde36b0, 0xc69bc0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/jsonrpc2/jsonrpc2.go:317 +0xac golang.org/x/tools/internal/lsp/lsprpc.(*StreamServer).ServeStream(0xc000367920, 0xe08a20, 0xc000032038, 0xdfc4e0, 0xc00035aaa0, 0x0, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/lsprpc/lsprpc.go:154 +0x787 golang.org/x/tools/internal/lsp/cmd.(*Serve).Run(0xc0002dc930, 0xe08a20, 0xc000032038, 0xc000004490, 0x0, 0x0, 0x0, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cmd/serve.go:88 +0x3f3 golang.org/x/tools/internal/tool.Run(0xe08a20, 0xc000032038, 0xe0ca20, 0xc0002dc930, 0xc000004490, 0x0, 0x0, 0x0, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/tool/tool.go:152 +0x2a4 golang.org/x/tools/internal/lsp/cmd.(*Application).Run(0xc0002dc900, 0xe08a20, 0xc000032038, 0xc000004490, 0x0, 0x0, 0x0, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cmd/cmd.go:137 +0x331 golang.org/x/tools/internal/tool.Run(0xe08a20, 0xc000032038, 0xe0c9e0, 0xc0002dc900, 0xc000004490, 0x1, 0x1, 0x0, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/tool/tool.go:152 +0x2a4 golang.org/x/tools/internal/tool.Main(0xe08a20, 0xc000032038, 0xe0c9e0, 0xc0002dc900, 0xc000004490, 0x1, 0x1) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/tool/tool.go:91 +0x136 main.main() C:/Users/L/Go/pkg/mod/golang.org/x/tools/gopls@v0.3.3/main.go:25 +0xe2

goroutine 73 [chan receive]: golang.org/x/tools/internal/lsp/debug.(*Instance).MonitorMemory.func1(0xc000350640, 0xc0002898f0, 0xc00036e000, 0xe08a20, 0xc000032038) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/debug/serve.go:460 +0x6c created by golang.org/x/tools/internal/lsp/debug.(*Instance).MonitorMemory C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/debug/serve.go:458 +0xa0

goroutine 9531 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9501 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x0, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc00067e280, 0x39, 0xc001087900) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc00948d680, 0xc00067e280, 0x39, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc0000e6cc0, 0xc008be6f00, 0xc009372100, 0xc009372160, 0xc008e98b50, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9500 [runnable]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x1, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc00e81cba0, 0x2f, 0xc000c57900) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc00948d650, 0xc00e81cba0, 0x2f, 0x28, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc00acf6ba0, 0xc008be6f00, 0xde3601, 0xde36d8, 0xc000032001, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9532 [runnable]: golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc0000e7c20, 0xc008be6f00, 0xc0036f3e00, 0x449e17, 0xc0036f3f10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:70 +0xc1d golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9530 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9495 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x0, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc000ba2a50, 0x43, 0xc00fffa100) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc00948d620, 0xc000ba2a50, 0x43, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000b51c20, 0xc008be6f00, 0xc0006bde00, 0x449e17, 0xc0006bdf10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9356 [runnable, locked to thread]: syscall.Syscall6(0x7ff95eae2500, 0x5, 0x5a0, 0xc01310da40, 0x123, 0xc000115cc4, 0x0, 0x0, 0x0, 0x0, ...) C:/Go/src/runtime/syscall_windows.go:201 +0xf2 syscall.WriteFile(0x5a0, 0xc01310da40, 0x123, 0x140, 0xc000115cc4, 0x0, 0x7ffff80000000000, 0x4) C:/Go/src/syscall/zsyscall_windows.go:329 +0xd2 syscall.Write(0x5a0, 0xc01310da40, 0x123, 0x140, 0x4773c9, 0x4, 0xc00007a280) C:/Go/src/syscall/syscall_windows.go:369 +0x6f internal/poll.(*FD).Write(0xc00007a280, 0xc01310da40, 0x123, 0x140, 0x0, 0x0, 0x0) C:/Go/src/internal/poll/fd_windows.go:706 +0x275 os.(*File).write(...) C:/Go/src/os/file_windows.go:237 os.(*File).Write(0xc000006018, 0xc01310da40, 0x123, 0x140, 0xc000115e48, 0x1, 0x1) C:/Go/src/os/file.go:153 +0x78 golang.org/x/tools/internal/jsonrpc2.(*headerStream).Write(0xc00035aaa0, 0xe08aa0, 0xc009416cf0, 0xc01310da40, 0x123, 0x140, 0x0, 0x0, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/jsonrpc2/stream.go:157 +0x1db golang.org/x/tools/internal/jsonrpc2.(*Conn).Notify(0xc00036a1e0, 0xe08aa0, 0xc009416cf0, 0xcbf810, 0x11, 0xb5f2e0, 0xc0092cdc40, 0x0, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/jsonrpc2/jsonrpc2.go:120 +0x327 golang.org/x/tools/internal/lsp/protocol.(*clientDispatcher).LogMessage(0xc00028a630, 0xe09120, 0xc0093b2700, 0xc0092cdc40, 0xbba600, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/protocol/tsclient.go:162 +0x74 created by golang.org/x/tools/internal/lsp/protocol.LogEvent C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/protocol/context.go:30 +0x1f3

goroutine 9496 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9504 [runnable]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x0, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc000b212c0, 0x37, 0xc0009af900) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc00948cdb0, 0xc000b212c0, 0x37, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000a4ef60, 0xc008be6f00, 0xc0009afe00, 0x449e17, 0xc0009aff10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9516 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9512 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9507 [runnable]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x1, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc000b21300, 0x32, 0xc01309a100) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc00938e060, 0xc000b21300, 0x32, 0x22, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000484240, 0xc008be6f00, 0xc0019cfe00, 0x449e17, 0xc0019cff10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9525 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9492 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x0, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc000994af0, 0x4d, 0xc001107900) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc00951e930, 0xc000994af0, 0x4d, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc00092b080, 0xc008be6f00, 0xc001107e00, 0x449e17, 0xc001107f10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9490 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x1, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc000443800, 0x32, 0xc00ffe9000) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc005b34ae0, 0xc000443800, 0x32, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc00027d440, 0xc008be6f00, 0xc001435e00, 0x449e17, 0xc001435f10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9510 [running]: goroutine running on other thread; stack unavailable created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9519 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9506 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x0, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc00084b280, 0x3a, 0xc001511900) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc00938e030, 0xc00084b280, 0x3a, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc0008472c0, 0xc008be6f00, 0xc001511e00, 0x449e17, 0xc001511f10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9534 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9498 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x1, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc0000b1dc0, 0x3b, 0xc003a47900) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc009416f90, 0xc0000b1dc0, 0x3b, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000a4f560, 0xc008be6f00, 0xc003a47e00, 0x449e17, 0xc003a47f10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9511 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9529 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9359 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x1, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc0004cfa80, 0x3e, 0xc013072b00) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc00951e120, 0xc0004cfa80, 0x3e, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000a7fb60, 0xc008be6f00, 0x2030000, 0xddeb0f, 0x50, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9524 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x0, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc0008fd380, 0x3f, 0xc003ac1900) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc009597890, 0xc0008fd380, 0x3f, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000847f20, 0xc008be6f00, 0x0, 0x1, 0x0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9358 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x0, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc0004cf700, 0x3a, 0xc0019bd900) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc009597350, 0xc0004cf700, 0x3a, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000b51ec0, 0xc008be6f00, 0xc00004a000, 0xc0019bdd98, 0x403f6f, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9517 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9508 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x0, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc000bc1d40, 0x3a, 0xc00372f900) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc00938e1b0, 0xc000bc1d40, 0x3a, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000a4f140, 0xc008be6f00, 0xc00372fe00, 0x449e17, 0xc00372ff10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9491 [runnable]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x1, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc000a49b00, 0x3f, 0xc013072e00) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc00951e960, 0xc000a49b00, 0x3f, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000a4eae0, 0xc008be6f00, 0xc0037abe00, 0x449e17, 0xc0037abf10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9535 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9514 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9520 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x0, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc0003c4910, 0x46, 0xc003963900) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc00938e000, 0xc0003c4910, 0x46, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000a4e900, 0xc008be6f00, 0xc003963d00, 0xa9f3cd, 0xc0003645b0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9536 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x1, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc00092fd00, 0x35, 0xc00132f900) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc00948d5f0, 0xc00092fd00, 0x35, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc00acf68a0, 0xc008be6f00, 0xc00132fe00, 0x449e17, 0xc00132ff10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9497 [runnable]: sync.runtime_SemacquireMutex(0xc0004475d4, 0xc00fec5501, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc0052d6f60, 0x53, 0xc00fec5600) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.addReports(0xe08aa0, 0xc005b34d50, 0xe1b540, 0xc00ace1500, 0xc005b34cf0, 0xc0052d6f60, 0x53, 0xc002bd59c8, 0x1, 0x1, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:325 +0x84 golang.org/x/tools/internal/lsp/source.diagnostics(0xe08aa0, 0xc005b34d50, 0xe1b540, 0xc00ace1500, 0xc005b34cf0, 0xe197e0, 0xc005302160, 0x0, 0xc00873d300, 0x0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:211 +0x788 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000847b60, 0xc008be6f00, 0xc003a15e00, 0x449e17, 0xc003a15f10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:118 +0x57e golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9527 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9523 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9361 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x1, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc000ba2410, 0x43, 0xc00ffe9500) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc00951e0f0, 0xc000ba2410, 0x43, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000b51a40, 0xc008be6f00, 0xc00004a000, 0xc0039cdd98, 0x403f6f, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9360 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x0, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc00093f900, 0x32, 0xc00fe39a00) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc009416de0, 0xc00093f900, 0x32, 0x25, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc00acf6a20, 0xc008be6f00, 0xc000045000, 0xc003a4bd98, 0x403f6f, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9515 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9503 [running]: goroutine running on other thread; stack unavailable created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9526 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9513 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9533 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9392 [semacquire]: sync.runtime_Semacquire(0xc010ae7328) C:/Go/src/runtime/sema.go:56 +0x49 sync.(*WaitGroup).Wait(0xc010ae7320) C:/Go/src/sync/waitgroup.go:130 +0x6b golang.org/x/tools/internal/lsp.(*Server).diagnose(0xc000293100, 0xe089e0, 0xc005e4b080, 0xe1b540, 0xc00ace1500, 0x468a00, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:143 +0x741 golang.org/x/tools/internal/lsp.(*Server).diagnoseSnapshot(0xc000293100, 0xe1b540, 0xc00ace1500) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:38 +0x8e created by golang.org/x/tools/internal/lsp.(*Server).didModifyFiles C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/text_synchronization.go:229 +0x718

goroutine 9521 [semacquire]: sync.runtime_SemacquireMutex(0xc0004475d4, 0x0, 0x1) C:/Go/src/runtime/sema.go:71 +0x4e sync.(*Mutex).lockSlow(0xc0004475d0) C:/Go/src/sync/mutex.go:138 +0x103 sync.(*Mutex).Lock(...) C:/Go/src/sync/mutex.go:81 golang.org/x/tools/internal/lsp/cache.(*view).Ignore(0xc000447400, 0xc0008335e0, 0x42, 0xc00588f900) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/cache/view.go:492 +0x1ba golang.org/x/tools/internal/lsp/source.clearReports(0xe1b540, 0xc00ace1500, 0xc009597e00, 0xc0008335e0, 0x42, 0x24, 0x0) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:313 +0x70 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000847800, 0xc008be6f00, 0xc00588fd00, 0x1, 0xc00588fd88, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:90 +0xa2b golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9518 [runnable]: golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9503 [running]: runtime.throw(0xcda4c5, 0x26) C:/Go/src/runtime/panic.go:1112 +0x79 fp=0xc003797908 sp=0xc0037978d8 pc=0x437da9 runtime.mapiternext(0xc003797bb8) C:/Go/src/runtime/map.go:853 +0x559 fp=0xc003797988 sp=0xc003797908 pc=0x410309 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc00092a420, 0xc008be6f00, 0xc003797f00, 0x7521f6, 0xc003797ea8, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:70 +0xc1d fp=0xc003797d20 sp=0xc003797988 pc=0x793d8d golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec fp=0xc003797f88 sp=0xc003797d20 pc=0xaba48c runtime.goexit() C:/Go/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc003797f90 sp=0xc003797f88 pc=0x468a71 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717

goroutine 9510 [running]: runtime.throw(0xcd5652, 0x21) C:/Go/src/runtime/panic.go:1112 +0x79 fp=0xc000593918 sp=0xc0005938e8 pc=0x437da9 runtime.mapaccess2_faststr(0xbba3c0, 0xc008be6f00, 0xc000747bc0, 0x22, 0x134fc20, 0x0) C:/Go/src/runtime/map_faststr.go:116 +0x483 fp=0xc000593988 sp=0xc000593918 pc=0x413be3 golang.org/x/tools/internal/lsp/source.Diagnostics(0xe08aa0, 0xc0086d6b40, 0xe1b540, 0xc00ace1500, 0xe0c9a0, 0xc000484840, 0xc008be6f00, 0xc000593e00, 0x449e17, 0xc000593f10, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/source/diagnostics.go:66 +0x1c0 fp=0xc000593d20 sp=0xc000593988 pc=0x793330 golang.org/x/tools/internal/lsp.(*Server).diagnose.func2(0xc010ae7320, 0xc010046c00, 0xe1b540, 0xc00ace1500, 0xc008f08220, 0xc008be6f00, 0xc000293100, 0xc010ae7308, 0xc0089bd2f0, 0xe0c9a0, ...) C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:116 +0x1ec fp=0xc000593f88 sp=0xc000593d20 pc=0xaba48c runtime.goexit() C:/Go/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc000593f90 sp=0xc000593f88 pc=0x468a71 created by golang.org/x/tools/internal/lsp.(*Server).diagnose C:/Users/L/Go/pkg/mod/golang.org/x/tools@v0.0.0-20200227200655-6862ededa516/internal/lsp/diagnostics.go:107 +0x717 [Error - 下午4:38:30] Connection to server got closed. Server will not be restarted.

</details>

closed time in 2 months

hyangah

issue commentgolang/go

x/tools/internal/lsp/source: panic due to concurrent map access

Duplicate of #37798. Release is targeted for today.

hyangah

comment created time in 2 months

issue commentmicrosoft/vscode-go

Cryptic Error message when opening folder in your GOPATH

Can you show the complete output of go env? In particular, are your GOROOT and GOPATH overlapping?

@bcmills @jayconrod

WodansSon

comment created time in 2 months

issue commentgolang/go

x/tools/gopls: crashed when parsing invalid URL

The log message at the top is unrelated and not fatal -- the actual problem is during completion. Looks like a dupe of https://golang.org/issue/37615. @muirmanders @stamblerre

blithefeng

comment created time in 2 months

issue commentgolang/go

gopls has no code hints when using third-party packages

You'll need to open the directory containing a go.mod, in your case "Hello world".

qianniancn

comment created time in 2 months

issue closedgolang/go

x/tools/gopls: support case insensitive file systems

gopls doesn't support case-insensitive file systems. VS Code always sends lower-case drive letters, but if a user sets their GOPATH to C://bob/go, go list will return upper-case drive letters. At that point, gopls will think it did not get metadata for the given file, and it will not work correctly.

closed time in 3 months

stamblerre

issue commentgolang/go

x/tools/gopls: support case insensitive file systems

There might be other stuff we can do but in general I would hope that everything would be case-preserving and it wouldn't matter. I say close.

stamblerre

comment created time in 3 months

issue commentgolang/go

x/tools/gopls: uses too much memory (60G)

Thanks again.

I don't see any signs of a bug here but this is a massive heap. Are you using gopls in a large monorepo, or do you have huge code-generated files?

bobotu

comment created time in 3 months

issue commentgolang/go

x/tools/gopls: uses too much memory (60G)

Thanks for the report. There should be some files named gopls.PID- in your temporary directory, named after heap sizes. Please upload the pair for the largest heap -- I would like to see a goroutine dump that matches this heap dump.

bobotu

comment created time in 3 months

issue commentcensus-instrumentation/opencensus-go

Critical: Nondeterministic 100% CPU spin during init() causes programs to hang

Strange. If goroutine 1 is running, I don't know why only g0s are showing up in the crash traceback. Maybe there really is a scheduler bug??

mholt

comment created time in 3 months

issue commentgolang/go

cmd/go: We should have one universal format tool (incorporate goimports into go fmt).

My immediate reaction is that goimports is too complicated and buggy to be tied to the main Go release cycle. The import grouping specifically has known bugs related to comments. But it has been getting more stable over time, so maybe?

JeremyLoy

comment created time in 3 months

issue openedgolang/go

x/tools/gopls: support multi-project workspaces

This is a place to discuss multi-project workspaces in gopls. Design doc forthcoming.

created time in 3 months

issue commentgolang/go

x/tools/gopls: high memory consumption when used with a monorepo

Thanks.

Unfortunately I don't have good news for you. Everything you've posted points to expected behavior -- I don't see any signs of a memory leak or work pileup. It looks like the monorepo is simply too large to work with all at once.

If you're only interested in one folder, you can start VS Code in that folder. If you're interested in multiple, you can add them piecemeal to your workspace, but note that most gopls features, e.g. find references, will only work within one folder.

trapgate

comment created time in 3 months

issue commentgolang/go

cmd/go: SWIG causes generated C++ sources in CompiledGoFiles

@bcmills @jayconrod

noahgoldman

comment created time in 3 months

issue commentgolang/go

x/tools/gopls: workspace symbol breaks mysteriously with swig package

I take it back -- we are ignoring the errors from #36129. #37098 is what kills it.

jackielii

comment created time in 3 months

issue commentgolang/go

x/tools/gopls: high memory consumption when used with a monorepo

There should be some files named gopls.PID- in your temporary directory, named after heap sizes. Please upload the pair for the largest heap.

trapgate

comment created time in 3 months

issue commentgolang/go

x/tools/gopls: workspace symbol breaks mysteriously with swig package

The cause of the error is #36129. It might be reasonable for workspace symbols to continue despite it.

jackielii

comment created time in 3 months

issue commentmicrosoft/vscode-go

Crash when using gopls and liveshare: only file URIs are supported, got "vsls" from "vsls:/"

In general this doesn't look very feasible to me; even if we process almost everything as an overlay, we still need a filesystem location for the go.mod and to root the overlay. vsls:/ gives us nothing.

Is there any documentation on how VSLS works? I couldn't find any offhand. Do we actually need to have gopls run locally, or only on the session host?

didrocks

comment created time in 3 months

issue commentgolang/go

x/tools/gopls: Cannot install 0.3.1 with go get

Sorry, I'm confused. To me this is very clearly a duplicate of #34092. Possibly that fix should be/have been backported to 1.13, but other than that, what is there still to diagnose here?

paulbdavis

comment created time in 3 months

more