Following up on #56570, we should remove the deprecated allowModFileModifications setting.

Quoting: https://github.com/golang/go/issues/56570#issuecomment-1925848022:

Generally speaking, this setting means "whatever the go command does to your go.mod file is OK". That's not a coherent mode of operation for gopls to support, which is why it has no test coverage. Additionally, the documentation says "this option will eventually be removed".

We should surface the deprecation notice in gopls@v0.15.0, and remove in gopls@v0.16.0.

I don't think this setting works well, so I don't see how it could be useful to any users. However, if you need this setting, please explain why!

Comment From: tuxerrante

After adding the related setting in the gopls section I still have the same error.

settings.json

 {
   ...
   "gopls": {
        "build.allowModfileModifications": false
    }
}

A VSCode restart didn't solve.

Comment From: metal3d

Using CoC on neovim, if I don't use this setting, I need to close, then go mod tidy, then reopen the project to make gopls accept newly installed package imports.

So, maybe it's necessary, or, if not, having a workaround for this.

Comment From: findleyr

@metal3d

A couple comments: - You can add "languageserver": { "go": { "filetypes": ["go", "gomod"] } } to your coc-settings.json to enable gopls for go.mod files. Then it should (1) sync go.mod file changes to gopls automatically, and (2) suggest a code lens to run go mod tidy. - You don't need to restart to reopen the project to restart gopls: just run :CocRestart.

In general, the behavior of letting the go command mutate the mod file is not well supported. It is bad behavior for a language server to modify file content without an explicit user action.

Comment From: findleyr

@tuxerrante sorry I don't understand what you're saying. I think you want the nagging warning to go away? In that case, please remove this setting from your settings.json file.

Comment From: tuxerrante

@tuxerrante sorry I don't understand what you're saying. I think you want the nagging warning to go away? In that case, please remove this setting from your settings.json file.

I had the issue already before adding that setting. I was trying different possibilities in order to make the warning go away. That's what I meant.

Comment From: findleyr

@tuxerrante, with empty settings.json you should not get any warnings about this setting. Perhaps it is set in workspace settings?

Comment From: gopherbot

Change https://go.dev/cl/579435 mentions this issue: gopls/internal/settings: remove support for "allowModfileModifications"

Comment From: tuxerrante

@tuxerrante, with empty settings.json you should not get any warnings about this setting. Perhaps it is set in workspace settings?

It was hidden in the user settings under AppData, not sure which plugin could have created it. thanks!

Comment From: jabbottn

Removing this completely breaks autocomplete for me in vscode due to private repos and the way that we are using the go project we have with bazel and generated code. Please add this setting back to future versions of gopls or something like it to restore autocomplete functionality.

Comment From: jabbottn

For now, I am downgrading to v0.15.0 to restore functionality.

Comment From: findleyr

@jabbottn sorry to hear that, but we really can't support a setting like "allowModfileModifications", as breaks the principle that clients have control over state changes, and introduces quite a bit of complexity into gopls. Can you share more about your workflow so that we can understand how best to accommodate it? Can you insert a go mod tidy after your code generation to preserve mod tidiness?