go/printer: match indentation when returning multiple composite literals

[dsymonds]

http://play.golang.org/p/IxtYF1rXe9
-----
package main

type T struct {
    x int
    y string
}

func f() (*T, *T) {
    return &T{
            x: 1,
            y: "foo",
        }, &T{
            x: 2,
            y: "bar",
        }
}
-----

This doesn't happen when there's only one return value, or when one of the return values
is "nil".

[dsymonds]

Comment 1:

It also happens if one of the return values is an anonymous func, which is where I keep
tripping over this.

[rsc]

Comment 2:

Labels changed: added suggested, removed release-go1.3maybe.

[rsc]

Comment 3:

Labels changed: added release-none.

[griesemer]

Comment 4:

Labels changed: added repo-main.

[agnivade]

@dsymonds - Just to clarify - you expected something like this ?

func f() (*T, *T) {
	return &T{
		x: 1,
		y: "foo",
	}, &T{
		x: 2,
		y: "bar",
	}
}

i.e. one less indent when arranging the composite literals.

[dsymonds]

Yes, I'd expect those two closing braces for the &T literals to be at the same indentation as the return statement, but also the fields should only get a single level of indent, like what you get when you declare a var in the same way: (https://play.golang.org/p/0pH8-b_MdNI)

package main

type T struct {
	x int
	y string
}

func f() (*T, *T) {
	// Declaring a looks right.
	a := &T{
		x: 1,
		y: "foo",
	}

	// Returning a single composite literal looks right.
	return &T{
		x: 1,
		y: "foo",
	}

	// Returning multiple values looks wrong
	return &T{
			x: 1,
			y: "foo",
		}, &T{
			x: 2,
			y: "bar",
		}
}

[agnivade]

Analysis: This is due to the indentList() function in go/printer/nodes.go L1229. If that function returns false, then the literals line up as intended.

And looking at the comment, it seems to be intentionally written to solve issue #1207 (which was incidentally filed by @dsymonds yourself :)).

// Heuristic: indentList returns true if there are more than one multi-
// line element in the list, or if there is any element that is not
// starting on the same line as the previous one ends.

The difference appears if the element is itself a composite literal or not. For example, if that function returns false, this issue is solved. But issue 1207 breaks.

Breaks -

return &T{
       	x:	1,
       	y:	"foo",
},
      	nil

Fixes-

return &T{
        x:	1,
        y:	"foo",
 }, &T{
       	x:	2,
       	y:	"bar",
 }

Will leave it to @griesemer to take a final call if we want to add more heuristic to check if the elements are composite literals or not.