Repository navigation
Fails to correctly handle multi-alias imports. #45
Description
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
Activity
dave commentedon Aug 23, 2020
This has come up again in the Go 1.15 standard library. I will exclude
src/crypto/x509/x509.gofrom 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/sha1import in golang/go@6f3a951 @katiehockmanExclude crypto/x509/x509.go from TestLoadStdLibAll and update comment…
katiehockman commentedon Aug 25, 2020
@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.
crypto/x509: fix duplicate import
crypto/x509: fix duplicate import
Exclude crypto/x509/x509.go from TestLoadStdLibAll and update comment…
Update the standard library test for current Go releases
Update the standard library test for current Go releases
Update the standard library test for current Go releases