I'll start looking into this.

@myitcv it looks like #34842 has a discussion about adding the "go" directive whenever we run "go list". I think this is intended behavior on the part of that command.

Change https://golang.org/cl/212477 mentions this issue: internal/lsp: modify how we check for go 1.14 for modfiles

I think this is intended behavior on the part of that command.

@ridersofrohan yes, that matches my understanding of cmd/go.

But this is not expected behaviour when running with tempModfile = true. Because in that mode (per #34506) it was my understanding we are not expecting any changes to be made to the go.mod file at all.

Ahh I see what you mean, the above CL should fix this issue when it gets merged in.

@myitcv let me know if this is working as you expect it to now and I will close the issue.

Thanks @ridersofrohan

Per #36463 (comment) it's a little tricky for us to test this right now because your fix landed after https://go-review.googlesource.com/c/tools/+/212102 which introduced the problems described in #36463

I'll see whether I can cherry-pick this commit and test.

@ridersofrohan I just tested with 53017a3 plus 11e9d9c and acbc0e3 cherry-picked on top. Following the exact same test as before, I am now seeing go.mod be updated to include not only the go directive but also the requirement. i.e. it's almost as if the configuration value is being ignored entirely.

Is there a test on the gopls side that verifies this is working?

It might well be my cherry-picking has failed...

@myitcv while working on a different issue, I found a potential problem with the previous CL. This should be addressed in commit/f270e23f which just got merged in. Let me know if this fixes that issue, I will also look into adding a test in gopls to check for this.

Thanks - checked against 700ee26 and all seems to be sorted now.

I will also look into adding a test in gopls to check for this

Thanks - otherwise it's really impossible to know if/when this gets broken.

Change https://golang.org/cl/214260 mentions this issue: internal/lsp/mod: test go.mod unchanged when tempModfile=true

@ridersofrohan we're seeing an issue here again against x/tools and gopls d456b1c.

Repro via dockexec:

cd $(mktemp -d)
git clone https://github.com/govim/govim
cd govim
git fetch origin pull/634/head && git checkout FETCH_HEAD
sed -i '/skip/d' cmd/govim/testdata/scenario_tempmodfile/modfile_changes.txt
go test -exec="dockexec govim/govim:go1.14beta1_vim_v8.2.0025_v1 -t -e VIM_FLAVOR=vim -e GOVIM_ERRLOGMATCH_WAIT=5s" -count=1 -v -run "TestScripts/scenario_tempmodfile/modfile_changes" ./cmd/govim

gives:

    TestScripts/scenario_tempmodfile/modfile_changes: testscript.go:348:
        WORK=$WORK
        PATH=/vim/bin:/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
        HOME=$WORK/.home
        TMPDIR=$WORK/_tmp
        devnull=/dev/null
        :=:
        exe=
        GOPATH=$WORK/.home/gopath
        CCACHE_DISABLE=1
        GOARCH=amd64
        GOOS=linux
        GOROOT=/go
        GOCACHE=/gocache
        GOPROXY=http://127.0.0.1:34127/mod
        goversion=1.14
        GOVIM_ERRLOGMATCH_WAIT=5s
        GOVIM_DETECT_USER_BUSY=false
        GONOSUMDB=*
        PLUGIN_PATH=/start
        GOVIMTEST_SOCKET=127.0.0.1:45987
        GOVIMTESTDRIVER_SOCKET=127.0.0.1:45405

        # A simple test that verifies we get a diagnostic for changes
        # that need to be made to our go.mod file
        # Open main.go and save to ensure we are actually doing something via gopls (0.154s)
        > vim ex 'e main.go'
        > vim ex 'w'
        # Sleep because we don't have an event we are waiting for (5.002s)
        > sleep $GOVIM_ERRLOGMATCH_WAIT
        # Verify that there have been no changes to go.mod (0.006s)
        > cmp go.mod go.mod.golden
        [diff -go.mod +go.mod.golden]
         module mod.com

        -go 1.14

        FAIL: testdata/scenario_tempmodfile/modfile_changes.txt:15: go.mod and go.mod.golden differ

--- FAIL: TestScripts (1.35s)
    --- FAIL: TestScripts/scenario_tempmodfile (0.04s)
        --- FAIL: TestScripts/scenario_tempmodfile/modfile_changes (5.39s)

@myitcv I'm looking into it now.

Change https://golang.org/cl/215978 mentions this issue: internal/imports: add buildflags to ProcessEnv

@myitcv ^ the above CL should have fixed this issue. Sorry for missing this the first time, let me know if it works or still shows up.

@ridersofrohan. No problems. Did the repro above work for you?

Sorry, that was unclear. Did the test in the repro above pass with the changes?

I'm not sure how to run that test. I just manually tested it using VSCode.

@myitcv, I tried to repro with your example, but how do I pass it my local version of gopls?

With gopls from master and Go 1.14, the test gets past the cmp and fails later:

        # Verify that there have been no changes to go.mod (0.000s)
        > cmp go.mod go.mod.golden
        # Verify that we have no diagnostics for any files (25.766s)
        > vimexprwait errors.empty getqflist()
        [stderr]
        -[]
        [exit status 1]
        FAIL: testdata/scenario_tempmodfile/modfile_changes.txt:18: unexpected command failure

Dunno what that means but I would think this bug, at least, is fixed.

I would think this bug, at least, is fixed.

It is. Thanks all

@stamblerre

how do I pass it my local version of gopls?

Not currently possible, but will be once govim/govim#720 lands