I am using go in vscode. The problem is that it seems to be linting the golang source code and is coming up with warnings. How do I disable the linting of the go source code itself.
Couple of recommendation:
Update everything (VScode, Go, VSCode-Go extension)
Make sure your workspace (or opened folder) is limited to your project sources.
Use golangci-lint as Lit Tool
Activate the "Go: Lint on save" setting, with 'package' as the selected option.
Related
I have LSP and LSP-typescript packages installed.
I also have directory with typescript code snippets (read: gists), which i sometimes open with sublime. When i interact with such a snippet, i usually get some typecript syntax warnings, coming from LSP. Incorrect syntax in this case is OK of course, because snippets are examples with unmet dependencies, missing constants etc...
Is there an option to disable LSP in such directories where I do not want any checks to be performed?
Apparently it is not possible to exclude directories, but you can achieve something similar by creating new project and disabling chosen LSP-clients at project level. It is doable via command palette => LSP: Disable language server in project.
Trying to learn Rust. Recently installed Atom but found no way yet to build and run a Rust target. I could do this in Sublime with RustEnhanced by just pressing Cmd-B. Installed Atom-build and build-cargo, my Rust setup should be fine since it works from Sublime (and command-line), but from Atom I only get "No build configuration exists". I thought just having build-cargo is enough, the Atom-build documentation apparently says that the build provider (build-cargo in this case) takes care of that. What am I missing?
Finally figured out a way to get what I needed. Install packages script and language-rust. Then simply open a file with extension .rs and hit cmd-i; the file will be compiled and will immediately afterward run, with output displayed in the pop-up window in the lower part of the editor.
I am writing a project using the Go language with GoLand IDE by Jetbrains.
While writing the code, GoLand shows me an error message such as "unresolved reference" when the reference do exist and that the program compiles and runs correctly.
Here is a similar (but simpler) example of some code that I have found here on stackoverflow (Go - append to slice in struct) to reproduce this issue.
The same error message appears even though I have implemented the methods just a few lines above.
package main
import (
"fmt"
)
type MyBoxItem struct {
Name string
}
type MyBox struct {
Items []MyBoxItem
}
func (box *MyBox) AddItem(item MyBoxItem) {
box.Items = append(box.Items, item)
}
func main() {
item1 := MyBoxItem{Name: "Test Item 1"}
item2 := MyBoxItem{Name: "Test Item 2"}
box := MyBox{}
box.AddItem(item1)
box.AddItem(item2)
// checking the output
fmt.Println(len(box.Items))
fmt.Println(box.Items)
}
box.AddItem(item1) and box.AddItem(item2) are marked red as an error. If I move my cursor above it, it says unresolved reference "AddItem". Yet the code compiles and runs. And as this was the solution to an other stackoverflow question, I do not think that the code is wrong. Furthermore I cannot find any mistakes in it.
[EDIT: I load the code from a remote server and edit it locally on my private pc. After finishing my changes, I upload it to the remote server (using GoLands tools like "Browse remote host") and build and compile it there. After trying it out locally with the very same code, the error message sometimes is there and sometimes not. I am totally confused]
I experienced a similar issue, but it was a lot more prevalent. Even things like fmt.Printf() were showing as unresolved. Was able to resolve the issue by going to File -> Invalidate Caches / Restart.
I found best way to fix this issue.
close your project and IDE
go to your project directory
remove ./.idea
try to open it again
woops woops, fixed
Edit : better way try to use this one in Goland Menu
file -> repair IDE
it will be refresh index module
Today I faced that problem and I fixed it by enabling go module integration. For that
Settings -> Other Settings -> Go Modules then enable go modules integration.
This will work if you using go modules in your project.
I'm using go module and it's solved by:
Deselect Preferences->Go->GOPATH->Use GOPATH that's defined in system environment
File->Invalidate caches / Restart
I'm a bit late to the answer lol but incase anyone is still running into this, all I did was delete the .idea file and reloaded the project on GoLand (by clicking File -> Open -> file location). Did the trick for me.
I just removed the project from Goland and re-create it from existing files. It was weird but it worked.
I cannot reproduce the issue in GoLand 2020.2. I suggest upgrading to it.
If that doesn't fix the issue then you can take the following steps to investigate the issue:
Is your project using Go modules or the traditional GOPATH?
If it's using GOPATH, have you enabled indexing of GOPATH under Settings/Preferences | Go | GOPATH?
If it's using Go modules, check to see that the support is enabled under Settings/Preferences | Go | Go Modules and then use Alt+Enter | Sync packages of <project>
For me the issue was the version of Golang, I had been using go1.19 which threw unreferenced errors with .Close methods, switching back to an older version go16.15 helped me resolve this issue.
I had a similar issue for gin.WrapH function utils.go. Tried the Override File Type option for utils.go in local module path which changed the file as a Go file but had a little cross sign where a tooltip marked that the file is excluded from compilation. The error Unresolved reference only went away when I selected the file, navigated to File -> File Properties -> Associate with File Type -> Register new file type association, and chose Go files
No option from other comments helped me. I had to switch GO SDK version in Setting -> Go -> GOROOT. Goland automatically downloaded 1.16 beta 1 version and it worked.
In Goland preferences, if you're using the Global GOPATH, check the option "Index entire GOPATH" and hit apply.
I had the same issue, I did try invalidates cache, but that did not work.
But the thing worked is just add a below line in your idea.properties file. And then restart IDE.
# custom GoLand properties (expand/override 'bin/idea.properties')
idea.max.intellisense.filesize=100000
This is because, Goland does not index huge packages. But you can force it to do that.
For Mac users, i solved this by setting Custom Tags to 'unix'.
In Preferences > Go > Build Tags & Vendoring. In the Custom Tags, input unix.
I'm using GoLand 2022.1.2
I had the same problem and it got fix weirdly.So I installed and opened project in vscode in order to continue coding.It started installing a extension called gopls. After installation completed I returned to GoLand to close project, but I waited for indexing to complete.Suddenly references were green !
Goland version 2020.1: I opened a folder with subfolders of golang projects and goland didn't recognize dependencies. I solved this problem setting Project GOPATH
ctrl + alt + s
Go > GOPATH
Click on plus button + In Project GOPATH
Add your golang's project folder, example: ~/projects/my-golang-projects
I faced the same issue when I do bazel run //:gazelle, I fixed this issue by doing bazel sync (Bazel -> Sync -> Sync Project with BUILD Files). But you should have the below settings.
(This fix is for Goland IDE, Mac. Of course we should add GOPATH in .bash_profile or .zshrc)
I had the same issue with aws go sdk, changing the Custom Properties (Help -> Edit Custom Properties) helped me.
here is the reference to the JetBrains thread https://youtrack.jetbrains.com/issue/GO-5029
idea.max.intellisense.filesize=10000
idea.max.content.load.filesize=20000
Restart the IDE to let the changes take effect.
I had been using go1.19 which threw unreferenced errors with .Close methods. I download the GoLand 2022.2.4 package and install, issue has been solved.
In my case, I fixed it by running go mod tidy in the console.
In my case go mod was 1.18 and IDE indexed my project with 1.19.
At Preferences -> GOROOT I selected Go 1.18 and problem solved.
Today face the same problem using GoLand 2021.3 MacOS.
Fixed it with go to File Menu -> Repaire IDE...
Then it will automatic fixing issues
I solved it by reinstall Go to D:\go, then reset Go sdk.
I've just installed JetBrains WebStorm 2016.1.1 Build #WS-145.597 for evaluation on OS X latest.
I want to use TypeScript but there is an immediate problem: I have enabled the TypeScript compiler in settings but in the Typescript Compiler tool window is complaining that it "Cannot start compiler process".
I've noticed that the build date on the WebStorm About box was yesterday (March 30 2016) so this may be a recently introduced issue.
Is anyone else having this problem? Anyone got an idea how to sort it?
Setting the TypeScript compiler alone didn't solve this for IntelliJ IDEA 2016.2.1 on Linux. I had to go back through my older project that didn't have the problem to find the solution.
After setting up your typescript compiler below.
I then had to directly edit this same setting within my project's .idea directory. Within your project structure, navigate to your .idea directory then locate and open file typescript-compiler.xml like below.
Now add the following xml option element after the "useConfig" option element:
<option name="nodeInterpreterTextField" value="$PROJECT_DIR$/../../node/bin/node" />
Be sure to change the directory path to your instance of node.
Sadly, this solution we be overridden every time you edit and save your settings. IDEA will have to fix their bug for a lasting solution.
I think you need to specify a node interpreter in the typescript settings:
I'm trying to debug an executable which has been created with CMake configuration
SET(CMAKE_BUILD_TYPE Debug)
However, CLion does not hit any breakpoints. What could be the problem?
I had the same issue today. I figured out that the configuration for the project was not set to Debug. After setting the configuration to Debug all the breakpoints are hit.
Please ensure that you have following configuration:
Select the MenuItem Run/EditConfigurations
Select the right Target
Select Debug as Configuration
Now the breakpoints should be hit.
In case this helps someone else, it turned out that my (somewhat embarrassing) issue was that I was hitting Run instead of Debug. So in the Run menu don't use the play icon, instead choose the cute bug icon instead. Choosing Run was causing it to automatically build the non-debug build so breakpoints wouldn't work. Once I started choosing the bug icon, the breakpoints worked like a charm.
As it has turned out, the executable was compiled with following CMake options (further down in the script):
SET(CMAKE_C_FLAGS_DEBUG "-D_DEBUG")
This was breaking debug functionality for CLion (it was also breaking most of the debug functionality of gdb)
I also had the same Problem. Since 2016.3 CLion changed the CMake workflow so that only one configuration is allowed at one time clion new workflow
The solution is File -> Settings -> Build, Excution, Deployment -> change the build configuration
In my case my CMake option CMAKE_BUILD_TYPE was already set to DEBUG on CMake Settings. However, it was the command set(CMAKE_BUILD_TYPE Release) in the CMakeLists.txt, which was merged by git pull and overrode the CMake Settings while execution. I could not figure out earlier as CMake Debug console was showing -DCMAKE_BUILD_TYPE=Debug
When I changed it to set(CMAKE_BUILD_TYPE Debug) breakpoints were hit again.
In case this helps someone else:
In my case I had to set the -DCMAKE_BUILD_TYPE option to Debug explicitly in Settings -> Build, Execution, Deployment -> CMake
I had a different issue that caused my breakpoints not to be hit. I develop both embedded apps and native MacOS console apps with CLion. For the embedded work, GDB needs to be set for your selected Preferences/Toolchains.
For debugging console apps LLDB needs to be selected in Preferences/Toolchains. If it is left on GDB, my breakpoints don't work. Set to LLDB here:
I had a comma in my project path. Removing the comma fixed the problem for me.
In 2019.3, it turns out to be CLion/Preference/Build,Execution,Deployment/CMake/Build type/Debug.
My problem was with the -ffile-prefix-map flag. Once I removed it, everything worked fine.
See https://youtrack.jetbrains.com/issue/CPP-23159 and https://youtrack.jetbrains.com/issue/CPP-15850
I had the same issue. I noticed that every time I click the debug option, the "Antimalware Service Executable" process starts. I created an exclusion for MinGW folder in windows Defender and it worked fine...
Just like minecrawler said in github, if your os is linux, your should set：
file/Settings/Build,Execution,Deployment/Tllochains/Debugger from Bundled GEB or gdb to Bundled LLDB.
I tried and it worded！
In my case (Linux / Ubuntu) the problem was somehow related to mounted directory.
The project was initially opened in CLion from /media/username/ssd/repo/git/projectname. The breakpoints were always disabled with message No executable code is associated with this line.
Then I opened the same project from a symlinked directory
~/git -> /media/username/ssd/repo/git and the breakpoints began to work fine.
In my case I had to edit the file so that everything was compiled again instead of using cache.
In my case, the problem is forget to comment out optimize option add_definitions(-O3) in cmakelists. which let compiler go release.
in the case of "the platform is currently not connected" of CLION for RUST, it turns out there is an authorization step which is not enabled on CLION 2022.2 version.
download the correct version solves the problem