blob: ffcea186035574da7373494a69c3dc3ce050298c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
# Regression test for https://golang.org/issue/46078:
# 'go mod tidy' should not panic if the main module initially
# requires an older version of itself.
# A module that explicitly requires an older version of itself should be
# rejected as inconsistent: we enforce that every explicit requirement is the
# selected version of its module path, but the selected version of the main
# module is always itself — not some explicit version.
! go list -m all
stderr '^go: updates to go\.mod needed; to update it:\n\tgo mod tidy$'
# The suggested 'go mod tidy' command should succeed (not crash).
go mod tidy
# We prune out redundant roots very early on in module loading, and at that
# point the indirect requirement on example.net/x v0.1.0 appears to be
# irrelevant. It should be pruned out; when the import of "example.net/x" is
# later resolved, it should resolve at the latest version (v0.2.0), not the
# version implied by the (former) misleading requirement on the older version of
# the main module.
cmp go.mod go.mod.tidy
-- go.mod --
module golang.org/issue/46078
go 1.17
replace (
example.net/x v0.1.0 => ./x
example.net/x v0.2.0 => ./x
golang.org/issue/46078 v0.1.0 => ./old
)
require golang.org/issue/46078 v0.1.0
-- go.mod.tidy --
module golang.org/issue/46078
go 1.17
replace (
example.net/x v0.1.0 => ./x
example.net/x v0.2.0 => ./x
golang.org/issue/46078 v0.1.0 => ./old
)
require example.net/x v0.2.0
-- issue46078/issue.go --
package issue46078
import _ "example.net/x"
-- old/go.mod --
module golang.org/issue/46078
go 1.17
require example.net/x v0.1.0
-- x/go.mod --
module example.net/x
go 1.17
-- x/x.go --
package x
|
