In VSCode, I am trying to rename a variable using F2. This seems to run the gorename tool, but fails every time without explicit error. It simply displays:
/home/oops/dev/mtg-tracker/mtg-tracker-server/handlers>Finished running tool: /home/oops/dev/go/bin/golint
/home/oops/dev/mtg-tracker/mtg-tracker-server/handlers>Finished running tool: /usr/local/go/bin/go build -i -o /tmp/vscode-goVw9yJs/go-code-check .
/home/oops/dev/mtg-tracker/mtg-tracker-server/handlers>Finished running tool: /usr/local/go/bin/go vet ./...
Rename failed
I've looked into similar issues and it seems to normally come with an error such as an invalid GOROOT or incorrect package naming, but I see no such error here and I haven't been able to find any further info.
I also saw that someone fixed this by updating gorename, which I tried looking into but have not been able to figure out how to do.
Expected result: VSCode actually renames my variable.
Actual result: The rename fails and it stays the same.
Note there is an issue 24661 dedicated to follow the tools and their updates, for command-line or VSCode usage.
That issue just included:
gorename will no longer be supported as gopls already implemented renaming functionality.
See issue 27571, which refers to issue 32875.
In the meantime, pending full support of gorename, I am using saibing/tools which does produced an "extended" version of gopls, with rename support.
And which is working just fine in VSCode.
Update Q4 2019 (Nov.): issue 32875 is now closed, gopls has released a 0.2.0 and those errors should be fixed.
A full rename support is still there: CL 194878
Remains CL 207579: This change adds command line support for prepare_rename.
Update Sept. 2020:
As commented and in CL 255053 (for go bundle), a lot of the tools in this list have been replaced by gopls as well.
Related
I get the below error message when I try to run the command in VSCode.
Command "maven.archetype.generate" fails. Cannot read property 'length' of undefined
As far as I can see, I have all plugins/extensions but cannot work out why it won't work. I found this but still cannot get it to work, however I can run apps for files created before I updated VSCode to version 1.32.1. I just cannot create new ones.
It's look like a bug.
Are you running the commands without any workspace or folder open?
Open a folder first, see if the issue still exists. If it's gone, I
suppose it's because of a potential NPE which is fixed by PR #276 but
not released yet. Please let me know the result.
It worked for me!
See more: https://github.com/Microsoft/vscode-maven/issues/277#issuecomment-473166245
From command line, type in:
mvn --version
to see if Maven is installed properly.
You need maven and jdk installed for maven to work.
Check out the “Before you begin” here:
https://code.visualstudio.com/docs/java/java-tutorial#_create-the-program
What is probably happening is that you do not have Maven or JDK installed, or you have not set the system variables properly. These installations are not the same as the plugins/extensions found in Visual Studio Code. These are in addition to that.
I am using JetBrains GoLand and I am trying to debug my go file and I am getting the following error:
decoding dwarf section info at offset 0x0: too short
I tried to find an answer here at StackOverflow but unfortunately, I didn't get any solution.
GoLand ships with a bundled version of Delve. Update to 2018.2.2 and it should work. If you need to do remote debugging, then you need to update your Delve installation on/for the target machine as well (make sure you compile it with Go 1.11).
Edit:
There are two more possible cases where this issue can appear:
the application was compiled with all the debugging flags turned off and the additional debugging information stripped
the application uses the standard library "plugin" package, which is known to cause an issue in the Go compiler. This will be fixed in Go 1.12.
I would like to share my experience here too as it may be helpful for community, I made it works by doing the following:
Update Goland to 18.3
Also, in case if you have Mac, you should run xcode-select --install
In case if you had delv already installed inside GOPATH/bin, remove it and re-install it again by following instructions here
For my Mac the problem is related to the dlv package as installed by Golang plugin.
Install delv and,
check the path of dlv as executed by IntelliJ (in the console).
Go to this directory
($HOME//Library/Application Support/IntelliJIdea2017.3/intellij-go/lib/dlv/mac)
and rename dlv to any other name. Get the right dlv executable by using
which dlv (/usr/local/Cellar/go/1.11.1/libexec/bin/dlv for my computer)
and add a symbolic link
(ln -s /usr/local/Cellar/go/1.11.1/libexec/bin/dlv dlv).
After hours of effort, I was able to find the issue. It was due to Golang Plugin which is deprecated and was not compatible with IntelliJ IDEA 2018.2.2 (Ultimate Edition).
I uninstalled the plugin and reinstall the IntelliJ.
Hope this also helps to above solutions.
I'm trying to build simple chaincode example in Atom editor on Windows but build fails (I'm using go-plus package) with following error:
fatal error: ltdl.h: No such file or directory #include ltdl.h
I know that using flag: -tags nopkcs11 will solve the problem, but how can i configure go-plus/Atom to use this flag?
I believe there is still an open issue for go-plus to support build tags. I have not used Atom in a while, but the only option I can think of would be to try to use a Makefile (which is not the easiest thing in the world on Windows since most of the built-in Atom commands assume GNU commands being available).
If you are open to moving to something like Visual Studio Code it does support build tags.
Perhaps we should actually reverse the build tag within Fabric and require you to enabled pkcs11 with a tag rather than disable it with a tag. I debated this when first adding the tag. Feel free to open up a JIRA item for this.
Trying
devtools::install_github("Rexamine/stringi")
and getting error:
Could not find build tools necessary to build stringi
I see several people have had this error but the solutions haven't worked for me. I reinstalled xcode because the command line tools seemed to be the problem for other people. Checked the paths for R and RStudio, I can open both fine (from the terminal as well). Don't think this is an Rtools issue but I can't figure out where the problem is. Has anyone had any luck with this particular devtools error?
Running OSX 10.11.6, RStudio Version 0.99.896, R 3.2.1 GUI 1.66 Mavericks build (6956), XCode Version 7.3.1 (7D1014).
You can try running
/usr/bin/clang --version
If command line tools are installed, this should just report the version of clang installed; otherwise, you'll be prompted to install Xcode + Command Line Tools. (This is just a simple way of ensuring command line tools indeed are installed)
If you run
devtools::install_github("Rexamine/stringi")
in a plain R console, outside of RStudio, what do you see? Can you update your post with the errors (if any) printed to the console?
You might also try updating RStudio to the preview release (https://www.rstudio.com/products/rstudio/download/preview/) to see if that helps.
It seems like this is likely a bug in RStudio's build tools detection; you might try explicitly disabling it with:
options(buildtools.check = function(action) TRUE)
This should ensure that devtools doesn't try to call RStudio's build tools detection code and just assume that everything is available.
I made a second development on levigo, when I finished it and try to install it on my system with the following command:
go install github.com/AndreMouche/levigo/
it reports the following error:
# github.com/AndreMouche/levigo
/home/fun/software/go/go/pkg/tool/linux_amd64/6c: unknown flag -FVw
Does anybody know how to fix it?
Your go command probably differs from your go tool chain.
Check if the right version of the go tool is in the PATH of your shell or try reinstalling go.
The go tool calls tools like the compiler (e.g. 6g) and the linker. If the go tool version
does not correspond with the version of these tools, said tools may get called with parameters
they don't yet know or they don't know anymore.
Check the version using these commands:
$ go version
$ go tool 6g -V
They both should report the same version string.
See this and this post for related problems.