1# This test makes checks against a regression of a bug in the Go command
2# where the module loader hung forever because all main module dependencies
3# kept workspace pruning instead of adopting the pruning in their go.mod
4# files, and the loader kept adding dependencies on the queue until they
5# were either pruned or unpruned, never breaking a module dependency cycle.
6#
7# This is the module graph in the test:
8#
9# /-------------------------\
10# | |
11# V |
12# example.com/a -> example.com/b v1.0.0 -> example.com/c v1.1.0
13
14go list -m -f '{{.Version}}' example.com/c
15
16-- go.work --
17go 1.16
18
19use (
20 ./a
21)
22-- a/go.mod --
23module example.com/a
24
25go 1.18
26
27require example.com/b v1.0.0
28
29replace example.com/b v1.0.0 => ../b
30replace example.com/c v1.0.0 => ../c
31-- a/foo.go --
32package main
33
34import "example.com/b"
35
36func main() {
37 b.B()
38}
39-- b/go.mod --
40module example.com/b
41
42go 1.18
43
44require example.com/c v1.0.0
45-- b/b.go --
46package b
47
48func B() {
49}
50-- b/cmd/main.go --
51package main
52
53import "example.com/c"
54
55func main() {
56 c.C()
57}
58-- c/go.mod --
59module example.com/c
60
61go 1.18
62
63require example.com/b v1.0.0
64-- c/c.go --
65package c
66
67import "example.com/b"
68
69func C() {
70 b.B()
71}View as plain text