Project Errors never show up

Nik Ogura Thank you for such detailed report, it is appreciated. I looked it into it, and the weird thing was that for me it worked out of the box, meaning that I got ./buildbug.go:9:2: undefined: blarg in both IDEA Ultimate and GoLand without having to change any setting. I played around with the Go Test configuration settings and noticed this: if in my Go Test config the Test kind is set to Directory, I get the FAIL json kind of output. But if I switch it to Package, then I get the error with the line number. 

Here is the screenshot of the settings that produced the “normal” error output for me:

Please give it a try and let me know if it works.

That does indeed work for me as a workaround.

I would encourage JetBrains to find, and correct the root cause of the regression though.

"Directory" tests are the default for "Go Test" configurations.  

From a UX perspective, it's best to have the defaults magically work.

Thank you!

-Nik

Svetlana Erokhina This thread was not about running Go tests and get line number feedback. It's about project-wide diagnostics in real-time based on gopls and the fact that Goland is the only editor that doesn't support it, even though it has a “Project errors” tab.

Gopls, Go's LSP server, provides real-time diagnostics while coding. So whenever I change something in the code that breaks some code somewhere else, I immediately see the errors without having to “Run tests”. My question would be if that's even possible in Goland, if Jetbrains is working on that?

Hi Louis,

Thanks for your message. Just to clarify—Nik's comment above came through to me as a separate ticket rather than part of the full original thread, so I didn't initially have the broader context when I replied. I definitely didn’t mean to skip any part of the ongoing discussion.

To answer your question: we are currently not working on supporting LSP out of the box, but some third-party plugins could cover your use case. For example, LSP4IJ, which you can find it in our Marketplace (Settings > Plugins). 

If you don't mind sharing, why do you prefer using LSP for the code verification and not the GoLand's built-in inspections? Understanding your use case would help us better support you and potentially improve the product.

Svetlana Erokhina It's about project-wide diagnostics in real-time. Goland has a “Project errors” tab but never shows Project errors.

Gopls, Go's LSP server, provides real-time diagnostics while coding. So whenever I change something in the code that breaks some code somewhere else, I immediately see the errors without having to “Run tests” or Run Inspections (which is very slow for large code bases).

I and other users in this thread described the problem in multiple ways already. I think it would actually be helpful if someone with real Go experience @ Jetbrains would review this thread.

This is kind of nuts. Svetlana Erokhina , your last message gives the impression that goland never had this feature, which is not true. Currently, on MacOS, I need to manually go to Problems (cmd+6) > Inspect Code… to see compilation errors on my project. This started after mid 2024. It didn't work like that before - I'm a paying customer for years, so I'm quite sure of what I'm saying here.

The issue in this thread is not general project diagnostics. It is about compilation errors. Like the print below, the underlying red line below packages with compilation errors. These should appear automatically. Currently to see these I need to follow the manual steps described earlier. This is what Louis is talking about in the messages above.

Streppel I've discussed this with the team and confirmed that GoLand hasn’t included automatic, project-wide compilation error reporting as an implemented feature. This behavior has been requested (see GO-4618), but it hasn’t been part of the product. In some cases, errors (such as red underlines you're referring to) may appear when you open a file or after running commands like go build or go test without having to start Inspect Code. This can create the impression that compilation errors are detected automatically, but GoLand doesn’t trigger such checks on the background unless you manually run Inspect Code or use the Problems view. 

If this ever appeared to work differently, it was most likely incidental or caused by some interaction with the project, not the result of a designed feature. If you believe there was a different behavior in older versions, we’d need a reproducible example (project, steps, screenshots, screencasts, version comparison) to investigate further. Based on everything we’ve seen, the current behavior is consistent.

Svetlana Erokhina thank you for your quick response. I have to admit that it really strikes me as a surprise, though. I wonder how the lack of this feature never bothered me except in the last few months, after all these years. Seems like a great coincidence with the opening of this thread.
 

I understand the issue you referenced, and it makes sense. I guess what bothers me the most, and what I think the bug is:

1. I run tests on whole project through the IDE
2. Terminal informs me that tests failed because of failed compilation
3. No feedbacks on UI. I need to manually go to `cmd+6 / Inspect Code` to see them

Shouldn't be like that. Step 3 shouldn't be needed.

Couple of things I'll try to do on my side when I have the time:

- I'll try to find a Linux machine (I'm on Mac) to see if I can replicate this issue

- I'll try to downgrade my goland to 2024.1 and see if something changes

Streppel Thank you for taking the time to investigate further on your end. If you find anything when testing on Linux or with an earlier version of GoLand, feel free to share. On my side, I’ve shared your feedback, as well as input from other users in this post, with the product owner. We’ll also see if we can improve the UI and overall workflow around handling compilation errors.

Streppel I agree with you in that I was certain that this feature existed in GoLand, though I haven't worked in Go for a while until in mid-2024 when I was surprised that the “Project errors” tab never showed any errors.

Svetlana Erokhina Perhaps you can elaborate why this tab exists when it virtually has zero functionality, if, as you say, project-wide errors were never a feature in GoLand.

I tried the LSP plugin, but that doesn't help either. GoLand suppresses any diagnostic output, and the “Project errors” tab stayed empty. I tried GoLand in Linux and Windows, still no project-wide errors.

I also checked GoLand 2023.x series, and it seems that Svetlana Erokhina is partially right, there are no project-wide errors, however I often see certain categories of problems from Go files that I never open, so it seems there was some form of project-wide diagnostics, but not the full Gopls version (meaning: errors that would come up on compilation).

Refactoring Go code across build targets is a big part of my daily life and it bothers me greatly that GoLand has no support for this basic functionality. Also, Code Inspections are now so slow (take minutes and often lead to “Low memory” errors), they are practically unusable while coding.

I work with Go teams that switched to VS Code just because GoLand doesn't have Project-wide diagnostics, a feature that not only VS Code provides, but literally every LSP-capable editor on the planet, including Vim and Emacs, has.

For the moment I have given up on GoLand, like most of my co-workers.

This bug is very old. I reported it (or another one) 3+ years ago.  The functionality just disappeared one day and hasn't been back.  Don't bother testing anything recent it won't be there.

The big reason why this is important is that when refactoring or updating a dependency many packages can be impacted.  It used to be displayed on the problems view, you could select current file or project wide with tabs.  Project wide gave a report of all packages and files that had issues.  This view used to work the same way as in IntelliJ for Java projects.

This may be a quirk of how Go works.  go build doesn't give a lot of details it just says package xyz failed to build etc.

I have given up on this bug.

Louis You're right about the Project Errors tab — we inherited it from IntelliJ IDEA, where it's used to show project-wide compilation errors in JVM languages. In GoLand, however, the tab currently doesn't serve much of a purpose, since Go projects don't use the same build system. Ideally, we should show Go compilation errors there someday (see GO-9494, GO-4618), but it hasn't been implemented yet. 

This is a major bug, IMO. It's not a missing feature: it used to work well; now it doesn't. It's a regression.

I'm frustrated that this issue has been outstanding for a year without being resolved.

I am unlikely to renew my licence unless it's fixed.

I am experiencing the same problem in Java projects in IntelliJ IDEA 2025.1.3 (Ultimate Edition). I can see compilation errors (and other warnings) for the current file in the File tab,  though I cannot see all errors in Project errors tab. It stays empty for Java and Go. A good thing is that I can see packages with errors in a Project view.
 

If you are using the new native typescript preview, make sure to disable it ( from Typescript settings in Webstorm ), otherwise, problems tool window will not show any project errors.

This bug is really a nightmare and impedes productivity with Goland. I have to rely on VSCode to get errors "in real time" without checking in every file, or otherwise compile by hand !
Eventually, I think I'll just end up using VSCode for everything…

This lack of basic project errors is truly embarrassing and I'll also be cancelling my plan because of it. It's crazy that you can change the name of a function (without refactor) and not see errors in files you've broken, and yet it works in VSCode which is free. I really loved Goland before this decision / bug / regression, refactoring in Goland used to be so reliable now it's an absolute nightmare and has been since 2022-2023 - whenever it changed. No, running inspect is not the same, not only is it terribly slow and hard to configure, the project errors disappear again after a change so you need to keep running it.. This should work out of the box, zero configuration.

+1 worse than gopls + vscode lol