diff options
Diffstat (limited to 'src/cmd/go/internal/mvs/mvs_test.go')
| -rw-r--r-- | src/cmd/go/internal/mvs/mvs_test.go | 160 |
1 files changed, 135 insertions, 25 deletions
diff --git a/src/cmd/go/internal/mvs/mvs_test.go b/src/cmd/go/internal/mvs/mvs_test.go index 721cd9635c..598ed66688 100644 --- a/src/cmd/go/internal/mvs/mvs_test.go +++ b/src/cmd/go/internal/mvs/mvs_test.go @@ -28,10 +28,11 @@ D4: E2 F1 D5: E2 G1: C4 A2: B1 C4 D4 -build A: A B1 C2 D4 E2 F1 -upgrade* A: A B1 C4 D5 E2 F1 G1 -upgrade A C4: A B1 C4 D4 E2 F1 G1 -downgrade A2 D2: A2 C4 D2 +build A: A B1 C2 D4 E2 F1 +upgrade* A: A B1 C4 D5 E2 F1 G1 +upgrade A C4: A B1 C4 D4 E2 F1 G1 +build A2: A2 B1 C4 D4 E2 F1 G1 +downgrade A2 D2: A2 C4 D2 E2 F1 G1 name: trim A: B1 C2 @@ -68,7 +69,7 @@ B2: D1 C: D2 D1: E2 D2: E1 -build A: A B1 C D2 E1 +build A: A B1 C D2 E1 upgrade A B2: A B2 C D2 E2 name: cross1R @@ -136,17 +137,17 @@ name: cross5 A: D1 D1: E2 D2: E1 -build A: A D1 E2 -upgrade* A: A D2 E2 -upgrade A D2: A D2 E2 +build A: A D1 E2 +upgrade* A: A D2 E2 +upgrade A D2: A D2 E2 upgradereq A D2: D2 E2 name: cross6 A: D2 D1: E2 D2: E1 -build A: A D2 E1 -upgrade* A: A D2 E2 +build A: A D2 E1 +upgrade* A: A D2 E2 upgrade A E2: A D2 E2 name: cross7 @@ -175,7 +176,7 @@ B1: D1 B2: C2: D2: -build A: A B1 C1 D1 +build A: A B1 C1 D1 upgrade* A: A B2 C2 D2 name: simplify @@ -194,7 +195,7 @@ B4: B5.hidden: C2: C3: -build A: A B1 C1 +build A: A B1 C1 upgrade* A: A B4 C3 name: up2 @@ -206,15 +207,15 @@ B4: B5.hidden: C2: C3: -build A: A B5.hidden C1 +build A: A B5.hidden C1 upgrade* A: A B5.hidden C3 name: down1 A: B2 B1: C1 B2: C2 -build A: A B2 C2 -downgrade A C1: A B1 +build A: A B2 C2 +downgrade A C1: A B1 C1 name: down2 A: B2 E2 @@ -227,19 +228,113 @@ D2: B2 E2: D2 E1: F1: -downgrade A F1: A B1 E1 +build A: A B2 C2 D2 E2 F2 +downgrade A F1: A B1 C1 D1 E1 F1 + +# https://research.swtch.com/vgo-mvs#algorithm_4: +# “[D]owngrades are constrained to only downgrade packages, not also upgrade +# them; if an upgrade before downgrade is needed, the user must ask for it +# explicitly.” +# +# Here, downgrading B2 to B1 upgrades C1 to C2, and C2 does not depend on D2. +# However, C2 would be an upgrade — not a downgrade — so B1 must also be +# rejected. +name: downcross1 +A: B2 C1 +B1: C2 +B2: C1 +C1: D2 +C2: +D1: +D2: +build A: A B2 C1 D2 +downgrade A D1: A D1 + +# https://research.swtch.com/vgo-mvs#algorithm_4: +# “Unlike upgrades, downgrades must work by removing requirements, not adding +# them.” +# +# However, downgrading a requirement may introduce a new requirement on a +# previously-unrequired module. If each dependency's requirements are complete +# (“tidy”), that can't change the behavior of any other package whose version is +# not also being downgraded, so we should allow it. +name: downcross2 +A: B2 +B1: C1 +B2: D2 +C1: +D1: +D2: +build A: A B2 D2 +downgrade A D1: A B1 C1 D1 name: downcycle A: A B2 B2: A B1: +build A: A B2 downgrade A B1: A B1 +# Both B3 and C2 require D2. +# If we downgrade D to D1, then in isolation B3 would downgrade to B1, +# because B2 is hidden — B1 is the next-highest version that is not hidden. +# However, if we downgrade D, we will also downgrade C to C1. +# And C1 requires B2.hidden, and B2.hidden also meets our requirements: +# it is compatible with D1 and a strict downgrade from B3. +# +# Since neither the initial nor the final build list includes B1, +# and the nothing in the final downgraded build list requires E at all, +# no dependency on E1 (required by only B1) should be introduced. +# +name: downhiddenartifact +A: B3 C2 +A1: B3 +B1: E1 +B2.hidden: +B3: D2 +C1: B2.hidden +C2: D2 +D1: +D2: +build A1: A1 B3 D2 +downgrade A1 D1: A1 B1 D1 E1 +build A: A B3 C2 D2 +downgrade A D1: A B2.hidden C1 D1 + +# Both B3 and C3 require D2. +# If we downgrade D to D1, then in isolation B3 would downgrade to B1, +# and C3 would downgrade to C1. +# But C1 requires B2.hidden, and B1 requires C2.hidden, so we can't +# downgrade to either of those without pulling the other back up a little. +# +# B2.hidden and C2.hidden are both compatible with D1, so that still +# meets our requirements — but then we're in an odd state in which +# B and C have both been downgraded to hidden versions, without any +# remaining requirements to explain how those hidden versions got there. +# +# TODO(bcmills): Would it be better to force downgrades to land on non-hidden +# versions? +# In this case, that would remove the dependencies on B and C entirely. +# +name: downhiddencross +A: B3 C3 +B1: C2.hidden +B2.hidden: +B3: D2 +C1: B2.hidden +C2.hidden: +C3: D2 +D1: +D2: +build A: A B3 C3 D2 +downgrade A D1: A B2.hidden C2.hidden D1 + # golang.org/issue/25542. name: noprev1 A: B4 C2 B2.hidden: C2: +build A: A B4 C2 downgrade A B2.hidden: A B2.hidden C2 name: noprev2 @@ -247,6 +342,7 @@ A: B4 C2 B2.hidden: B1: C2: +build A: A B4 C2 downgrade A B2.hidden: A B2.hidden C2 name: noprev3 @@ -254,6 +350,7 @@ A: B4 C2 B3: B2.hidden: C2: +build A: A B4 C2 downgrade A B2.hidden: A B2.hidden C2 # Cycles involving the target. @@ -264,9 +361,9 @@ A: B1 B1: A1 B2: A2 B3: A3 -build A: A B1 +build A: A B1 upgrade A B2: A B2 -upgrade* A: A B3 +upgrade* A: A B3 # golang.org/issue/29773: # Requirements of older versions of the target @@ -280,7 +377,7 @@ B2: A2 C1: A2 C2: D2: -build A: A B1 C1 D1 +build A: A B1 C1 D1 upgrade* A: A B2 C2 D2 # Cycles with multiple possible solutions. @@ -293,23 +390,23 @@ B2: C2 C1: C2: B2 build M: M A1 B2 C2 -req M: A1 B2 -req M A: A1 B2 -req M C: A1 C2 +req M: A1 B2 +req M A: A1 B2 +req M C: A1 C2 # Requirement minimization. name: req1 A: B1 C1 D1 E1 F1 B1: C1 E1 F1 -req A: B1 D1 +req A: B1 D1 req A C: B1 C1 D1 name: req2 A: G1 H1 G1: H1 H1: G1 -req A: G1 +req A: G1 req A G: G1 req A H: H1 @@ -326,7 +423,20 @@ M: Anone B1 D1 E1 B1: Cnone D1 E1: Fnone build M: M B1 D1 E1 -req M: B1 E1 +req M: B1 E1 + +name: reqdup +M: A1 B1 +A1: B1 +B1: +req M A A: A1 + +name: reqcross +M: A1 B1 C1 +A1: B1 C1 +B1: C1 +C1: +req M A B: A1 B1 ` func Test(t *testing.T) { |