I am unable to get any indication that gopls has crashed with the given examples.
Please provide the full file (examples are missing the package line at least) and what indicates that gopls has crashed.

Does not crash with:

package main

type a *a
var x a = x

func main() {

}

Still does not crash with a invalid file containing exactly:

type a *a
var x a = x

It is not a gopls bug then. I am testing on vscode and this exact same program causes vscode to hang while "Getting actions from 'Go'"

I too am running vscode and got no such thing.

However what you are describing sounds a lot like vscode is still starting up, when you do a fresh launch of vscode it is known to sometimes take a while to startup all the plugins and related tools so if you do a edit and save too quickly then it has to wait for all of that to finish loading.

Try waiting a few minutes after oppening vscode and see if it still hangs.

@soypat: Can you please share your Go version? This type of bug may have been fixed with later versions of Go.

I could reproduce this behavior:

package main

type a *a

var x a = <> // try to complete

func main() {}

gopls doesn't crash but stops responding. It is caused by a loop in golang.org/x/tools/internal/lsp/source.Deref():

func Deref(typ types.Type) types.Type {
	for {
		p, ok := typ.Underlying().(*types.Pointer)
		if !ok {
			return typ
		}
		// log.Printf("current typ:            %#v\n", typ)
		// log.Printf("new typ (pointer elem): %#v\n", p.Elem())
		typ = p.Elem()
	}
}

typ is equal to typ.Underlying().(*types.Pointer).Elem():

current typ:            &types.Named{info:0x2, obj:(*types.TypeName)(0xc005e04dc0), orig:(*types.Pointer)(0xc00559db60), underlying:(*types.Pointer)(0xc00559db60), methods:[]*types.Func(nil)}
new typ (pointer elem): &types.Named{info:0x2, obj:(*types.TypeName)(0xc005e04dc0), orig:(*types.Pointer)(0xc00559db60), underlying:(*types.Pointer)(0xc00559db60), methods:[]*types.Func(nil)}

So, this loop is infinite.

golang.org/x/tools/internal/lsp/source.Deref()
  github.com/golang/tools/internal/lsp/source/util.go:233

golang.org/x/tools/internal/lsp/source/completion.(*completer).lexical()
  github.com/golang/tools/internal/lsp/source/completion/completion.go:1352

golang.org/x/tools/internal/lsp/source/completion.(*completer).collectCompletions()
  github.com/golang/tools/internal/lsp/source/completion/completion.go:643

golang.org/x/tools/internal/lsp/source/completion.Completion()
  github.com/golang/tools/internal/lsp/source/completion/completion.go:554 +0xe56

Ok I can reproduce this now but the steps to reproduce wasn't clear.

First create a file and fill it with and save:

package main

type a *a

var x a = <> // try to complete

func main() {}

Next edit this line and save again:
var x a = nil

Sorry. I'll make sure steps are clearer next time. Did not think saving the file was crucial part of steps

Thanks for figuring out the cause of this bug, @ShoshinNikita! Do you want to send the CL to fix it or would you rather a member of the gopls team take it on?

I would be happy to send a CL but I am not sure about the fix. Should we just return the current typ in such situations?

Yeah I think that would work.

Change https://golang.org/cl/310050 mentions this issue: internal/lsp/source: fix an infinite loop in Deref function

I don't think this fix is sufficient for cyclic types like:

type (
	foo *bar
	bar *foo
)

Yeah, the current fix doesn't work for such cyclic types. I think we can use map[types.Type]struct{} with all previous underlying types to detect cycles.

One slight optimization is that you only have to worry about named pointer types (i.e. you only have to allocate/insert into your map when you see a named pointer type).

Change https://golang.org/cl/310311 mentions this issue: internal/lsp/source: fix Deref function for cyclic types