aboutsummaryrefslogtreecommitdiff
path: root/src/crypto/tls/testdata/Client-TLSv12-ClientCert-RSA-RSA
diff options
context:
space:
mode:
authorJay Conrod <jayconrod@google.com>2019-05-16 12:38:41 -0400
committerJay Conrod <jayconrod@google.com>2019-05-16 22:39:38 +0000
commit97ecc4321ec3069d405c04cb2dc3132b39ef732e (patch)
treeebb1fb639ff4425c317c031b999cb6f30e654ca8 /src/crypto/tls/testdata/Client-TLSv12-ClientCert-RSA-RSA
parent4e7bef84c1a84f60791f4b3c23bdd3f3d9392e70 (diff)
downloadgo-97ecc4321ec3069d405c04cb2dc3132b39ef732e.tar.xz
cmd/go: don't panic when explaining lost upgrades due to downgrades
If a user runs 'go get mod@vers' where the module transitively requires itself at a newer version, 'go get' attempts to perform a downgrade, which necessarily excludes the requested version of the module. Previously, we called mvs.BuildList with the requested module version as the target. This panicked because BuildList doesn't allow the target module (typically the main module) to require a newer version of itself. With this change, when we lose an upgrade due to a downgrade, we call mvs.BuildList through a wrapper that treats the lost module version as requirement of a synthetic root module, rather than the target module. This avoids the panic. This change also starts reporting errors when an upgraded module is lost entirely (downgrades caused the module to be completely removed from the build list). Fixes #31491 Change-Id: I70ca261c20af7553cad2d3b840a1eaf3d18a4191 Reviewed-on: https://go-review.googlesource.com/c/go/+/177602 Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Diffstat (limited to 'src/crypto/tls/testdata/Client-TLSv12-ClientCert-RSA-RSA')
0 files changed, 0 insertions, 0 deletions