GoLand 2018.3.2 is out!

Ekaterina Zharova

Try it via Toolbox App, or update from any earlier 2018.3 with the use of Help | Check for Updates command, or just download a copy from our website.

Download GoLand 2018.3.2

Here’s a list of notable issues this update addresses:

GO-6474 — The debugger correctly displays variable names when their type is an interface.

GO-6523 — Code formatting formats the last parameters with three dots in variadic functions equal to go fmt rules.

GO-6488 — GoLand doesn’t show redundant Save files during the commit notifications when gofmt checkbox is enabled in the commit dialog.

GO-6596 — We’ve solved the problem with unresolved references to packages.

GO-6575 — The IDE correctly calculates array types when array length is specified via expressions like len(otherArray).

GO-6558 — The Move refactoring will preserve line feeds around refactored declarations.

Don’t forget that we always appreciate your feedback, so please share it with us here in comments, or Twitter, or our issue tracker. Thanks!

Comments below can no longer be edited.

6 Responses to GoLand 2018.3.2 is out!

  1. Todd Greenwood-Geer says:

    December 21, 2018


    GO-6596 — We’ve solved the problem with unresolved references to packages.

    This is most certainly not true, at least with:

    go version go1.11.2 linux/amd64

    Goland is virtually unusable at this point, due to unresolved references to packages.

    • Florin Pățan says:

      December 24, 2018

      Hi Todd,

      Sorry to hear you have issues with Go Modules support.
      Can you please either provide more details here, and a way to reproduce it, like in the referenced ticket, or open a ticket similar to it? Unfortunately, we don’t have any other report or data to verify/reproduce this issue based on the information above.

      Thank you.

  2. Ben says:

    December 23, 2018

    A small issue with the new (in)complete Go 1.11 support.

    When somebody uses:

    module testmodule.local/Example

    require (
    github.com/lib/pq v1.0.0
    somedir v0.0.0
    subdir2 v0.0.0

    replace somedir => ../somedir
    replace subdir2 => ../subdir2

    Because Go 1.11 can not handle local module imports correctly, you need to trick the go mod support by using replace statements like above. Goland is not able to detect these changes and thus has no ability to do any code checking, showing all module code as red…

    The old Go 1.10 with using these directly into the import ( “../somedir ” ), worked perfectly. But as Go 1.11 broke that functionality, it forces people into using this trickery.

    • Florin Pățan says:

      December 24, 2018

      Hi Ben,

      I had a look at the above case, using Go 1.11.4, and I cannot reproduce this (I’m on Windows).

      My go.mod file looks like this:

      module awesomeProject7

      require github.com/pkg/errors v0.8.0

      replace github.com/pkg/errors => ../myerrors

      and the go.mod file from the myerrors folder looks like this:

      module github.com/pkg/errors

      After applying the change to the go.mod file to add the replace statement, the IDE ran the sync command in background and everything else (completion, navigation, etc.) worked as expected.

      Can you please provide more information on this?
      Thank you.

      • Ben says:

        December 24, 2018

        Well, this will help …

        Under the Go settings, look at “Enable GO Modules (vgo) integration”, this was disabled… No wonder it did not work. When this is enabled, it can pick up the rewrite rule correctly.

        This was standard disabled on my installation. So thank you for the testing Florin, with this i knew the issue was somewhere else.

  3. James says:

    August 12, 2019

    I’m very new to Golang and Goland. Tried to run an extremely simple file and got the “unresolved reference *whatevs*” highlighting in Goland. In my case, *whatevs* was Println…as basic as it gets. Thankfully, I found this blog post and read Ben’s comment.

    Really curious why in the world that setting isn’t on by default…especially 8 months after this blog post.


Subscribe for updates