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

GOBIN: undefined
toolsGopath: /Users/richardd/.vscode/godev
gopath: /Users/richardd/go
GOROOT: /usr/local/go
PATH: /Users/richardd/.nvm/versions/node/v16.2.0/bin:/opt/dropbox-override/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/whoseisit/bin:/usr/local/engtools/darwin/bin:/usr/local/engtools/common/bin:/usr/local/go/bin:/opt/homebrew/bin:/usr/local/arcanist/bin:/Library/Apple/usr/bin:/Users/richardd/go/bin:/usr/local/go/bin

	go:	/usr/local/go/bin/go: go version go1.18.4 darwin/arm64

	gotests:	not installed
	gomodifytags:	not installed
	impl:	not installed
	goplay:	not installed
	staticcheck:	/Users/richardd/.vscode/godev/bin/staticcheck	(version: v0.3.2 built with go: go1.18.4)
	gopls:	/Users/richardd/.vscode/godev/bin/gopls	(version: v0.9.1 built with go: go1.18.4)

go env
Workspace Folder (rSERVER): /Users/richardd/src/server
	GO111MODULE=""
	GOARCH="arm64"
	GOBIN=""
	GOCACHE="/Users/richardd/Library/Caches/go-build"
	GOENV="/Users/richardd/Library/Application Support/go/env"
	GOEXE=""
	GOEXPERIMENT=""
	GOFLAGS=""
	GOHOSTARCH="arm64"
	GOHOSTOS="darwin"
	GOINSECURE=""
	GOMODCACHE="/Users/richardd/go/pkg/mod"
	GONOPROXY=""
	GONOSUMDB=""
	GOOS="darwin"
	GOPATH="/Users/richardd/go"
	GOPRIVATE=""
	GOPROXY="https://proxy.golang.org,direct"
	GOROOT="/usr/local/go"
	GOSUMDB="sum.golang.org"
	GOTMPDIR=""
	GOTOOLDIR="/usr/local/go/pkg/tool/darwin_arm64"
	GOVCS=""
	GOVERSION="go1.18.4"
	GCCGO="gccgo"
	AR="ar"
	CC="clang"
	CXX="clang++"
	CGO_ENABLED="1"
	GOMOD="/dev/null"
	GOWORK="/Users/richardd/src/server/go.work"
	CGO_CFLAGS="-g -O2"
	CGO_CPPFLAGS=""
	CGO_CXXFLAGS="-g -O2"
	CGO_FFLAGS="-g -O2"
	CGO_LDFLAGS="-g -O2"
	PKG_CONFIG="pkg-config"
	GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_8/bycsrbvd2dv2pptr3nqnyyqh0000gn/T/go-build3856595532=/tmp/go-build -gno-record-gcc-switches -fno-common">

Share the Go related settings you have added/edited

Run Preferences: Open Settings (JSON) command to open your settings.json file.
Share all the settings with the go. or ["go"] or gopls prefixes.

I can't show all, namely directory filters, for work reasons. I have also changed these configuration settings every which way trying to get a viable solution running over the past week. [Below are just snippets in case someone is curious about formatting].

    "go.useLanguageServer": true,
    "editor.maxTokenizationLineLength": 50000,
    "go.toolsGopath": "~/.vscode/godev",
    "go.trace.server": "verbose",
        "go.lintOnSave": "off",
    "go.vetOnSave": "off",
    "go.buildOnSave": "off",
    "gopls": {
      "verboseOutput": true,
      "build.memoryMode": "DegradeClosed", //Same situation with this off or on
      "ui.diagnostic.staticcheck": false,
      "build.experimentalUseInvalidMetadata": true,    
      "ui.navigation.importShortcut": "Definition",
      "ui.documentation.linksInHover": false,
      "ui.codelenses": {
        "generate": true,
        "regenerate_cgo": false,
        "tidy": false, 
        "upgrade_dependency": false,
      },    

Describe the bug

A clear and concise description of what the bug.
We recently transitioned a very large 70gb+ monorepo from GOPATH to go.work/go.mod. Use of the language server has definitely been a bumpy transition for local M1 mac devs.

On workspace open from configuration file, there is an initial ~1 minute workspace load time (no problem at all, it is a large repo). Once things have loaded, and a specific go file is opened, everything is initially populated great. All inlay hover actions work great, errors are populated if they exist before hand, and even with normal memory mode on, all directory wide errors are populated. You can even make an edit to the code and save once with inlay hovers continuing to work.

However, once you run a second save, there seems to be some cache invalidation as you experience the classic "waiting for code actions from Go" pop-up and inlay hovers just read "loading". After about 2 minutes, the loading/waiting is done and the full code base is completely usable by gopls. Everything is linted as you need it on save, all hover actions work, everything works fine.

This occurs every time you load the workspace. It's almost as if the initial load is populating cache somewhere else or something. Verbose gopls server traces show it's always the second fixImports call on save.

A couple of findings:
1.) I added quite a bit of logging to the go extensions goMain.js file. In most of the logs, you can see that it completed registering the language provider/document symbols after the hang up ( see the jump from 11:49 to 11:52 in image 1). In others, it reports that the extension host has started profiling the connection and attached the debugger with document symbols returning after a ~1 minute jump (image 2).

This is confirmed every single time this occurs by vs code extension logs reporting something along the lines of the second the hang up occurs:
[2022-07-15 11:22:42.390] [main] [info] Enabling inspect port on extension host with pid 47681

2.) I then switched over to adding a lot of logging to the gopls bin. This reports that it was able to find and return the document symbols in a timely manner.

3.) This identical configuration works perfectly on our linux remote hosts. There is an initial ~1 minute load and then things work great. It seems like it's actually able to call and retrieve the data quick as well. Sometimes there is a momentary hang up with "loading" on hover but the data is returned and hover inlays populated in ~1-2 seconds.

Some thoughts:
1.) Potential culprit is a few +linux .go files we have that are reported when gopls is initial building the workspace. You receive a lot of No dep handle found for {+linux file name}. I have tried to remove these package directories via the build.DirectoryFilters but they are always processed both when the workspace loads and when fixImports occurs.
When I add a:

      "build.buildFlags": [
        "-tags=linux",

or use test as the build tag, these errors are not reported but the hang up still occurs.
I had a thought that maybe gopls was building these with the linux flag and storing them in modcache as such so have since removed them.

2.) One interesting thing I noticed is sometimes if you completely remove all go tools, modcache, and the go vs code extension, then reinstall them, and load the workspace, things work fine: you have the initial workspace load, traverse to a go file, and things run snappy. This kind of reinforced my thoughts on removing the linux build tag.

3.) I had another hunch that this was potentially dlv related. It doesn't appear as though dlv is available for vscode with an m1, it didn't pop up as an installable tool until I set:

    "go.toolsEnvVars": {
      "GOOS": "linux",
      }

dlv is of course immediately available on our linux builds. When I saw the Debugger attached log from Extension Host while viewing the goMain.js logs, I thought maybe that was dlv attaching itself to gopls. I'm not sure on this one at all, just worth noting.

4.) Running  gopls -rpc.trace -v check path/to/file.go takes about ~30 seconds, performs a full sweep of our go workspace form the looks of it and reports the same no dep handle for and c compiler issues. It just runs faster from the looks of it.

A clear and concise description of what you expected to happen.
Go through the initial ~1 minute workspace load then have gopls be usable for the entire stack, or at least module, on an M1 mac.

Steps to reproduce the behavior:

• This might be tricky, I'd be happy to dm as it would most likely involve disclosing some private information. I believe y'all have been working with a colleague on creating a map for the cache.

1. Go to '...'
2. Click on '....'
3. See error

Screenshots or recordings

If applicable, add screenshots or recordings to help explain your problem.