Fails to correctly handle multi-alias imports.

[dave]

When dst automatically manages the imports block, the imports are internally keyed by path. This incorrectly assumes that only one import for each package path is possible. Although very rare, it is possible to add the same package multiple times with different aliases.

See: golang/go@3409ce3

In TestLoadStdLibAll we test that the entire standard library is able to be parsed and rebuilt including management of the imports block. This test fails for the two files server.go and request.go in net/http because of this.

In order to handle this gracefully would involve a major rewrite of the import management code which is the most complex part of dst. For now I've skipped the TestLoadStdLibAll for these two files.

Re: @dmitshur

[dave]

This has come up again in the Go 1.15 standard library. I will exclude src/crypto/x509/x509.go from this test because it now has a duplicate import. This has come up twice now so I really should fix it.

p.s. I wonder if it was intentional to add a duplicate crypto/sha1 import in golang/go@6f3a951 @katiehockman

[katiehockman]

@dave Nope that wasn't intentional. I think it should keep the import that golang/go@6f3a951 added and remove the blank identifier import. Thanks for pointing that out.