Support the new package binary file format (coming in Go 1.7)

[kostya-sh]

Probably nothing to do for this issue until Go 1.6 is out but I thought I would file the issue as a reminder anyway.

A new binary export format is coming with Go 1.6 (disabled by default). See the following commit for more details: golang/go@ae2f54a

As I've been experimenting using Go built from tip I've noticed that gocode panics when the new export format is used.

[nsf]

Thanks for letting me know. In my opinion they should just gzip the old format, gives similar ratios.

[kostya-sh]

FYI, golang/go@7538b1d has landed.

gocode no longer works with go tip unless GO_GCFLAGS="-newexport=0" is set.

[nsf]

Will take a look at it this weekend.

[OneOfOne]

A workaround for editors that uses autobuild (vscode in my case):

1. make sure the editor passes -gcflags=-newexport=0 to go install.
2. apply the following patch to gocode and run go install github.com/nsf/gocode

diff --git a/declcache.go b/declcache.go
index 6040d24..d040958 100644
--- a/declcache.go
+++ b/declcache.go
@@ -237,7 +237,7 @@ func build_package(p *build.Package) error {
        }
    }

-   cmd := exec.Command("go", "install", p.ImportPath)
+   cmd := exec.Command("go", "install", "-gcflags=-newexport=0", p.ImportPath)
    cmd.Env = env

    // TODO: Should read STDERR rather than STDOUT.

[nsf]

Or don't use Go master version? What's the rush? Use Go 1.6.

P.S. Already working on binary format parser.

[OneOfOne]

Working on a CL for go1.7, so... but that's great to hear.

[pierrre]

Thank you!

[danp]

With go tip and gocode including de6353c should I still be seeing a panic?

panic: unexpected object tag 58
1(runtime.call32): /Users/dan.peterson/Projects/go/project/go/src/runtime/asm_amd64.s:479
2(runtime.gopanic): /Users/dan.peterson/Projects/go/project/go/src/runtime/panic.go:458
3(main.(*gc_bin_parser).obj): /Users/dan.peterson/Projects/go/src/github.com/nsf/gocode/package_bin.go:204
4(main.(*gc_bin_parser).parse_export): /Users/dan.peterson/Projects/go/src/github.com/nsf/gocode/package_bin.go:114
5(main.(*package_file_cache).process_package_data): /Users/dan.peterson/Projects/go/src/github.com/nsf/gocode/package.go:140
6(main.(*package_file_cache).update_cache): /Users/dan.peterson/Projects/go/src/github.com/nsf/gocode/package.go:89
7(main.update_packages.func1): /Users/dan.peterson/Projects/go/src/github.com/nsf/gocode/autocompletecontext.go:374
8(runtime.goexit): /Users/dan.peterson/Projects/go/project/go/src/runtime/asm_amd64.s:2058

panic: One of the package cache updaters panicked
1(runtime.call32): /Users/dan.peterson/Projects/go/project/go/src/runtime/asm_amd64.s:479
2(runtime.gopanic): /Users/dan.peterson/Projects/go/project/go/src/runtime/panic.go:458
3(main.update_packages): /Users/dan.peterson/Projects/go/src/github.com/nsf/gocode/autocompletecontext.go:382
4(main.(*auto_complete_context).update_caches): /Users/dan.peterson/Projects/go/src/github.com/nsf/gocode/autocompletecontext.go:166
5(main.(*auto_complete_context).apropos): /Users/dan.peterson/Projects/go/src/github.com/nsf/gocode/autocompletecontext.go:303
6(main.server_auto_complete): /Users/dan.peterson/Projects/go/src/github.com/nsf/gocode/server.go:179
7(main.(*RPC).RPC_auto_complete): /Users/dan.peterson/Projects/go/src/github.com/nsf/gocode/rpc.go:26
8(runtime.call64): /Users/dan.peterson/Projects/go/project/go/src/runtime/asm_amd64.s:480
9(reflect.Value.call): /Users/dan.peterson/Projects/go/project/go/src/reflect/value.go:434
10(reflect.Value.Call): /Users/dan.peterson/Projects/go/project/go/src/reflect/value.go:302
11(net/rpc.(*service).call): /Users/dan.peterson/Projects/go/project/go/src/net/rpc/server.go:383
12(runtime.goexit): /Users/dan.peterson/Projects/go/project/go/src/runtime/asm_amd64.s:2058

[danp]

Tried nuking $GOPATH/pkg as well, didn't help.

[nsf]

No, it's a bug. Is it happens on Go tip if you run gocode's _testing/all.bash or with some particular lib? Go authors may change package format before release 1.7. I'm interested in reproducable test cases. I will take a look at them at the weekend.

[danp]

I get a failure from test.0032 and when trying to use gocode in my editor.

[nsf]

Ok, I'll take a look at latest Go master. Maybe they've changed something.

[nsf]

This failure is probably also relevant: #350.

But sorry guys, super busy this weekend. In general I will make sure it works when 1.7 is closer. Maybe when they start marking release candidates.

[mattn]

It seems that gocode is better to use codes from cmd/compile/internal/gc/bimport.go . maybe keeping compatibility for older version seems to be too difficult for me.

[mdempsky]

Why does gocode need to parse export data itself? Is there functionality missing from go/importer?

[nsf]

Well, first of all I can parse it directly to the format I use, which is historically a "go/ast" based format (in the early days it was possible to parse .a file by actual Go parser with some preprocessing hacks).

Secondly "go/importer" has some weird logic when it comes to getting the package files. It asks you to pass in the package path as seen by a Go source file and in theory it should allow customization of a lookup function. But in practice it doesn't support non-default lookup functions: https://golang.org/src/go/importer/importer.go?s=807:862#L14

So I simply can't use it for gocode, because gocode has gb package lookup mode amongst other things and I actively use it.

[mdempsky]

Sorry, I don't use gb so I don't understand the problem. gb still uses .a files like normal cmd/go builds, right? You can use importer.Default().Import("/path/to/goroot/pkg/linux_amd64/fmt") for example to load /path/to/goroot/pkg/linux_amd64/fmt.a.

[mdempsky]

BTW, I have a mostly working prototype that uses go/importer to directly create decls for imported objects, bypassing creating the go/ast intermediate form. I just need to fix two last test failures.

[nsf]

Well, hm, maybe. But I just like to do things my own way. Although, if you can make it work I'll take a look.

[OneOfOne]

A temporary workaround until gocode supports the new export format is compiling go with this patch:

diff --git a/src/cmd/compile/internal/gc/export.go b/src/cmd/compile/internal/gc/export.go
index 2dd137e..7b4028c 100644
--- a/src/cmd/compile/internal/gc/export.go
+++ b/src/cmd/compile/internal/gc/export.go
@@ -377,7 +377,7 @@ func dumpexport() {
    }

    size := 0 // size of export section without enclosing markers
-   if newexport {
+   if false && newexport {
        // binary export
        // The linker also looks for the $$ marker - use char after $$ to distinguish format.
        exportf("\n$$B\n") // indicate binary format

https://gist.github.com/OneOfOne/c4bc9eb3206e41ab133ae1d3e70194b0

[nsf]

I've ported all importer changes from Go's master to gocode. All gocode's tests pass, but if you have any issues with new binary format and gocode, please report them here.

A friendly reminder: make sure before or after updating gocode with go get -u github.com/nsf/gocode, you close the previous instance with gocode close.

[OneOfOne]

@nsf I can confirm it's working.

[mdempsky]

FWIW, I uploaded my modified version of gocode as github.com/mdempsky/gocode. It's dramatically smaller (~1600, down from ~6500) mostly due to using go/types and go/importer. It also doesn't attempt any caching, but still seems fast enough for interactive use. It currently only supports cmd/go builds, because I haven't yet grok'd how gb works.

[nsf]

@mdempsky it looks interesting, but I can't really test it out in "production", because we use gb. And as a result, I can't compare it to current gocode version. Test coverage in gocode is pretty bad and you can't rely on it, the only way to find out is to try using it. Hence, I can't just take your patch and apply it. But I will definitely give it a try if you implement gb support.

And if you eventually want to step over and maintain gocode for the rest of your life, I totally don't mind. I don't have time for it anymore.

In case if someone is worried - don't. I will keep maintaining gocode for the whole Go 1 lifecycle, because it does a pretty good job at what it was made for, at least for me anyways. If there is a better alternative - great, less code for me to maintain.

[mattetti]

Confirmed to work against master. While I'm a happy user of the current version, @mdempsky if you're planning on maintaining your branch and need help testing it, I rely on gocode quite heavily and would be glad to help test.

[zchee]

@nsf Thanks for great works! master branch almost working.
also, I have a project that uses a gocode. It's gocode for Neovim using deoplete.nvim word completion framework.
Thanks again.
https://github.com/zchee/deoplete-go
https://github.com/Shougo/deoplete.nvim

BTW, I found two bugs. Maybe it's related new binary format.
I've prepared a reproducible sample .go file.
Should I create a new issue thread? or post to this thread?

[nsf]

@zchee a new issue would be nice

[zchee]

@nsf Thanks, I'll create a new issue later.

[nsf]

@zchee I also probably won't take a look at it until the weekend. Well, depends on complexity.

[mdempsky]

@mattetti I do plan on maintaining my version. If you find any issues, feel free to report them under mdempsky/gocode (so we don't spam @nsf :)), and I'll take a look. I'm keeping the interface backwards compatible so it should be easy to switch back and forth between versions of gocode if there are problems (just reinstall and restart).

[mdempsky]

Update: I've added gb support to mdempsky/gocode.

It hopefully works automatically and without any configuration: if gocode notices that you're editing a file within DIR/src or DIR/vendor/src and DIR is not a member of GOPATH, then it will also check DIR/pkg for .a packages compiled by gb. Note: this is in addition to and after normal GOPATH .a package searching, if any. Experimentally seems to work with gb's example-gsftp sample project.

[srounce]

A friendly reminder: make sure before or after updating gocode with go get -u github.com/nsf/gocode, you close the previous instance with gocode close.

A note to others, in addition to the above I also had to run
gocode drop-cache

[nsf]

gocode drop-cache won't do anything, it doesn't restart the server, it just drops in-memory gocode cache. After building new gocode version you need to restart the server, that's the important part.

[srounce]

Well actually, after running gocode close I still encountered a panic. gocode status showed cache to be empty but panic still happened. After a hit-and-hope run of gocode drop-cache it started working immediately afterwards.
Quite probably a coincidence, whatever.

[nsf]

I have no explanation for that scenario.

[dmitshur]

Hi. I'd like to chime in here and offer some observations and point out an opportunity.

First, huge, huge thanks to @nsf (and contributors to gocode) for creating gocode and maintaining it all this time. I've been following its development since 2012, using it in my projects, and using it for all my Go writing autocomplete needs as part of GoSublime. Basically every day, thousands of times. So thank you.

I use Go and care about it a lot, so I want the best future for gocode. I really hope the rest of my comment is constructive and helpful – at least that's my intention. Please consider the following observations, and feel free to correct me if I get some details wrong.

I know that @nsf has said in the past that gocode could really use a rewrite, at least in theory.

That's just a fact. Given circumstances (Go 1.6 gets new binary format for packages), maybe it's a good time to start it now.

Source: #307

As he pointed out, starting with Go 1.6, and continuing with 1.7 and 1.8, there are multiple internal changes done and planned to the binary format for packages.

The Go compiler team wants to improve things in that area. In order to be able to do that without breaking Go tooling, they've provided packages such as go/types, go/importer, etc., with stable APIs that enable access to the underlying data. This allows them to break internal format details, updating those packages appropriately to keep them functioning as before, and iterate forward.

The current gocode, primarily for historical reasons (source), still tries to parses the binary format itself without going through the stable APIs, and that's what's causing many tip-related breakages.

As I understand, @mdempsky was motivated to try to fix gocode for tip since many people (including the Go team, who often use tip) depend on it, and he didn't want it to break as him and his team were introducing internal breaking changes to the binary format (but the stable APIs continue to work).

BTW, I have a mostly working prototype that uses go/importer to directly create decls for imported objects, bypassing creating the go/ast intermediate form.

FWIW, I uploaded my modified version of gocode as github.com/mdempsky/gocode. It's dramatically smaller (~1600, down from ~6500) mostly due to using go/types and go/importer. It also doesn't attempt any caching, but still seems fast enough for interactive use. It currently only supports cmd/go builds, because I haven't yet grok'd how gb works.

Source: #305 (comment)

I know that @nsf has started the project long ago and used C-style snake case for variable names, etc. It's completely valid to do that since it's his project and it's not a part of a public API. However, given that this project provides value to so many people, who may want to contribute, following the Go idiomatic style would make it easier for other people to do that.

I see that @mdempsky has already done the work to change the internal code style to be more idiomatic, see mdempsky@e117c26.

@nsf made a good point that:

@mdempsky it looks interesting, but I can't really test it out in "production", because we use gb. And as a result, I can't compare it to current gocode version. Test coverage in gocode is pretty bad and you can't rely on it, the only way to find out is to try using it. Hence, I can't just take your patch and apply it. But I will definitely give it a try if you implement gb support.

But I see that @mdempsky has completed gb support as of May 18:

Update: I've added gb support to mdempsky/gocode.

Source: #305 (comment)

And I know @nsf has said in the past he wouldn't mind if others helped out with maintaining this project.

@mdempsky has also said he plans to maintain his current version:

@mattetti I do plan on maintaining my version. If you find any issues, feel free to report them under mdempsky/gocode (so we don't spam @nsf :)), and I'll take a look. I'm keeping the interface backwards compatible so it should be easy to switch back and forth between versions of gocode if there are problems (just reinstall and restart).

Source: #305 (comment)

So this looks like a great opportunity to me! Since mdempsky/gocode version has gb support now, @nsf should be able to give it a try in production and see if that version works without issues (or report any).

If that goes well, perhaps all the improvements from mdempsky/gocode version can be merged into nsf/gocode, so we have the best of all worlds in one. It really looks like it could be win-win for everyone. At least from what I can tell, but of course it's possible I'm overlooking some details or I'm wrong. Please let me know if so.

I hope this comment doesn't come out rude; I really just want to point out what looks (from my perspective) like a very positive opportunity to help make this project better in the long run. Thanks everyone!

[nsf]

The reason why I don't like relying on provided semantic analysis libraries is because gocode works with invalid go code. And what happens if these libs fail to handle some case which is 100% invalid from their point of view, but for gocode it would be nice to handle it. Do I fork the libs?

As for me testing the alternative gocode, sure I can do that, but it's unlikely that I'm merging it anyway.

I can also put a message on README.md so that users try that other version of gocode, but the problem is - I don't think that many users actually read README.md. You see gocode is not an end user product, there is a ton of editors that rely on gocode being as it is and it puts a lot of pressure on me when it comes to global changes like that. I can't just throw in a new version of gocode silently. Then if it fails what do I do? Revert everything back? I would rather maintain it as it is.

But ok, I'm gonna try this new version of gocode when I'll be working on gocode this weekend (I need to rewrite the way package resolving are done due to the bug). And see if it performs well. Will also try some artificial but realistic cases I have in mind.

[sethgrid]

[UPDATE] FIX:go get -u github.com/nsf/gocode - leaving this here incase google brings someone back. Moderator, feel free to delete if you feel that is better.

gocode is panicing for me: panic: unknown export data version: v1; not sure if this is the right thread for it. When I begin to type "http.", I get one suggestion: "PANIC". I am on Mac El Cap running go 1.7.1. I did not realize how much I depend on gocode until it stopped working. Here is gocode's output
[EDIT: removed duplicate output]

$ gocode close
$ gocode -debug -s

2016/09/17 07:31:52 Go project path: github.com/sethgrid/cloudlock
2016/09/17 07:31:52 Got autocompletion request for '/Users/sethammons/workspace/go/src/github.com/sethgrid/cloudlock/main.go'
2016/09/17 07:31:52 Cursor at: 1383
2016/09/17 07:31:52 -------------------------------------------------------
package main

import (
    "bufio"
    "flag"
    "fmt"
    "log"
    "net"
    "net/http"
    "sync"
    "time"

    "github.com/facebookgo/flagenv"
    "github.com/gorilla/mux"
)

func main() {
    var port int
    flag.IntVar(&port, "port", 9126, "port to run site")
    flagenv.Parse()
    flag.Parse()

    r := mux.NewRouter()
    r.HandleFunc("/", indexHandler)
    r.HandleFunc("/login", loginHandler)
    r.HandleFunc("/logout", logoutHandler)
    r.Handle("/dash", mwAuth(http.HandlerFunc(dashHandler)))

    http.Handle("/", mwLog(r)) // wrap with logging mw

    log.Printf("starting on :%d", port)

    if err := http.ListenAndServe(fmt.Sprintf(":%d", port), nil); err != nil {
        log.Println("Unexpected error serving: ", err.Error())
    }
}

func indexHandler(w http.ResponseWriter, r *http.Request) {
    log.Println("index handler")
}

func loginHandler(w http.ResponseWriter, r *http.Request) {
    log.Println("login handler")
}

func logoutHandler(w http.ResponseWriter, r *http.Request) {
    log.Println("logout handler")
}

func dashHandler(w http.ResponseWriter, r *http.Request) {
    log.Println("dash handler")
}

func mwAuth(h http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        log.Println("requires auth", r.URL)
        h.ServeHTTP(w, r)
    })
}

func mwLog(h http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        http.#
        h.ServeHTTP(w, r)
        log.Printf("%v", start)
        // *** several lines removed that were commented out anyway *** //

    })
}

// everything below is for the logger mw (from noodle)

// logWriter mimics http.ResponseWriter functionality while storing
// HTTP status code for later logging
type logWriter struct {
    code          int
    headerWritten bool
    http.ResponseWriter
}

func (l *logWriter) WriteHeader(code int) {
    l.headerWritten = false
    if !l.headerWritten {
        l.ResponseWriter.WriteHeader(code)
        l.code = code
        l.headerWritten = true
    }
}

func (l *logWriter) Write(buf []byte) (int, error) {
    l.headerWritten = true
    return l.ResponseWriter.Write(buf)
}

func (l *logWriter) Code() int {
    return l.code
}

// provide other typical ResponseWriter methods
func (l *logWriter) Hijack() (net.Conn, *bufio.ReadWriter, error) {
    return l.ResponseWriter.(http.Hijacker).Hijack()
}

func (l *logWriter) CloseNotify() <-chan bool {
    return l.ResponseWriter.(http.CloseNotifier).CloseNotify()
}

func (l *logWriter) Flush() {
    l.ResponseWriter.(http.Flusher).Flush()
}

var writers sync.Pool
2016/09/17 07:31:52 -------------------------------------------------------
2016/09/17 07:31:52 Found "bufio" at "/usr/local/go/pkg/darwin_amd64/bufio.a"
2016/09/17 07:31:52 Found "flag" at "/usr/local/go/pkg/darwin_amd64/flag.a"
2016/09/17 07:31:52 Found "fmt" at "/usr/local/go/pkg/darwin_amd64/fmt.a"
2016/09/17 07:31:52 Found "log" at "/usr/local/go/pkg/darwin_amd64/log.a"
2016/09/17 07:31:52 Found "net" at "/usr/local/go/pkg/darwin_amd64/net.a"
2016/09/17 07:31:52 Found "net/http" at "/usr/local/go/pkg/darwin_amd64/net/http.a"
2016/09/17 07:31:52 Found "sync" at "/usr/local/go/pkg/darwin_amd64/sync.a"
2016/09/17 07:31:52 Found "time" at "/usr/local/go/pkg/darwin_amd64/time.a"
2016/09/17 07:31:52 Found "github.com/facebookgo/flagenv" at "/Users/sethammons/workspace/go/pkg/darwin_amd64/github.com/facebookgo/flagenv.a"
2016/09/17 07:31:52 Found "github.com/gorilla/mux" at "/Users/sethammons/workspace/go/pkg/darwin_amd64/github.com/gorilla/mux.a"
2016/09/17 07:31:52 Error parsing input file (inner block):
2016/09/17 07:31:52  6:8: expected selector or type assertion, found ';'
2016/09/17 07:31:52  7:3: expected ';', found 'IDENT' h
2016/09/17 07:31:52  49:2: expected ')', found 'EOF'
2016/09/17 07:31:52  49:2: expected ';', found 'EOF'
2016/09/17 07:31:52  49:2: expected ';', found 'EOF'
2016/09/17 07:31:52  49:2: expected '}', found 'EOF'
2016/09/17 07:31:52  49:2: expected '}', found 'EOF'
2016/09/17 07:31:52  49:2: missing ',' in argument list
panic: unknown export data version: v1
1(runtime.call32): /usr/local/go/src/runtime/asm_amd64.s:472
2(runtime.gopanic): /usr/local/go/src/runtime/panic.go:443
3(main.(*gc_bin_parser).parse_export): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package_bin.go:101
4(main.(*package_file_cache).process_package_data): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:141
5(main.(*package_file_cache).update_cache): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:90
6(main.update_packages.func1): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/autocompletecontext.go:374
7(runtime.goexit): /usr/local/go/src/runtime/asm_amd64.s:1998

panic: One of the package cache updaters panicked
1(runtime.call32): /usr/local/go/src/runtime/asm_amd64.s:472
2(runtime.gopanic): /usr/local/go/src/runtime/panic.go:443
3(main.update_packages): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/autocompletecontext.go:382
4(main.(*auto_complete_context).update_caches): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/autocompletecontext.go:166
5(main.(*auto_complete_context).apropos): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/autocompletecontext.go:303
6(main.server_auto_complete): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/server.go:187
7(main.(*RPC).RPC_auto_complete): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/rpc.go:26
8(runtime.call64): /usr/local/go/src/runtime/asm_amd64.s:473
9(reflect.Value.call): /usr/local/go/src/reflect/value.go:435
10(reflect.Value.Call): /usr/local/go/src/reflect/value.go:303
11(net/rpc.(*service).call): /usr/local/go/src/net/rpc/server.go:383
12(runtime.goexit): /usr/local/go/src/runtime/asm_amd64.s:1998

panic: unknown export data version: v1
1(runtime.call32): /usr/local/go/src/runtime/asm_amd64.s:472
2(runtime.gopanic): /usr/local/go/src/runtime/panic.go:443
3(main.(*gc_bin_parser).parse_export): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package_bin.go:101
4(main.(*package_file_cache).process_package_data): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:141
5(main.(*package_file_cache).update_cache): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:90
6(main.update_packages.func1): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/autocompletecontext.go:374
7(runtime.goexit): /usr/local/go/src/runtime/asm_amd64.s:1998

panic: unknown export data version: v1
1(runtime.call32): /usr/local/go/src/runtime/asm_amd64.s:472
2(runtime.gopanic): /usr/local/go/src/runtime/panic.go:443
3(main.(*gc_bin_parser).parse_export): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package_bin.go:101
4(main.(*package_file_cache).process_package_data): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:141
5(main.(*package_file_cache).update_cache): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:90
6(main.update_packages.func1): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/autocompletecontext.go:374
7(runtime.goexit): /usr/local/go/src/runtime/asm_amd64.s:1998

panic: unknown export data version: v1
1(runtime.call32): /usr/local/go/src/runtime/asm_amd64.s:472
2(runtime.gopanic): /usr/local/go/src/runtime/panic.go:443
3(main.(*gc_bin_parser).parse_export): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package_bin.go:101
4(main.(*package_file_cache).process_package_data): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:141
5(main.(*package_file_cache).update_cache): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:90
6(main.update_packages.func1): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/autocompletecontext.go:374
7(runtime.goexit): /usr/local/go/src/runtime/asm_amd64.s:1998

panic: unknown export data version: v1
1(runtime.call32): /usr/local/go/src/runtime/asm_amd64.s:472
2(runtime.gopanic): /usr/local/go/src/runtime/panic.go:443
3(main.(*gc_bin_parser).parse_export): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package_bin.go:101
4(main.(*package_file_cache).process_package_data): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:141
5(main.(*package_file_cache).update_cache): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:90
6(main.update_packages.func1): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/autocompletecontext.go:374
7(runtime.goexit): /usr/local/go/src/runtime/asm_amd64.s:1998

panic: unknown export data version: v1
1(runtime.call32): /usr/local/go/src/runtime/asm_amd64.s:472
2(runtime.gopanic): /usr/local/go/src/runtime/panic.go:443
3(main.(*gc_bin_parser).parse_export): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package_bin.go:101
4(main.(*package_file_cache).process_package_data): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:141
5(main.(*package_file_cache).update_cache): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:90
6(main.update_packages.func1): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/autocompletecontext.go:374
7(runtime.goexit): /usr/local/go/src/runtime/asm_amd64.s:1998

panic: unknown export data version: v1
1(runtime.call32): /usr/local/go/src/runtime/asm_amd64.s:472
2(runtime.gopanic): /usr/local/go/src/runtime/panic.go:443
3(main.(*gc_bin_parser).parse_export): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package_bin.go:101
4(main.(*package_file_cache).process_package_data): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:141
5(main.(*package_file_cache).update_cache): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:90
6(main.update_packages.func1): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/autocompletecontext.go:374
7(runtime.goexit): /usr/local/go/src/runtime/asm_amd64.s:1998

panic: unknown export data version: v1
1(runtime.call32): /usr/local/go/src/runtime/asm_amd64.s:472
2(runtime.gopanic): /usr/local/go/src/runtime/panic.go:443
3(main.(*gc_bin_parser).parse_export): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package_bin.go:101
4(main.(*package_file_cache).process_package_data): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:141
5(main.(*package_file_cache).update_cache): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/package.go:90
6(main.update_packages.func1): /Users/sethammons/workspace/go/src/github.com/nsf/gocode/autocompletecontext.go:374
7(runtime.goexit): /usr/local/go/src/runtime/asm_amd64.s:1998

[nsf]

@sethgrid That error message of yours was removed in the commit 2735323. Try updating gocode:

gocode close && go get -u github.com/nsf/gocode

Or if your editor ships with its own gocode binary - blame editor plugin authors for not updating it.

[nsf]

@shurcooL

following the Go idiomatic style would make it easier for other people to do that

What exactly in my style prevents users from contributing? They can't read snake casing? I will not turn down code because it uses camel casing or pascal casing or whatever you want to call it. I see no logic in your statement at all.

If I said to somebody that I will not accept your patch because it uses incorrect styling - I'm sorry. But IIRC I never said that to anyone.

including the Go team, who often use tip

Well, they can write the tool for themselves, they are well paid to work on Go. Since 1.0 I always tell gocode users - don't use tip, use a stable Go release version, that's how I maintain gocode. If somebody is willing to submit a patch that backports the features from tip without breaking anything - great (thanks @zchee). But rewriting gocode to achieve what a few dozen people want?

I know that @nsf has said in the past that gocode could really use a rewrite, at least in theory.

In that rewrite post I talked about main pain points of gocode from a user point of view. None of them are solved by a fork. Sure with "go/types" you can import packages with a custom importer, but there is none of that in the fork. Tools like gocode need to parse the source code tree instead of relying on binary compiler-dependent formats. While this path has some challenges, it's the right thing to do in the long term. We need not only always relevant autocompletion results (possibly before compilation is performed), but also additional info that is available only in the source code - the documentation. Can "go/types" preserve documentation together with semantic info? I don't know, maybe. But I would rather keep doing things my own way. Autocompletion doesn't require that much of a semantic analysis.

So, what even to discuss here?

[dmitshur]

following the Go idiomatic style would make it easier for other people to do that

What exactly in my style prevents users from contributing?

I didn't mean it prevents people from contributing, I said that it's easier to contribute to a project that follows idiomatic Go style because it's easier to read/understand the code, and to make changes to it without being distracted by extraneous style concerns. My point is, given two equivalent code bases:

• one that follows idiomatic Go style
• one that does not follow idiomatic Go style

IMO the former is easier to contribute to (to some degree, it may not be a large amount).

Tools like gocode need to parse the source code tree instead of relying on binary compiler-dependent formats. While this path has some challenges, it's the right thing to do in the long term. We need not only always relevant autocompletion results (possibly before compilation is performed), but also additional info that is available only in the source code - the documentation. Can "go/types" preserve documentation together with semantic info? I don't know, maybe.

I am not an expert in this area, but your argument sounds valid to me. @mdempsky, what are your thoughts on that?

[zchee]

@sethgrid Yeah, I also have this issue, so I send 2735323 patch.
Go developers did no backward compatible changes that were only to tip users.
I think you already know; gocode parses binary file directory. We did not have the way to avoid this error.

@shurcooL This comment is not a criticize to you. and I totally understand you said means, why need idiomatic Go style.
This is simply my thought, actually learned a lot of from gocode. Not opposite opinion.

When #352, I found a bug that related new binary format.
@nsf already did fix to support it, but there was a corresponding leakage.
I used the tip for the studying of Go, and gocode had given me a lot of things, So I wanted to contribute.
I did not know anything the "AST" until that time.
So I have read the gocode source of one week night and day because I haven't long experience to the programming, not only Go.

After that, I found causes point. solved the problem #357.
It changed only the 8 words, but I learned a lot of. what is a parser, How gocode and Go works (a little)

If you pointed out the C style naming is not Go style, did it interfere with my understanding? I think no.
And, if you said point only of read/understand the gocode source for the contribute, maybe no problem if he/she have really wanted to contribute, wanted to something return to the gocode.

It might be not Go style, might be easier to read someone.
But an author of gocode, @nsf style. I think we should respect it.
What do you think?

[nsf]

@zchee just to be clear, this is not my style at all, I have no preference at the moment and can happily write javascript with camelCasing. Changing gocode to snake casing was a bad idea, but my point is that it doesn't affect anyhting really and changing it back brings zero benefits.

[zchee]

@nsf Yeah, I know :)

this is not my style at all, ... Changing gocode to snake casing was a bad idea, but my point is that it doesn't affect anyhting really and changing it back brings zero benefits.

Yes, Maybe it's not you style at now, but still you write gocode use snake_case with any reason(in this case, "it doesn't affect anyhting really and changing it back brings zero benefits."), so I think it's nsf's gocode project coding style.

I mean, In C++, Designed by Bjarne Stroustrup. So we should respect his and C++ language rules? yes. but we should respect his coding style? no.
We should respect any C++ projects .clang-format(if have). If clang or gcc can compile.
{} bracket position, space|tab indent...
In Go, can compile even use snake_case, so that is not rules. just project coding style.

Ask "Why you use this style?". ok, maybe project author will answer.
But if discuss project coding style, That discussion will not profit either side.

I want to say If project author has any coding style per project with any reason(or reason that do not want to change style), we should respect it.
If you will write gocode2.0(or termbox-go2.0, whatever) with camelCase, the contributors should be written in accordance with it.