Skip to content
This repository has been archived by the owner on Oct 12, 2022. It is now read-only.

Update gocode #305

Merged
merged 12 commits into from
Sep 17, 2018
Merged

Update gocode #305

merged 12 commits into from
Sep 17, 2018

Conversation

anjmao
Copy link
Contributor

@anjmao anjmao commented Aug 11, 2018

This PR removes old gocode from nsf and adds gocode from mdempsky. Any cache is not added yet, there are failing unit tests which I'm working on.

@keegancsmith
Copy link
Member

thanks! Just ping when CI is happy and you want a review.

@anjmao
Copy link
Contributor Author

anjmao commented Sep 2, 2018

@keegancsmith

  • I fixed tests and added some todos for feature work since gocode doesn't support some of them like imports autocomplete, builtin global functions autocomplete...
  • Some autocomplete tests are failing for go 1.8 since gocode dropped support for go 1.8 mdempsky/gocode@4389b7c Should we consider dropping go 1.8 support in langserver (make sense to me)?

@anjmao anjmao changed the title wip: update gocode Update gocode Sep 2, 2018
@keegancsmith
Copy link
Member

Yup dropping support of go1.8 sounds good to me. If I am not mistaken most tooling aims to support the last 2 minor releases. Do you mind changing the travis config to be "1.10.x" and "1.11.x" in this PR?

@anjmao
Copy link
Contributor Author

anjmao commented Sep 3, 2018

@keegancsmith I updated travis to drop 1.8, now tests are passing. There is CI problem with AppVeyor, I'm getting error:

exec: "gcc": executable file not found in %PATH%

I never worked with AppVeyor, but I see that it uses global go version. I checked previous successful PR and it was using go version go1.9.2 windows/amd64, now it uses newer go go version go1.11 windows/amd64

I checked more go projects which uses appveyor, they are also failing (https://ci.appveyor.com/project/mholt/caddy)

@keegancsmith
Copy link
Member

Finally took a look at the PR. You are removing functionality that was added in that is relied on, like SetBuildContext and InitDaemon. You should just be able to keep export.go, I believe that was added to export the functionality we hook into.

I also see there are lots of tests you have now commented out. Anyidea why they are breaking? Could it be due to the change in SetBuildContext, or is it just due to how much this fork of gocode has diverged from upstream?

Data: contents,
Cursor: offset,
Source: !h.config.UseBinaryPkgCache,
Context: gbimporter.PackContext(h.BuildContext(ctx)),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@keegancsmith Thanks for review.

As I'm not using gocode daemon (not starting any net listener) I'm setting build context here. In current master https://github.com/sourcegraph/go-langserver/blob/master/langserver/internal/gocode/export.go#L17 is used only in unit tests.
There are failing integration tests since this gocode fork returns different suggestions for some cases.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to update those tests instead of just commenting them out?

Ok great about setting the buildcontext where you set it, that actually makes a lot of sense.

@keegancsmith
Copy link
Member

keegancsmith commented Sep 6, 2018

If you could update the commented out tests that would be great, then I'll merge in.

@anjmao
Copy link
Contributor Author

anjmao commented Sep 7, 2018

Sure I will look at these failing tests, but some tests are failing since gocode doesn't support imports autocomplete, I thought it is better if I add this feature on separate PR or do you want me to add it in this PR?

@keegancsmith
Copy link
Member

Another PR works for me.

Filename: filename,
Data: contents,
Cursor: offset,
Builtin: true,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@keegancsmith I was missing this flag, after adding Builtin: true I was able to fix failing tests except whos with package autocomplete. There is one bug in gocode , if I place dot inside package path I get all builtins. In real world this is not a big deal and this can also be fixed with package autocomplete.

image

@anjmao
Copy link
Contributor Author

anjmao commented Sep 12, 2018

@keegancsmith Can you have a look now, I added Builtin: true flag and updated some tests which was not working before.


h.config.UseBinaryPkgCache = false

// TODO(anjmao): autocomplete tests fails if binary cache is used
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This settings is by default activated and therefore used by editors.
Do you know why this is happening? Is it because gocode has some problems or is it a problem in the go-langserver?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As gocode is using binary cache for completion if I set this to UseBinaryPkgCache = true a lot of completion tests are failing since autocomplete returns empty result because test case binary is not built yet at that moment. Is there any way I can pre build each test case code during mountFS?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests already install the packages:

// Install all Go packages in the $GOPATH.
oldGOPATH := os.Getenv("GOPATH")
os.Setenv("GOPATH", tmpDir)
out, err := exec.Command("go", "install", "-v", "all").CombinedOutput()
os.Setenv("GOPATH", oldGOPATH)
t.Logf("$ GOPATH='%s' go install -v all\n%s", tmpDir, out)
if err != nil {
t.Fatal(err)
}

Maybe there is another problem that I cannot see at the moment...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, this is only failing because $GOPATH/pkg would be used when UseBinaryPkgCache = true, and in the case of the tests here we are not actually building the code with go install because the code is not on disk. i.e. this wouldn't actually fail in practice / in real use when UseBinaryPkgCache = true, yeah?

If so, I think it is fine to not address this for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I am wrong here (I submitted my reply before I saw @lloiser's reply). We are copying the test sources into a temporary GOPATH and go install'ing them, so it should be working

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lloiser Thanks, yes it's actually building code and pkg binary cache files are created during tests, but for some reasons imported packages scope is empty.

In gocode package imports prints empty scope if binary cache is used, but it works perfectly fine in vscode when using binary cache.

pkg.Imports()[0].Scope()

I'm currently investigating go/importer used in gocode.

.travis.yml Show resolved Hide resolved
@anjmao
Copy link
Contributor Author

anjmao commented Sep 16, 2018

@lloiser @keegancsmith I finally found why completion tests was not working with BinaryCache.

  1. Since I'm on macOS my GOOS is darwin, tests was using hardcoded linux. I changed tests to use runtime.GOOS instead.
  2. Gocode has support for gb pased projects and there was a bug with importPaths, which I fixed in separate commit.

I never used https://getgb.io/, but I'm not sure if we should support that. I would rather drop gb support since custom GOPATH is a easy solution to someone who want to have project based workflow.

@keegancsmith
Copy link
Member

drop gb support

👍

I see only appveyor is failing, but its failing due to unrelated issues.

@keegancsmith keegancsmith merged commit 28e52ba into sourcegraph:master Sep 17, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants