Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/gofmt: Slice literal condensed to one line and comment moved outside if comment is last line #18599

Open
btracey opened this issue Jan 10, 2017 · 2 comments
Assignees
Labels
Milestone

Comments

@btracey
Copy link
Contributor

@btracey btracey commented Jan 10, 2017

Perhaps a duplicate of #9460, but the issue discussion says it's restricted to for statements, and at the very least this is another symptom of the same problem.

What version of Go are you using (go version)?

go 1.7.3

What operating system and processor architecture are you using (go env)?

go playground

In my work, it's common to have a list of cases I want to run, and comments are a good way to remove them selectively. All of the following conditions format as is

// All on one line
cases := []int{1, 2, 3}
// Cases each on own line
cases := []int{
	1,
	2,
	3,
}
// Trailing comment in the list
cases := []int{
	1,
	2,
	//3,
}
// Trailing comment with newline at the start
cases := []int{
	1, 2, 3,
	//4,
}
// All items on the same line, with first commented
cases := []int{ // 1
	2, 3, 4}

But, in the specific case where there is no newline between the start of the slice and the slice items, and the comment is on a newline between the items and the trailing brace, the comment is moved outside of the slice literal.

Specifically:

cases := []int{1, 2, 3,
	//4,
}

Formats to:

cases := []int{1, 2, 3}//4,

Furthermore, newlines are kept if there are multiple trailing comments

cases := []int{1, 2, 3,
	//4,
	//5,
}

is formatted to

cases := []int{1, 2, 3}//4,
//5,

This is undesirable formatting, particularly this last case since the newline comment feels uncoupled from the literal.

@rakyll
Copy link
Contributor

@rakyll rakyll commented Jan 10, 2017

@griesemer griesemer self-assigned this Jan 10, 2017
@griesemer griesemer added this to the Go1.9Maybe milestone Jan 10, 2017
@griesemer
Copy link
Contributor

@griesemer griesemer commented Jun 19, 2017

I've spent some time on this today, and it's more complicated than I hoped for. The problem seems to appear when a composite literal could be written on a single line, were it not for the comments.
Which suggests an easy work-around: If you write your code in the form

var _ = []int{
	1, 2, 3,
	//4,
}

var _ = []int{
	1, 2, 3,
	//4,
	//5,
}

gofmt does what you'd expect. In other words, if you end up commenting out individual lines anyway (and write them on a separate line), don't put the initial elements on the line with the opening {. That's nicer formatting anyway: If the } is on a separate line (from the elements), put the { on a separate line (from the elements).

(And if you started out with a single line {1, 2, 3, 4} and what to comment out an element, use general comments: {1, 2, 3 /* , 4 */}).

Pushing to Go1.10 since there's a perfectly sensible formatting style that avoids the issue.

@griesemer griesemer modified the milestones: Go1.10, Go1.9Maybe Jun 19, 2017
@rsc rsc modified the milestones: Go1.10, Go1.11 Nov 22, 2017
@bradfitz bradfitz modified the milestones: Go1.11, Unplanned May 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.