Stale cache due to not regenerated .a files

[didrocks]

Hey, Thanks for gocode, it's been a bless to use in my editor (Visual Studio Code)!

I have an issue with some stale cache, on Linux (Ubuntu 64 bits 16.04LTS). I'm running latest updated tip (hash 478b96fe0e77b4451b866559e2adb407fbce7120) gocode with Go 1.7

I did notice some staled cache on my packages, and the new/removed exported structs, variables, or any data fields were not seen by gocode when requesting completion.

I saw that gocode, when completion is requested, is generating the static libraries, .a files, and seems to use them as a reference.

ls -l $GOPATH/pkg/linux_amd64/<path_to_project>/                                                                                         total 32
-rw-rw-r-- 1 didrocks didrocks  3252 oct.  27 14:29 dirs.a
-rw-rw-r-- 1 didrocks didrocks  8644 oct.  27 14:29 logger.a
-rw-rw-r-- 1 didrocks didrocks 16076 oct.  27 14:29 state.a

I notice that, making a (valid) change to the state package for instance, that gocode doesn't regenerate state.a (still same size and timestamp), and so, doesn't offer the new exposed struct. However, running

gocode close
gocode --debug -s

shows the partially new state file content. For instance: Adding Abc struct for testing:

package state

// State that can be a snap in
type State struct {
    Channel  string
    DevMode  bool
    Revision string
    Version  string
}

// Transition from one state to another one
type Transition struct {
    Action Action
    Next   *State
}

// Action associated to a Transition
type Action int

const (
    // Install or update a snap
    Install = iota
    // Revert a snap
    Revert
    // Remove a snap
    Remove
)

type Abc strin#
2016/10/27 14:44:38 -------------------------------------------------------
2016/10/27 14:44:38 Found "io/ioutil" at "/home/didrocks/tools/go/pkg/linux_amd64/io/ioutil.a"
2016/10/27 14:44:38 Found "path" at "/home/didrocks/tools/go/pkg/linux_amd64/path.a"
2016/10/27 14:44:38 Found "github.com/ubuntu/snaps-manager/dirs" at "/home/didrocks/workspace-go/pkg/linux_amd64/github.com/ubuntu/snaps-manager/dirs.a"
2016/10/27 14:44:38 Found "github.com/ubuntu/snaps-manager/logger" at "/home/didrocks/workspace-go/pkg/linux_amd64/github.com/ubuntu/snaps-manager/logger.a"
2016/10/27 14:44:38 Found "gopkg.in/yaml.v2" at "/home/didrocks/workspace-go/pkg/linux_amd64/gopkg.in/yaml.v2.a"
2016/10/27 14:44:38 Offset: 5
2016/10/27 14:44:38 Number of candidates found: 1
2016/10/27 14:44:38 Candidates are:
2016/10/27 14:44:38   type string built-in
2016/10/27 14:44:38 =======================================================

and state.Abc isn't proposed on autocompletion. If you look closely, string isn't complete (compared to file on disk). Would that we why state.a isn't regenerated (triggering a failed compilation too early?), but nothing is showing this in gocode logs.

The .a files are unchanged. Removing them and requesting completion again fixes it once they are regenerated.

If so, this could be an issue with Visual Studio Code plugin itself:

Finished running tool: /home/didrocks/tools/go/bin/go tool vet /home/didrocks/workspace-go/src/github.com/ubuntu/snaps-manager/state/state.go

Finished running tool: /home/didrocks/tools/go/bin/go build -o /tmp/go-code-check -tags "" .

Note that go vet pick the correct (and complete) file on disk and go build doesn't fail. So the file is supposively complete. Any idea or need more debug info? Thanks!

[nsf]

All I can say is that I don't use autobuild feature and honestly not sure how it works. And while it's not nice for me to not know how part of my software works, that's how it is. If it's indeed fails to rebuild out-dated libraries for some reason, I don't know how to fix that. My view is that gocode will eventually parse source files instead of relying on compiled binaries. But it may be a very distant "eventually". All I can suggest is to look into gocode's code, around the place where it builds stuff (autobuild function in declcache.go). Maybe insert a bunch of printfs there, see what's going on, etc. Maybe it's not even gocode who builds binaries for you, gocode's autobuild feature is disabled by default.

[Iancurtis]

Hi, i got the same problem today . thanks for nfs's opinion. Maybe this will help you . #399

[didrocks]

Thanks lancurtis!

Indeed, lib-path was set matching my go.gopath option from VSC. I don't know how, because looking at https://github.com/Microsoft/vscode-go, there is no clear option set from it. I can only say that shutting down gocode, unset go.gopath from VSC and starting completion again with autobuild gets the static libraries file not stalled anymore and regenerated, even if already present. (and so, completion works)

[nsf]

And I will repeat here what I said in the pull request. If lib-path is set, autobuild shouldn't work, because lib-path is a hack, that says - ignore all Go package lookup rules or whatever other package lookup rules are there and use custom ones with a custom path. Initially lib-path was added to handle very specific Go usage cases, like using Go with google's appengine. Normally text editors shouldn't use lib-path and users shouldn't too.