1# Regression test for https://golang.org/issue/46078:
2# 'go mod tidy' should not panic if the main module initially
3# requires an older version of itself.
4
5# A module may require an older version of itself without error. This is
6# inconsistent (the required version is never selected), but we still get
7# a reproducible build list.
8go list -m all
9stdout '^golang.org/issue/46078$'
10
11# 'go mod tidy' should fix this (and not crash).
12go mod tidy
13
14
15# We prune out redundant roots very early on in module loading, and at that
16# point the indirect requirement on example.net/x v0.1.0 appears to be
17# irrelevant. It should be pruned out; when the import of "example.net/x" is
18# later resolved, it should resolve at the latest version (v0.2.0), not the
19# version implied by the (former) misleading requirement on the older version of
20# the main module.
21
22cmp go.mod go.mod.tidy
23
24
25-- go.mod --
26module golang.org/issue/46078
27
28go 1.17
29
30replace (
31 example.net/x v0.1.0 => ./x
32 example.net/x v0.2.0 => ./x
33 golang.org/issue/46078 v0.1.0 => ./old
34)
35
36require golang.org/issue/46078 v0.1.0
37-- go.mod.tidy --
38module golang.org/issue/46078
39
40go 1.17
41
42replace (
43 example.net/x v0.1.0 => ./x
44 example.net/x v0.2.0 => ./x
45 golang.org/issue/46078 v0.1.0 => ./old
46)
47
48require example.net/x v0.2.0
49-- issue46078/issue.go --
50package issue46078
51
52import _ "example.net/x"
53
54-- old/go.mod --
55module golang.org/issue/46078
56
57go 1.17
58
59require example.net/x v0.1.0
60
61-- x/go.mod --
62module example.net/x
63
64go 1.17
65-- x/x.go --
66package x
View as plain text