Change https://golang.org/cl/340349 mentions this issue: mod/modfile: 'go mod tidy' may delete comments on require blocks

However, if all of the requirements in a block are moved to a new block, and the old block is [deleted], the new block should inherit the comments from the old block.

What happens if we also add other new modules in the same block, or delete some of the modules from the original block and retain the rest? If we add other new ones, we have no way to know whether the comment applies to them. I guess deletion should theoretically be ok, though.

But what if the comment says something like these indirect dependencies are only needed for example.com/bar, and they're being moved from the indirect section to the direct one? Then preserving the comment on the new block would be equally wrong.

Honestly, I would rather we just retain the empty require block and its comment and let the user decide what to do about it when they read the diff (https://play.golang.org/p/-jeTQAvJ9Ll).

module test

go 1.17

// don't delete me
require (
)

require example.com/m v0.0.0

replace example.com/m v0.0.0 => ./m

Or, another option might be to avoid moving a dependency between blocks if its existing require block has a block-level comment.

That would potentially introduce mixed-dependency blocks where they were previously single-kind, but would always preserve the block comments that apply to a given dependency — even if its classification changes, and even if other requirements are added or removed in the same block at the same time.

On balance, I think I prefer the latter approach. Let's just keep a dependency in the same require block it was already in if that block has a comment.

Similarly, perhaps we shouldn't add new dependencies into an existing block with a block comment.

I like the simplicity of not moving directives into or out of require blocks with comments and not deleting blocks with comments that become empty. These are all going to be custom situations with hand edits, and it's hard to pick a behavior that will work everywhere, so let's go with something simple.

@bcmills In this case,What do we expect to see?

module m
// save
require (
    x.y/a v1.2.3 
)
require (
    x.y/a v1.2.3 // comments
)

A:

module m
// save
require (
)
require x.y/a v1.2.3 // comments

B:

module m
// save
require x.y/a v1.2.3

C:

module m
// save
require x.y/a v1.2.3 // comments

D:

module m
require x.y/a v1.2.3 // comments

Change https://golang.org/cl/343431 mentions this issue: modfile: in SetRequireSeparateIndirect, arrange requirements consistently

Change https://golang.org/cl/343432 mentions this issue: cmd/go: write go.mod requirements more consistently for go 1.17+