-
Notifications
You must be signed in to change notification settings - Fork 646
Test Plan for Sept 2018 (0.6.90) #1939
Comments
✅ Provide auto-completions for symbols from unimported packages even when the package name has multiple matches. and testing other new features and fixes. |
|
Blank identifiers in outline fix looks good |
@shreyu86, @johan-lejdung, @ragurney Thanks for confirming! |
I've been casually using this for two days now. Nothing out of the ordinary has happened. The tempdir stuff seems to be working in that tempdirs do appear with expected contents. vscode-go-debug.txt still goes directly into TEMP with the predictable name, so that fix seems to not have gone in. I noticed the iferr snippet improvement, and that is cool! |
Snippets look good! |
Not in the list but I think setting |
@gertcuykens That can very well be the case. If you find more details, please do log a new issue and we can investigate further. |
Great job on this release so far. I have a huge project using Go Modules, with many local subpackages imported). The latest vsix (beta 6) works way better than the previous versions. It does not seem bogged down on CPU nearly as much. Previously I had like 10-12 go.exe running under VS Code when saving stuff, but this seems to have dissapeared. The version of godef that the plugin installs does not support Go Modules, and that breaks that functionality. There is a fork at https://github.com/ianthehat/godef which works, and you might consider switching to that. When are you enabling languageserver for Windows? :) |
Benchmark file and package works great! |
@lkarlslund better to ask the owner of https://github.com/ianthehat/godef to merge |
The |
To those who use Go modules: The Go tools team have forks of the Please install this beta version, follow through the prompts to install/update the tools and let us know how the @lkarlslund Nice timing :) I wanted to complete the testing of the forks and adding the right prompts in the right places before releasing them in the beta version. So now you have them.
As soon as the upstream item sourcegraph/go-langserver#113 is resolved |
|
I am using Go modules yes. I can see that vscode is starting gocode-gomod. I ran it with
|
Also FYI the reason completion works with normal |
@alecthomas So from what I can understand you are using modules but are also vendoring the dependencies. And it is for such vendored dependencies that you are not getting completions? If so, can you open a new issue with a sample code (preferably a small repo that I can just clone)? |
@ramya-rao-a Just been testing out the beta plugin and as per @alecthomas auto complete doesn't seem to be working for stdlib. I uploaded a repo https://github.com/wolfeidau/test-gocode hope that helps.
|
@wolfeidau I wasn't able to reproduce using your case. The very first completion is a little slow, but after that, the stdlib was completing fine. |
Another data point: |
@alecthomas It is known that If what you said before still holds and you see |
@ramya-rao-a I'm guessing it is environment-specific, as @wolfeidau has produced a test repo that fails for him, but does not for @stamblerre. So I don't think I'd be able to add anything that @wolfeidau 's existing repo doesn't already. |
Same here with me... the autocomplete doesn't works by using @wolfeidau case |
Using your repo and the repro steps in the README of your repo, I do see that there is no completions for the #1944 is tracking the case where auto-completions dont work, unless a package has been imported and used atleast once in the saved version of the file. I believe that is what is happening in this case. Can you try saving the file after any usage of the stdlib and try again? @alecthomas |
@ramya-rao-a I have tried doing as you instructed. Open
I started digging into the fork which @stamblerre is currently maintaining, then quickly got lost in the go tools packages adding printf statements. We really need to know where It would be amazing if there was a bit more tracing in the I have updated the readme in my with my |
@wolfeidau I've logged #1963 to continue the discussion |
Everyone, Thanks a lot for the participation! 0.6.90 version is now released. If you have further feedback, please feel free to open an issue. |
If you got a notification from this issue, then you are part of the next update to the Go extension.
Thanks and Welcome!
Here I will be listing the features and the bug fixes that will go in the next update along with the the folks who logged the bugs/feature requests, those who upvoted it, and those who fixed it by sending PRs.
The idea is to get the folks behind this update to give the update a trial run before I release it.
I always do basic testing before every update. But because I dont work with Go in my day job, I always feel that someone who does Go more than me can help in testing tremendously.
And when I say "test", you can do a minimum pass of just installing the update and then do nothing special other than going about using VS Code like you do everyday. Or you can test the feature you requested/implemented or the bug you logged/fixed. Or you can test all of the below. Every bit helps.
Drop in a comment in this issue after 2 or 3 days of installing the update with your findings.
If you are using Go modules:
go.docsTool
is set togogetdoc
will now work. You will be prompted to updategogetdoc
. @zmb3go.docsTool
setting. You will be prompted to install a fork ofgodef
that we are testing. @stamblerregocode
that we are testing as well as to update thegopkgs
tool. Currently it only works if the package is already imported and used atleast once. @stamblerre, @uudashrGo: Add Import
&Go: Browse Packages
commands that will show the appropriate packages from the current module instead of GOPATH @uudashrFeatures not related to Go modules
@biancarosa, @lkarlslund
Go: Benchmark File
,Go: Benchmark Package
and codelens to run all the benchmarks in current file & package respectively. Feature Request 1522 with PR 1898 & PR 1899@jeffbean
go.generateTestsFlags
to provide flags for thegotests
tool when generating tests using any of theGo: Generate Unit Tests...
commands. PR 1841@johan-lejdung
go.testTags
to be used for running tests. This way, you can use the existinggo.buildTags
for compiling and a different set of tags for running tests. Feature Request 1842 implemented with PR 1877@ragurney, @mgood
Go to symbol in file
command. Bug 1889 fixed with PR 1893@svipben
Analysis Tools Missing
button in the status bar which shows up when you don't have the required Go tools installed. PR 1922@alecthomas
iferr
andforr
i.e "if err ..." the "for range". Feature Request 1920 implemented with PR 1924@Charliekenney23, @antong
@shreyu86
@ramya-rao-a
Go: Test File
command. Bug 1911The text was updated successfully, but these errors were encountered: