x/tools/gopls: remove the "allowModfileModifications" setting

[findleyr]

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

Quoting: #56570 (comment):

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 [email protected], and remove in [email protected].

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!

[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.

[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.

[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.

[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.

[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.

[findleyr]

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

[gopherbot]

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

[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!

[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.

[jabbottn]

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

[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?