Software: Apache. PHP/5.4.45 

uname -a: Linux webm003.cluster110.gra.hosting.ovh.net 5.15.167-ovh-vps-grsec-zfs-classid #1 SMP Tue
Sep 17 08:14:20 UTC 2024 x86_64 

uid=243112(mycochar) gid=100(users) groups=100(users)  

Safe-mode: OFF (not secure)

/home/mycochar/gcc-12.2.0/libgo/go/cmd/go/testdata/script/   drwxr-xr-x
Free 0 B of 0 B (0%)
Your ip: 216.73.216.218 - Server ip: 213.186.33.19
                            

Viewing file:     work_regression_hang.txt (1.27 KB)      -rw-r--r--

# This test makes checks against a regression of a bug in the Go command
# where the module loader hung forever because all main module dependencies
# kept workspace pruning instead of adopting the pruning in their go.mod
# files, and the loader kept adding dependencies on the queue until they
# were either pruned or unpruned, never breaking a module dependency cycle.
#
# This is the module graph in the test:
#
#                               /-------------------------\
#                              |                          |
#                              V                          |
#  example.com/a -> example.com/b v1.0.0 -> example.com/c v1.1.0

go list -m -f '{{.Version}}' example.com/c

-- go.work --
go 1.16

use (
	./a
)
-- a/go.mod --
module example.com/a

go 1.18

require example.com/b v1.0.0

replace example.com/b v1.0.0 => ../b
replace example.com/c v1.0.0 => ../c
-- a/foo.go --
package main

import "example.com/b"

func main() {
	b.B()
}
-- b/go.mod --
module example.com/b

go 1.18

require example.com/c v1.0.0
-- b/b.go --
package b

func B() {
}
-- b/cmd/main.go --
package main

import "example.com/c"

func main() {
	c.C()
}
-- c/go.mod --
module example.com/c

go 1.18

require example.com/b v1.0.0
-- c/c.go --
package c

import "example.com/b"

func C() {
	b.B()
}