A gofmt/goimports-like tool for Go programmers that fills in Go return statements with zero values to match the func return types

This issue is in regards to vscode no longer adding/removing imports on save. An additional option was added to override the use of goreturns -d and fallback to goreturns -w, which gets things working for me again.

The initial issue: https://github.com/Microsoft/vscode-go/issues/520

I am using:

• Go 1.6
• vscode 1.6.1
• vscode go plugin 0.6.45
• windows 10 Home

Hi :)

Your link sourcegraph.com/sqs/goreturns looks like being down. Also you seem to use gcimporter as a dependency, but it was moved to another page:

+ go get -u sourcegraph.com/sqs/goreturns
package golang.org/x/tools/go/gcimporter: cannot find package "golang.org/x/tools/go/gcimporter" in any of:
    /usr/local/go/src/golang.org/x/tools/go/gcimporter (from $GOROOT)
    /home/ubuntu/.go_workspace/src/golang.org/x/tools/go/gcimporter (from $GOPATH)
    /usr/local/go_workspace/src/golang.org/x/tools/go/gcimporter
package golang.org/x/tools/go/types: no buildable Go source files in /home/ubuntu/.go_workspace/src/golang.org/x/tools/go/types

Taken from our build-log here: https://circleci.com/gh/coala-analyzer/coala-bears/975

It would be nice if you could fix that as soon as possible, we from coala rely on your cool tool in our testing step :)

Okay, this is somewhat a bug/bad behavior upstream in GoSublime, but given that's it's quite popular and goreturns is meant to be a drop-in replacement for goimports or gofmt, I'll report it here.

The problem is that sometimes GoSublime will fail to apply its changes when it's configured to use goreturns instead of goimports or gofmt.

With the help of dump_args, I tracked it down the following weird behavior of GoSublime on save hook:

• If the process (goreturns in this case) emits any output on stderr, then GoSublime will not proceed with applying the change. Even if exit code is 0. However, goreturns will sometimes output warnings/information to stderr.

I've seen it output things like this to stderr:

main.go:35:2: could not import code.google.com/p/go.net/websocket (can't find import: code.google.com/p/go.net/websocket)
main.go: typechecking failed (continuing without type info)

I'm pretty sure https://github.com/DisposaBoy/GoSublime should only look at the exit code, not whether stderr was written to, so you might want to try to get it resolved upstream with @DisposaBoy.

go version go1.6.2 linux/amd64

$ go get github.com/sqs/goreturns
package sourcegraph.com/sqs/goreturns/returns: unrecognized import path "sourcegraph.com/sqs/goreturns/returns" (parse https://sourcegraph.com/sqs/goreturns/returns?go-get=1: no go-import meta tags)

The entire https://sourcegraph.com/sqs* tree returns a 404.

PS: Looks like it's the same issue as https://github.com/sqs/goreturns/issues/21, but unable to figure out how the fix works

https://github.com/Microsoft/vscode-go/issues/1107 HI，there is an issue when i use "github.com/deckarep/golang-set". Formatting will auto removed the module from my imports while the package mapset is used in my code such as "mapset.NewSetFromSlice(x)". But other modules is ok. Is there any solutions to resolve this? Thank you.

It converts

func Fb() (res int, err error) {
    err = errors.New("foo")
    return
}

into

func Fb() (res int, err error) {
    err = errors.New("foo")
    return res, err
}

Hi,

The following code in g() seems to be indented differently depending if I use goimports (same formatting as gofmt) or goreturns :

package test

func g() {
        f().
                Scan(a,
                b)
        return
}

func h() {
        Scan(a,
                b)
}

Note that there is no return value involved here... (I built this minimal sample from a much larger file where some coworkers and me were wondering why the formatting was always changing between our commits... turns out is was caused by us using different formatting tools !).

Reference: https://groups.google.com/forum/#!topic/golang-nuts/eD8dh3T9yyA

Go Tools import paths have changed. This PR updates imports of Go Tools packages accordingly.

Fixes #2. Add test case for preserving returns in closures when correct number of values. Enable test case for processing returns in closures (not just top-level func decls).

This is a somewhat rare situation, so you can get away with delaying fixing this until later and use/evaluate goreturns on other stuff... But I'll report it here anyway.

It seems when you're iterating over ast to adjust the returns, you're not taking into account potential func literals inside funcs/methods.

So, here's a simple reproduce case. Take this valid Go code:

http://play.golang.org/p/KQj9uHSvza

After running it through goreturns, it will become incorrect:

package main

import "fmt"

func getMessage() (string, error) {
    foo := func() string {
        return "", "Hello, playground."
    }
    return foo(), nil
}

func main() {
    m, err := getMessage()
    if err != nil {
        panic(err)
    }
    fmt.Println(m)
}

--- /var/folders/tw/kgz4v2kn4n7d7ryg5k_z3dk40000gn/T/gofmt388411413 2014-10-07 22:02:03.000000000 -0700
+++ /var/folders/tw/kgz4v2kn4n7d7ryg5k_z3dk40000gn/T/gofmt302595696 2014-10-07 22:02:03.000000000 -0700
@@ -4,7 +4,7 @@

 func getMessage() (string, error) {
    foo := func() string {
-       return "Hello, playground."
+       return "", "Hello, playground."
    }
    return foo(), nil

See this controversial gofmt issue https://code.google.com/p/go/issues/detail?id=7101.

You might want to avoid going down that path by not including these options:

  -comments=true: print comments
  -tabs=true: indent with tabs
  -tabwidth=8: tab width

Note that neither gofmt nor goimports includes those.

Did you include them on purpose?

go version go1.18.3 linux/amd64

test file aa.go

package a

func F() (*MyType, int, error) { return errors.New("foo") }

Now the test

user@PC:~$ goreturns <aa.go
package a

import "errors"

func F() (*MyType, int, error) { return errors.New("foo") }

'return' is not changed.

package main func func1() (ret, msg string) { return "ok", "done" } func func2() (string, string) { return func1() } func main() { func2() }

run goreturns, -return func1()

• return "", func1()

full output: $ goreturns c.go package main

func func1() (ret, msg string) { return "ok", "done" } func func2() (string, string) { return "", func1() } func main() { func2() }

this will break build, confirmed this issue with latest goreturns.

Since vscode does not accept custom command / flags for goreturns, this seems the best way to add flags (for example -local in our case). Create a ~/.goreturns.json file with this template:

{
	"fragment": false,
	"printErrors": false,
	"allErrors": false,
	"removeBareReturns": false,
	"local": ""
}

Passing flags will override these values.

goreturns doesn't generate enough return parameters for the following snippet when using the -b flag to remove bare returns. goreturns -b -w file.go

file.go:

package main

func temp() (a, b, c uint64, ok bool) {
	return
}

Output:

package main

func temp() (a, b, c uint64, ok bool) {
	return a, ok
}

Expected:

package main

func temp() (a, b, c uint64, ok bool) {
	return a, b, c, ok
}

Here is a diff example of bare return rewrite when using goreturns -b -i -l -w .:

 	if err != nil {
-		return
+		return output,
+
+			// Processing output
+			err
 	}

-	// Processing output
 	if updateCache {

expected result:

 	if err != nil {
-		return
+		return output, err
 	}

	// Processing output
 	if updateCache {

It is interesting that the rewrite escapes the {...} block.