Currently lockextra always increments extraMInUse, even if the M won't
be used (or doesn't even exist), such as in addExtraM. addExtraM fails
to decrement extraMInUse, so it stays elevated forever.
Fix this bug and simplify the model by moving extraMInUse out of
lockextra to getExtraM, where we know the M will actually be used.
While we're here, remove the nilokay argument from getExtraM, which is
always false.
Fixes#60540.
Change-Id: I7a5d97456b3bc6ea1baeb06b5b2975e3b8dd96a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/499677
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #59959.
For #58645.
Change-Id: I574153ef2fd61a5e90ec281fca065c42fce22cc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/498263
Reviewed-by: Eli Bendersky <eliben@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also add a missing </a> in the preceding section.
For #53761
Change-Id: I8e64b86b5b32067f954d58cf9adf86cb4d2eeb2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/499735
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Eli Bendersky <eliben@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
Some files already use "slices", others use "cmd/go/internal/slices".
(Some files are using more than slices.Clip and must use "slices".)
Use "slices" consistently and delete cmd/go/internal/slices.
Change-Id: I69ec680106ad2924276f7473e6547a3a907efc96
Reviewed-on: https://go-review.googlesource.com/c/go/+/499715
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
We were using the omission of toolchain from the MVS graph
as a signal that toolchain was not mentioned on the go get line,
but not including it in the graph causes various problems,
and it may be reintroduced to the graph during operations like
pruning conversion, after which its presence is not a good signal
about whether it was mentioned on the go get command line.
Fix all this irregularity by explicitly telling WriteGoMod whether
the command line mentioned toolchain instead.
For #57001.
Change-Id: I74084637c177c30918fdb114a0d9030cdee7324e
Reviewed-on: https://go-review.googlesource.com/c/go/+/499575
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
For a unification failure involving a constraint, rather than just
reporting (for instance)
S does not match []E
now report the inferred type for the type parameter, use spec
terminology when referring to the constraint, and print the
constraint in full:
S (type func()) does not satisfy ~[]E
There's more we can do, but this is better than what we had.
For #60542.
Change-Id: I033369fa0dfc475f0ec0da0582e8cbefb109f3cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/499639
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Change-Id: I975b437240df03da84f2ce7c47f7a0097a597f25
Reviewed-on: https://go-review.googlesource.com/c/go/+/499638
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
For #51676.
For #58645.
Change-Id: I9045051b5a25c6dfc833eef13e6c105a0d8ae763
Reviewed-on: https://go-review.googlesource.com/c/go/+/499716
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Since log/slog doesn't appear in earlier Go versions, we don't need
to document these proposals as changes.
Change-Id: Iae6ed9ca6bd22d8c46c21deece9ddedf7d739032
Reviewed-on: https://go-review.googlesource.com/c/go/+/498272
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
TryBot-Bypass: Jonathan Amsterdam <jba@google.com>
This reverts CL 467515. Now that we have cmp.Compare,
we don't need math.Compare or math.Compare32 after all.
For #56491Fixes#60519
Change-Id: I8ed33464adfc6d69bd6b328edb26aa2ee3d234d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/499416
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eli Bendersky <eliben@google.com>
This can be treated identically to R_PPC64_REL24_NOTOC as stubs
are generated based on GOPPC64 and -buildmode.
Change-Id: I3c42a9bf3c08d107fb656e6bf59b2307783bd9af
Reviewed-on: https://go-review.googlesource.com/c/go/+/497915
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Surprisingly, it usually survived the call to flush a write
barrier. Usually.
Fixes#60368
Change-Id: I4792a57738e5829c79baebae4d13b62abe9526b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/499679
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
For #48621
For #55079
Change-Id: I279b4fbf07d2fa9de9577559a4e17a57f5692aa3
Reviewed-on: https://go-review.googlesource.com/c/go/+/499618
Reviewed-by: Eli Bendersky <eliben@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
For #53685
Change-Id: I237297d19afeb36ad738074d0c61caa7012f65ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/499617
Reviewed-by: Eli Bendersky <eliben@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
For #55107
For #56887
For #56892
Change-Id: Ibcca34c931ed3595d877c4573bba221dec66bb5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/499616
Reviewed-by: Eli Bendersky <eliben@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
For #47653
Change-Id: Id44c9dba58966f43f188030a53343d890a6ffde7
Reviewed-on: https://go-review.googlesource.com/c/go/+/499419
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
For #57803
Change-Id: I8e33f4dd3fc3071bfbf4d2848faefbe8488f5742
Reviewed-on: https://go-review.googlesource.com/c/go/+/499418
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
For #53747
Change-Id: Ia5e2f89c1184f2dfd6d672b838b0dbb579e6c954
Reviewed-on: https://go-review.googlesource.com/c/go/+/499417
Reviewed-by: Eli Bendersky <eliben@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Also document the new String methods that call them.
For #54451
Change-Id: I5cd7e0fc6c84097bba6d29c4d6012ed3c8bb1e0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/499177
Reviewed-by: Eli Bendersky <eliben@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
For #56986
For #59033
Change-Id: I7d03fe34d418aff97a551b236b5d43506e402871
Reviewed-on: https://go-review.googlesource.com/c/go/+/499415
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Currently the BenchmarkSetType* benchmarks are racy: they call
heapBitsSetType on an allocation that might be in a span in-use for
allocation on another P. Because heap bits are bits but are written
byte-wise non-atomically (because a P assumes it has total ownership of
a span's bits), two threads can race writing the same heap bitmap byte
creating incorrect metadata.
Fix this by forcing every value we're writing heap bits for into a large
object. Large object spans will never be written to concurrently unless
they're freed first.
Also, while we're here, refactor the benchmarks a bit. Use generics to
eliminate the reflect nastiness in gc_test.go, and pass b.ResetTimer
down into the test to get slightly more accurate results.
Fixes#60050.
Change-Id: Ib7d6249b321963367c8c8ca88385386c8ae9af1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/497215
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL is a no-op, just adding the new options and plumbing it through.
'go get' will use this option to let commitRequirements know whether
toolchain was mentioned explicitly on the command line.
For #57001.
Change-Id: Iee7145f3335e899704df3e98fb840f1aa4063b0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/499555
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Slight cleanup of the special case for "mod tidy" during modload
of a module with no go version. Now it's clearer what is special.
For #57001.
Change-Id: I4a3ad0a948ccb5c62365f2a7f7f7de5582cc57c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/499535
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
This happens mainly during testing because the virtual
toolchain switch is not terribly robust, and if you accidentally
try to exec "1.23" instead of "go1.23" it will let you, but it
won't work right.
Of course, although we feel pretty good about the non-test
implementation, perhaps it has a toolchain switch loop lurking too,
or perhaps one will be introduced in the future.
To handle the test bug, and just in case we have a real bug later,
add detection of toolchain switch loops with clear messages.
Also fixes a bug in setting the -lang flag properly when invoking
the Go compiler: this is the first test using 'go 1.21.x' lines
during a build.
For #57001.
Change-Id: I0ece3dd718596689a23b677cf08ddf32ea97bc57
Reviewed-on: https://go-review.googlesource.com/c/go/+/498436
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test was introduced as a regression test for #60276. However, it
was quite flaky on a number of different platforms because there are
myriad ways the runtime can eat into time one might expect is completely
idle.
This change re-enables the test, but makes it much more resilient.
Because the issue we're testing for is persistent, we now require 10
consecutive failures to count. Any single success counts as a test
success. This change also makes the test's idle time bound more lenient,
allowing for a little bit of time to be eaten up. The regression we're
testing for results in nearly zero idle time being accounted for.
If this is still not good enough to eliminate flakes, this test should
just be deleted.
For #60276.
Fixes#60376.
Change-Id: Icd81f0c9970821b7f386f6d27c8a566fee4d0ff7
Reviewed-on: https://go-review.googlesource.com/c/go/+/498274
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
NewerToolchain needs a list of candidate toolchains.
Currently it always consults the module version list, using the network.
When GOTOOLCHAIN=path, it should probably not do this,
both because =path implies we don't want to use the network
and because not every released version will be in $PATH.
Instead, scan $PATH to find the available versions.
For #57001.
Change-Id: I478612c88d1504704a3f53fcfc73d8d4eedae493
Reviewed-on: https://go-review.googlesource.com/c/go/+/499296
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
While here, I've removed the CL 472195 TODO, which I marked as
RELNOTE=yes by mistake.
For #57441
For #57302
Change-Id: I7563140bf307f8d732f0154d02b8fa0735527323
Reviewed-on: https://go-review.googlesource.com/c/go/+/499515
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
This patch fixes a problem with the way pods (clumps of related
coverage meta+counter data files) are collected, which was causing
problems for "go tool covdata subtract".
A subtract operation such as "go tool covdata subtract -i=dir1,dir2
-o=out" works by loading in all the counter data files from "dir1"
before any of the data files from "dir2" are loaded. The sorting
function in the pods code was sorting counter files for a given pod
based purely on name, which meant that differences in process ID
assignment could result in some files from "dir2" being presented
before "dir1". The fix is to change the sorting compare function to
prefer origin directory over filename.
Fixes#60526.
Change-Id: I2226ea675fc99666a9a28e6550d823bcdf2d6977
Reviewed-on: https://go-review.googlesource.com/c/go/+/499317
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
For #57411
Change-Id: I56c112bb03dde24c2e2643c9b72ce06158a8e717
Reviewed-on: https://go-review.googlesource.com/c/go/+/499278
TryBot-Bypass: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Change-Id: I98bdfe8ab338a5b92c466a5aacfa95266171e5c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/499279
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Bypass: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: Ieedddf52ae09cf5a8e9347f0f30aff21e8369787
Reviewed-on: https://go-review.googlesource.com/c/go/+/499281
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Bypass: Keith Randall <khr@golang.org>
This change defines two unification modes used to control unification:
- assign set when unifying types involved in an assignment
- exact if set, types unify if they can be made identical
Currently, unification is inexact: when a defined type is compared
against a type literal, the underlying type of the defined type is
considered. When channel types are compared, the channel direction
is ignored. And when defined types are compared where one (or both)
are interfaces, interface unification is used.
By contrast, exact unification requires types to match exactly:
if they can be unified, the types must be identical (with suitable
type arguments).
Exact unification is required when comparing component types.
For instance, when unifying func(x P) with func(x Q), the two
signatures unify only if P is identical to Q per Go's assignment
rules.
Until now we have ignored exact unification and made due with inexact
unification everywhere, even for component types. In some cases this
led to infinite recursions in the unifier, which we guarded against
with a depth limit (and unification failure).
Go's assignmemt rules allow inexact matching at the top-level but
require exact matching for element types.
This change passes 'assign' to the unifier when unifying parameter
against argument types because those follow assignment rules.
When comparing constraints, inexact unification is used as before.
In 'assign' mode, when comparing element types, the unifyier is
called recursively, this time with the 'exact' mode set, causing
element types to be compared exactly. If unification succeeds for
element types, they are identical (with suitable type arguments).
This change fixes#60460. It also fixes a bug in the test for
issue #60377. We also don't need to rely anymore on the recursion
depth limit (a temporary fix) for #59740. Finally, because we use
exact unification when comparing element types which are channels,
errors caused by assignment failures (due to inexact inference which
succeeded when it shouldn't have) now produce the correct inference
error.
Fixes#60460.
For #60377.
For #59740.
Change-Id: Icb6a9b4dbd34294f99328a06d52135cb499cab85
Reviewed-on: https://go-review.googlesource.com/c/go/+/498895
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Pass a mode parameter through all unifier calls but make no use of it.
When unifying type elements (components of composite types), use emode,
which currently is set to mode.
Preparatory step to fix#60460. Factoring out this mechanical change
will make the actual fix smaller and easier to review and understand.
Because this change doesn't affect the behavior of the unifier, it is
safe.
For #60460.
Change-Id: I5b67499d93025be2128c14cc00bcc3b8cc9f44b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/498955
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
With the introduction of runtime.Pinner, we need to update the cgo
pointer passing rules to accomodate the new functionality. These rule
changes are easier to describe if the rest of the pointer passing rules
are described in terms of pinning as well (Go memory is implicitly
pinned when a pointer to it is passed to a C function, and implicitly
unpinned when that function returns).
For #46787.
Change-Id: I263f03412bc9165f19c9ada72fb005ed0483a8ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/498116
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Fix a broken HTML tag.
Change-Id: I9e7c65c2cc12c7b14ca205f78b78ac1e9c92a3ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/499355
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The design doc says 'toolchain' lines apply even if the default
toolchain is older than the one specified in the toolchain line.
However, that leads to various confusing behavior and security issues.
Instead, treat toolchain as a min go version that only applies
in the current module (not in dependencies).
As an example of confusing behavior / security issue, if I install
Go 1.30 and then run 'go build' in a module I've checked out,
I expect to use Go 1.30 or newer, not to silently use an older toolchain
that may have security problems fixed in Go 1.30.
Making toolchain a min establishes that guarantee.
Also clean up the tests quite a bit.
Finally drop + from the acceptable version suffixes; we use + for +auto and +path.
For #57001.
Change-Id: Ia92c66be75d6d0e31cb4e2c0aa936fa4ec5c0a8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/498260
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
If we run 'go get go@1.40' or 'go get m@v' where m has a go.mod
that says 'go 1.40', we need to write a new go.mod that says 'go 1.40'.
But we can't be sure we know how to write a Go 1.40-compatible go.mod.
Instead, download the latest point release of Go 1.40 and invoke it to
finish the get command.
For #57001.
Change-Id: I4133fc3c2ecf91226a6c09a3086275ecc517e223
Reviewed-on: https://go-review.googlesource.com/c/go/+/498118
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
This patch reverts a portion of the changes in CL 443715, specifically
the code in initorder that treats coverage counter variables as special
with respect to init order. The special casing is no longer needed
now after a change to the way coverage instrumention is done (the go and
cover cmds now make sure that coverage variables appear first in
the compilation order).
Updates #56293.
Change-Id: Idf803ff4c1a095e88d455a6adcd63991687eb288
Reviewed-on: https://go-review.googlesource.com/c/go/+/499216
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This patch contains a revised fix for issue #56293, switching to a
scheme in which coverage counter variables and meta-data variables are
written to a separate output file as opposed to being tacked onto the
end of an existing rewritten source file.
The advantage of writing counter vars to a separate file is that the
Go command can then present that file as the first source file to the
compiler when the package is built; this will ensure that counter
variable are treated as lexically "before" any other variable that
might call an instrumented function as part of its initializer.
Updates #56293.
Change-Id: Iccb8a6532b976d36ccbd5a2a339882d1f5d19477
Reviewed-on: https://go-review.googlesource.com/c/go/+/499215
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Also mention errors that implement it.
For #41198
Change-Id: I4f01b112f53b19e2494b701bb012cb2cb52f8962
Reviewed-on: https://go-review.googlesource.com/c/go/+/498775
Reviewed-by: Eli Bendersky <eliben@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
For #57436
Change-Id: I99e8b0819c76f1ccf12154a894c9c4c9d68124d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/498602
Reviewed-by: Eli Bendersky <eliben@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
For #56539
For #59166
Change-Id: Ief392464916a1a74a8fcc6c3c7bdb213e8c6ef98
Reviewed-on: https://go-review.googlesource.com/c/go/+/498601
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Before CL 471595, modload.readModGraph in module with graph pruning
enabled only ever chased down transitive dependencies of unpruned
roots, so pruned dependencies couldn't cause cycles and we didn't
need to dedup them in the loading queue.
However, in 'go get' we are now passing in a set of upgraded modules
to unprune, and those upgraded modules can potentially contain cycles,
leading to an infinite loop during loading.
We have two options for a fix: we could either drop the 'unprune'
check in the enqueue operation (and instead expand the 'unprune'
requirements in a separate pass, as we do in workspace mode), or we
could check for cycles for all modules (not just the ones that are
naturally unpruned). The latter option makes it clearer that this
process must terminate, so we choose that.
(It may be possible to clean up and simplify the workspace-mode case
now that we are passing in the 'unprune' map, but for now we're
looking for a minimal fix for the Go 1.21 release.)
Fixes#60490.
Change-Id: I701f5d43a35e357f6c0c0c9d10b7aa088f917311
Reviewed-on: https://go-review.googlesource.com/c/go/+/499195
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
