Support completions for modules with build constraints

[tweekmonster]

It would be nice to get completions for OS-specific modules instead of getting nothing. I've already accomplished this in: deoplete-plugins/deoplete-go#73, but I agree with @nhooyr that this should be a feature in gocode.

Files such as thing_freebsd.go and thing_windows.go are obvious. Files with // +build constraints are a little more difficult, but I think that if the build constraint is // +build windows freebsd it should be safe enough to go with the first OS within the context of that module.

If you don't have time to look into this, could you point me to the part of the source that would need to be changed for this? I tried looking, but I'm not sure where to start.

[nsf]

IIRC gocode doesn't even look at these build tags, it just loads all source files and tries to populate the same scope with entities from all of the files. So a random one ends up being in the scope.

That's the function which is responsible for loading other package files (aside from currently edited one).
https://github.com/nsf/gocode/blob/master/autocompletecontext.go#L457-L496

Maybe we could do smarter filtering there, at the moment as far as I can see it only tests for package name.

[nsf]

As for deoplete-plugins/deoplete-go#73, there shouldn't be a need to gocode close, gocode passes env vars with every request to the server and it will drop the cache if they don't match. At least this is the intention, bugs are possible.

Changing context based on +build comment or filename of the currently edited file is an interesting idea. I'll think about it.

[tweekmonster]

@nsf Thanks for the info. In regard to gocode close, I was testing by trying to get completions in a file named mount_windows.go and nothing appeared until I tried go close. After that, it just started working.

It was one of those half-hours of bug hunting madness, so it could've been a bug in my script that somehow caused retention in gocode.