x/tools/gopls: when editing Go files in GOMODCACHE, offer to clone module and add replace directive

[adonovan]

Being able to quickly edit the standard library (e.g. by inserting a print statement) is extremely useful during debugging. However, editing source files from dependencies within the module cache is not as convenient. Gopls could detect an attempt to modify such a file and offer to clone the module, add a replace directive to the main module, and move the cursor to the corresponding position in the cloned file, which can then be freely edited. The replace directive could be flagged with a // FIXME: debugging comment, with a code action to revert it.

(Credit to @prattmic for the idea.)

[prattmic]

Being able to quickly edit the standard library (e.g. by inserting a print statement) is extremely useful during debugging. However, editing source files from dependencies within the module cache is not as convenient.

FWIW, I expect that for the vast majority of users, editing the standard library is also difficult because the standard library is either in the module cache (GOTOOLCHAIN) or /usr/lib or something (system install).

Support for getting an editable copy of std would be great too, but I expect that is more involved, as it needs to change the toolchain that is used for builds.

[adonovan]

I expect that is more involved, as it needs to change the toolchain that is used for builds.

Yeah, that's why I neglected to mention it. Also, installing GOROOT is a relatively high-value one-time investment for a Go developer, so I expect more people have done it already.

[gabyhelp]

Related Issues

• x/tools/gopls: handle replace directives #36745 (closed)
• x/tools/gopls: provide links for replace in go.mod #73423 (closed)
• x/tools/gopls: consider to suppress diagnostics on code in GOMODCACHE #52106
• proposal: cmd/go: Is it possible to support replace the standard library in go module? #66780 (closed)
• cmd/go: support simultaneous edits of interdependent modules #27542 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[mwriter]

Being able to quickly edit the standard library (e.g. by inserting a print statement) is extremely useful during debugging

Don't you think this is very consistent with the existing concept of overlays in golang?
Which just requires development.

[adonovan]

Don't you think this is very consistent with the existing concept of overlays in golang?

That's an interesting question. Already today, editing the GOMODCACHE files causes gopls to reflect their new contents in the results of its queries (definition, references, etc). In principle, if gopls had a good way to run a test via gopls code action, it too would reflect the source changes. Unfortunately the source.test code action is disabled by default since it would compete with VS Code's dedicated test runner. Also, it requires that all editor buffers are saved, because even though the build executed by the go test respects overlays, I/O done by the test process does not.

[mwriter]

Also, it requires that all editor buffers are saved

But we can create temporary files. Exactly the same as it is happening now with an incremental build.
And theoretically this can be done directly in RAM.
Another thing is that I don't like the way relative paths are being resolved for overlays right now. But this should not be an obstacle in this case.