-
Notifications
You must be signed in to change notification settings - Fork 89
Conversation
thanks! Just ping when CI is happy and you want a review. |
|
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 |
@keegancsmith I updated travis to drop 1.8, now tests are passing. There is CI problem with AppVeyor, I'm getting error:
I never worked with AppVeyor, but I see that it uses global go version. I checked previous successful PR and it was using I checked more go projects which uses appveyor, they are also failing (https://ci.appveyor.com/project/mholt/caddy) |
Finally took a look at the PR. You are removing functionality that was added in that is relied on, like 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 |
langserver/completion.go
Outdated
Data: contents, | ||
Cursor: offset, | ||
Source: !h.config.UseBinaryPkgCache, | ||
Context: gbimporter.PackContext(h.BuildContext(ctx)), |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
If you could update the commented out tests that would be great, then I'll merge in. |
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? |
Another PR works for me. |
Filename: filename, | ||
Data: contents, | ||
Cursor: offset, | ||
Builtin: true, |
There was a problem hiding this comment.
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.
@keegancsmith Can you have a look now, I added Builtin: true flag and updated some tests which was not working before. |
langserver/langserver_test.go
Outdated
|
||
h.config.UseBinaryPkgCache = false | ||
|
||
// TODO(anjmao): autocomplete tests fails if binary cache is used |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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:
go-langserver/langserver/langserver_test.go
Lines 1401 to 1409 in 68907e0
// 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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
@lloiser @keegancsmith I finally found why completion tests was not working with BinaryCache.
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. |
👍 I see only appveyor is failing, but its failing due to unrelated issues. |
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.