I have installed the Go extension (version 0.11.4) in Visual Studio Code on MacOS:
However, I find that the linter does not 'pick up' functions defined in the same package, but in different files. For example, if I create in the same directory a file foo.go with
package foobar
import "fmt"
func main() {
fmt.Println(SayHello())
}
and a file bar.go with
package foobar
func SayHello() string {
return "Hello, world!"
}
then in foo.go I get a linter error that SayHello is an undeclared name:
I've read about a similar issue here (https://github.com/golang/lint/issues/57), but since that issue is five years old I figured it might be fixed by now? Or does golint simply not work across multiple files?
[The original answer is outdated; here is up-to-date information provided by the vscode-go maintainers. The updated answer is now marked as "Recommended" in the Go collective]
The plugin has changed a lot since 2019.
In 2021, Go Modules became the default which may have changed how the program is built and analyzed.
The vscode-go plugin uses gopls as the language server by default. Note that in 2019, there were two different language servers and gopls was still in experimental mode.
golint was deprecated.
If you still have a similar issue, it's likely that you are seeing a different problem.
Please check the followings:
Do you have go.mod? Otherwise, initialize your working module and restart the language server or reload the window.
Is the go.mod file in the root directory of your workspace? See gopls workspace setup
guide for complex setup.
Do you use build tags or other build constraints? Then see issue 29202. You may need to configure "go.buildTags" or "go.buildFlags".
If you expect lint errors from linters like staticcheck, golangci-lint, ..., check "go.lintOnSave" is set to the right scope.
If you notice that restarting the language server ("Go: Restart Language Server" command) fixes your issue, that's a gopls bug. Please consider to file an issue in github.com/golang/vscode-go following the troubleshooting guide.
Otherwise, please open a new question with details.
----- Original answer -------
I faced same problem. I found that I got into this problem after enabling "Go language server" which is an experimental feature. I disabled it in VS code settings->Go Configuration and after that the problem went away.
Update VS Code Go Tool might help.
Command + Shift + P -> Go: Install/update tools
Install all tools and restart VS Code.
May 2022 update:
This solution only works if you haven't installed the helper tools. Normally after you installed these packages it'll work right away with the default configuration, if you still have a problem, take a look at the answer above.
The cause of this warning for me was the setting go.lintOnSave, which was set to file. Changing the value to package made the linter correctly pick up the types defined in other files.
For people who ended up here:
The plugin has changed a lot since 2019.
In 2021, Go Module became the default which may have changed how the program is built and analyzed.
The vscode-go plugin uses gopls as the language server by default. Note that in 2019, there were two different language servers and gopls was still in experimental mode.
golint was deprecated.
If you still have a similar issue, it's likely that you are seeing a different problem.
Please check the followings:
Do you have go.mod? Otherwise, initialize your working module and restart the language server or reload the window.
Is the go.mod file in the root directory of your workspace? See gopls workspace setup
guide for complex setup.
Do you use build tags or other build constraints? Then see issue 29202. You may need to configure "go.buildTags" or "go.buildFlags".
If you expect lint errors from linters like staticcheck, golangci-lint, ..., check "go.lintOnSave" is set to the right scope.
If you notice that restarting the language server ("Go: Restart Language Server" command) fixes your issue, that's a gopls bug. Please consider to file an issue in github.com/golang/vscode-go following the troubleshooting guide.
Otherwise, please open a new question with details.
Update Install/update tools for GO
Open your code as main project in VS Code and avoid multiple projects/workspace in the same VS Code.
**
Single Project VS Code
**
**
Avoid Multiple Project in VS Code
**
If you run across this and are NOT using modules, then adding "go.useLanguageServer": false will disable gopls and return you to your former environment. (meaning vscode will now recognize functions and structures defined in multiple files in the same package)
In my case it was a missing go.mod file. I fixed with the following command:
go mod init example.com/myProject/myModule
Of course you should use a more reasonable module name.
Make clean uninstall of vscode and then it's work fine again...
add sudo if you needed to
rm -rf $HOME/Library/Application\ Support/Code
rm -rf $HOME/.vscode
Remove vscode from application
Download vscode and install again
One possible reason:
If you are referencing a function/variableis declared in a test file (*_test.go) from a non test file, this error would be thrown.
In my case, I just restarted VS Code and the error went away.
After almost pulling my hair out, I found that linting was working but I had many files with errors. I haven't yet found the hierarchy followed but fixing problems in one file subsequently led to it correctly linting another file. I think it follows the execution tree, although I haven't validated this.
I found this annoying as it can mistakenly lead you to think that linting is not working, while in fact, it's lining a file that you're not currently focussed on, especially if you have generated files that you're not interested in.
Another solution might be that you need to have the folder opened in VS Code with the go.mod file included. So you might have a folder structure that looks like workspace/application/modules/xyz.go. If you have the go.mod file in the application folder and modules is the folder you have open in VS Code it will complain.
I came across this issue by having the go extension installed, and attempting to utilize the same package name with a module under a different directory.
Files at Root: main.go, a.go, and go.mod
Sub-directory: nested/b.go
Problem: Attempting to label b.go as package main when it is under a different directory.
Solutions:
Move b.go up to project root and retain package name; all works as expected,
or
Change package name of b.go from package main to package nested, then add imports for b.go to main.go via:
// main.go
package main
import "example/nested"
func main() {
A()
nested.B()
}
and b.go:
// b.go
package nested
import "fmt"
func B() {
fmt.Println("Hello from B")
}
I have to try to use dlib for my project.
However, when I try to build it, I receive a message about:
"_USER_ERROR__missing_dlib_all_source_cpp_file__OR__inconsistent_use_of_DEBUG_or_ENABLE_ASSERTS_preprocessor_directives"
For solving this issue
I tried to add it new project
I deleted every existing path or data
I tried to build it on "Release mode"
I have still receive a message:
"_USER_ERROR__missing_dlib_all_source_cpp_file__OR__inconsistent_use_of_DEBUG_or_ENABLE_ASSERTS_preprocessor_directives"
Please, solve my curiosity!
You can check the link for dlib integration. Also check the following things for configuration.
1.Header search path for the lib folder. for e.g. $(PROJECT_DIR)/lib where lib folder contains libdlib.a and dlib header files.
2.Check the Preprocessor macros in build setting whether properly
set or not.
3.Create the Objective c++(change .m to .mm extension) wrapper class which can execute both c++ and objective c code.
*Note import dlib header files in wrapper class not in the main.m or app-delegate otherwise it will gives error.
Also check the Reference.
Getting an error when trying to run go build ./... from my $GOPATH/src .
no non-test Go files in <dir>
The error is correct there are no test files in <dir> but why is that causing a compile error? Is it a bug?
I don't think this is a bug, unless you see somewhere in the docs that contradicts this behaviour you should probably close the issue you've created.
Tests in go normally live in the package they are testing. You have made a new package with package main at the top (invalid if you also have main elsewhere), and then have included no go source files in that tests/main package (invalid as package has no go source files apart from tests, which the compiler complains about explicitly).
Possible solutions for you (assuming this isn't just a hypothetical question):
Move tests for main to test_main.go (this is what readers will
expect)
Add doc.go file to your tests pkg and call it package tests in
both files
The reason for putting tests in the same package is to ensure they have access to the entire package, if you want to split them to another package you'll find you have to test as an external user of the pkg - this may be painful. Main is also a special case as well as you don't normally import it.
Calling it a bug… the build shouldn't fail if the tests compile. Filed here: https://github.com/golang/go/issues/22409
The bug I filed was a duplicate of https://github.com/golang/go/issues/8279 looks like it was broken in 1.3.
First, check your $GOPATH has been set correctly. Learn more at here.
Then, check if any '_' in your file name. Remove these '_'s and try again.
;-)
I am getting familiar myself to LLVM, and my goal is to implement a back-end for my custom processor.
Before I jump into my back-end implementation, I first try to learn how a build procedure works, so I first copy lib/Target/MSP430 to lib/Target/myproc, and build llvm targeting "myproc" (even though it actually is a back-end for MSP430, I did this just to learn how I can add a new target to LLVM).
When I configure/make llvm, I got the following error message.
...
/bin/cp: cannot stat `/mydir/build/lib/Target/myproc/Debug+Asserts/MSP430GenRegisterInfo.inc.tmp': No such file or directory
...
I checked /lib/Target/myproc, and saw there was only one file, Makefile, copied from /lib/Target/myproc.
Here is what I have done before I configure and make.
In my LLVM source directory, copy lib/Target/MSP430 to lib/Target/myproc.
Modify configure and projects/sample/configure to add "myproc".
Go to lib/Target/myproc and change "MSP430" to "myproc" in MSP430.td, LLVMBuild.txt, and Makefile (I also modify the files in subdirectories).
As the LLVM compile works for other targets on my machine, I believe it's not the problem of machine of tools that I am using, but the problem of my modification.
Am I missing something? Are there any further modifications that I am supposed to make?
There's a decent tutorial for writing backends here:
http://llvm.org/docs/WritingAnLLVMBackend.html
There's also this tutorial from a dev meeting:
http://llvm.org/devmtg/2012-04-12/Slides/Workshops/Anton_Korobeynikov.pdf
*GenRegisterInfo.inc comes from running tblgen on the target .td file. The .inc output file name depends on what the .td files are named in the myproc/ target directory.
It would be helpful to see more of your make log but my guess is that you're getting a tblgen error when processing .td files in myproc/. That tblgen error is the real problem you need to diagnose and address.
I want to use oclint (an Objective-C static analyzer) for my projects but the official documentation does not clearly describe how to configure it.
How do I use it?
I have installed the oclint package then copied the script for capturing projects configs into a project's folder. Running this script creates an empty file named compile_commands.json and it does not fill xcodebuild.log with any data.
Thank you!
I don't think this script will add anything into xcodebuild.log. It reads from it. You may want to manually run xcodebuild and save the output into xcodebuild.log before running the script.
Check out the documentation.
I have had luck with the manual route of copying the script into my project's folder then executing it on the command line.
Though this does not integrate oclint's functionality into XCode, it does provide feedback via stdout.
From this feedback I then update my code to align with oclint's recommendation and iteratively run oclint until my code complies with oclint's rules.