'go mod tidy' and 'go mod vendor' normally report errors when a
package can't be imported, even if the import appears in a file that
wouldn't be compiled by the current version of Go. These errors are
common for packages introduced in higher versions of Go, like "embed"
in 1.16.
This change causes 'go mod tidy' and 'go mod vendor' to ignore
missing package errors if the import path appears to come from the
standard library because it lacks a dot in the first path element.
Fixes#44557
Updates #27063
Change-Id: I61d6443e77ab95fd8c0d1514f57ef4c8885a77cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/298749
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The new error message tells the user what was wrong (no go.mod found)
and directs them to 'go help modules', which links to tutorials.
Fixes#44745
Change-Id: I98f31fec4a8757eb1792b45491519da4c552cb0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/298650
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
types2 uses the syntax printer to print expressions (for tracing
or error messages), so we need to (at least) print type lists in
interfaces.
While at it, also implement the printing of type parameter lists.
Fixes#44766.
Change-Id: I36a4a7152d9bef7251af264b5c7890aca88d8dc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/298549
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
It is not multithreaded-compilation-safe, and also seems
to cause problems on the noopt-builder.
Change-Id: I52dbcd507d256990f1ec7c8040ec7b76595aae4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/298850
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Added a test that exercises named results
Change-Id: Ie228b68f4f846266595a95e0f65a6e4b8bf79635
Reviewed-on: https://go-review.googlesource.com/c/go/+/297029
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
It turns out that the proc thread update function doesn't actually
allocate new memory for its arguments and instead just copies the
pointer values into the preallocated memory. Since we were allocating
that memory as []byte, the garbage collector didn't scan it for pointers
to Go allocations and freed them. We _could_ fix this by requiring that
all users of this use runtime.KeepAlive for everything they pass to the
update function, but that seems harder than necessary. Instead, we can
just do the allocation as []unsafe.Pointer, which means the GC can
operate as intended and not free these from beneath our feet. In order
to ensure this remains true, we also add a test for this.
Fixes#44662.
Change-Id: Ib392ba8ceacacec94b11379919c8179841cba29f
Reviewed-on: https://go-review.googlesource.com/c/go/+/297389
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
at least for ints and strings
includes simple test
For #40724.
Change-Id: Ib8484e5b957b08f961574a67cfd93d3d26551558
Reviewed-on: https://go-review.googlesource.com/c/go/+/295309
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This is a preparatory patch to support 6 arg opcodes on POWER10,
and simplify 5 arg opcode processing (e.g RLWNM and similar).
This expands the optab structure, and renames a4 arguments to a6.
No actual change in functionality is made.
Change-Id: I785e4177778e4bf1326cf8e46e8aeaaa0e4d406b
Reviewed-on: https://go-review.googlesource.com/c/go/+/295031
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Carlos Eduardo Seo <carlos.seo@linaro.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Keith Randall <khr@golang.org>
This test verifies the behavior of a test that fails due to timing
out. However, the test to be timed out was only sleeping for 1s before
returning successfully. That is empirically not always long enough for
the test process itself to detect the timeout and terminate.
We could replace the sleep with a select{}, but that would assume that
the deadlock detector does not terminate a test that reaches that
state (true today, but not necessarily so).
We could replace the arbitrarily sleep with an arbitrarily longer
sleep, but that's, well, arbitrary.
Instead, have the test sleep in an unbounded loop to ensure that it
always continues to run until the timeout is detected, and check the
test output to ensure that it actually reached the timeout path.
Fixes#32983
Change-Id: Ie7f210b36ef0cc0a4db473f780e15a3d6def8bda
Reviewed-on: https://go-review.googlesource.com/c/go/+/289889
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Noticed while debugging failing tests for #36460.
Fixes#44788
Change-Id: Ic2cf511d871b29284f7372920f6f7d452825dd63
Reviewed-on: https://go-review.googlesource.com/c/go/+/298651
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: Ib44729ffb5d4d7b84114dcf028b7e0418c9d5035
GitHub-Last-Rev: 13f59a650a
GitHub-Pull-Request: golang/go#42434
Reviewed-on: https://go-review.googlesource.com/c/go/+/268021
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Martin Möhrmann <moehrmann@google.com>
Verified with test and with single step watching changes to register
values across morestack calls, after reload.
Also added stack-growth test with pointer parameters of varying lifetime.
For #40724.
Change-Id: Idb5fe27786ac5c6665a734d41e68d3d39de2f4da
Reviewed-on: https://go-review.googlesource.com/c/go/+/294429
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Morestack works for non-pointer register parameters
Within a function body, pointer-typed parameters are correctly
tracked.
Results still not hooked up.
For #40724.
Change-Id: Icaee0b51d0da54af983662d945d939b756088746
Reviewed-on: https://go-review.googlesource.com/c/go/+/294410
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Otherwise, if -d=panic was set, check2 will treat already reported
error as internal compiler error.
For #43311Fixes#44445
Change-Id: I5dbe06334666df21d9107396b9dcfdd905aa1e44
Reviewed-on: https://go-review.googlesource.com/c/go/+/294850
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
After CL 272654, the compiler now use go/constant.Value to represent
constant nodes. That makes ir.ConstantValue requires node type to
correctly return value for untyped int node. But untyped int node can
have nil type after typechecked, e.g: using int value as key for
map[string]int, that makes the compiler crashes.
To fix it, just don't add the invalid key to constSet, since when
it's not important to report duplicated keys when they aren't valid.
For #43311Fixes#44432
Change-Id: I44d8f2b95f5cb339e77e8a705a94bcb16e62beb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/294034
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
That's an invalid operation and depend on gc.hidePanic to report error.
Updates #43311
Change-Id: Ib0761dcf4d9d2a23c41de7eff0376677a90b942e
Reviewed-on: https://go-review.googlesource.com/c/go/+/294033
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
While at it, also remove checkassignlist, which is not used.
For #43311
Change-Id: Ie7ed81f68080d8881fca6035da64a9755f2cb555
Reviewed-on: https://go-review.googlesource.com/c/go/+/294032
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
That's an invalid operation and depend on gc.hidePanic to report error.
Updates #43311
Change-Id: I78d615c40ab1e7887f612491e215c1c2bb758ef6
Reviewed-on: https://go-review.googlesource.com/c/go/+/294031
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When syntax.Parse returns error, noder.file will be nil. Currently, we
continue accessing it regardlessly and depend on gc.hidePanic to hide
the panic from user.
Instead, we should gracefully handle the error in LoadPackage, then exit
earlier if any error occurred.
Updates #43311
Change-Id: I0a108ef360bd4f0cc9f481071b8967355e1513af
Reviewed-on: https://go-review.googlesource.com/c/go/+/294030
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
still needs morestack
still needs results
lots of corner cases also not dealt with.
For #40724.
Change-Id: I03abdf1e8363d75c52969560b427e488a48cd37a
Reviewed-on: https://go-review.googlesource.com/c/go/+/293889
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Additional register-parameter plumbing, not all the way to the end;
if you test register parameter-passing, it fails mid-compilation.
For #40724.
Change-Id: Ibb675022c9156779a451726329890e52fca1cb33
Reviewed-on: https://go-review.googlesource.com/c/go/+/293398
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Moved all "target" information into "storeRC"; it was a register
cursor, now it is a register cursor that also carries the store
target with it if there are no registers. Also allows booby-trapping
to ensure that the target is unambiguously one or the other.
For #40724.
Change-Id: I53ba4b91679e5fcc89c63b7d31225135299c6ec6
Reviewed-on: https://go-review.googlesource.com/c/go/+/293397
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The argument class check in addpool is unnecessary, remove it so that we don't
need to list all the compatiable classes.
Change-Id: I36f6594db35e25db22fe898273e024c2db4cb771
Reviewed-on: https://go-review.googlesource.com/c/go/+/283492
Trust: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Arm64 doesn't have scaled register format, such as (R1*2), (R1)(R2*3),
but currently the assembler doesn't report an error for such kind of
instruction operand format. This CL disables the scaled register
operand format for arm64 and reports an error if this kind of instruction
format is seen.
With this CL, the assembler won't print (R1)(R2) as (R1)(R2*1), so that
we can make the assembly test simpler.
Change-Id: I6d7569065597215be4c767032a63648d2ad16fed
Reviewed-on: https://go-review.googlesource.com/c/go/+/289589
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently any variable that is spilled onto the stack will occupy at least 8 bytes,
because the stack offset is required to be aligned with 8 bytes on linux/arm64.
This CL removes this constraint by aligning the stack slot with its actual size.
Updates #42385
Change-Id: Icbd63dc70cd19852802e43f134355f19ba7e1e29
Reviewed-on: https://go-review.googlesource.com/c/go/+/267999
Trust: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Constant of BITCON type can be moved into RSP by MOVD or MOVW instructions
directly, this CL enables this format of these two instructions.
For 32-bit ADDWop instructions with constant, rewrite the high 32-bit
to be a repetition of the low 32-bit, just as ANDWop instructions do,
so that we can optimize ADDW $bitcon, Rn, Rt as:
MOVW $bitcon, Rtmp
ADDW Rtmp, Rn, Rt
The original code is:
MOVZ $bitcon_low, Rtmp
MOVK $bitcon_high,Rtmp
ADDW Rtmp, Rn, Rt
Change-Id: I30e71972bcfd6470a8b6e6ffbacaee79d523805a
Reviewed-on: https://go-review.googlesource.com/c/go/+/289649
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL adds support for arm64 fp&simd instructions VUMAX and VUMIN.
Fixes#42326
Change-Id: I3757ba165dc31ce1ce70f3b06a9e5b94c14d2ab9
Reviewed-on: https://go-review.googlesource.com/c/go/+/271497
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL adds assembly support for 128-bit FLDPQ and FSTPQ instructions.
This CL also deletes some wrong pre/post-indexed LDP and STP instructions,
such as {ALDP, C_UAUTO4K, C_NONE, C_NONE, C_PAIR, 74, 8, REGSP, 0, C_XPRE},
because when the offset type is C_UAUTO4K, pre and post don't work.
Change-Id: Ifd901d4440eb06eb9e86c9dd17518749fdf32848
Reviewed-on: https://go-review.googlesource.com/c/go/+/273668
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This is a direct port of CL 298129 to go/types.
Fixes#44688
Change-Id: I950992ea7beea5b9c8bea0c296b5ce03b2aa9b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/298349
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Methods of generic types are instantiated lazily (upon use). Thus,
when we encounter a method of such a type, we need to instantiate
the method signature with the receiver type arguments. We infer
those type arguments from the method receiver. If the method is
embedded, we must use the actual embedded receiver type, otherwise
the receiver type declared with the method doesn't match up and
inference will fail.
(Note that there's no type inference in the source code here, it's
only the implementation which uses the existing inference mechanism
to easily identify the actual type arguments. If the implementation
is correct, the inference will always succeed.)
Updates #44688.
Change-Id: Ie35b62bebaeaf42037f2ca00cf8bd34fec2ddd9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/298129
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This fix uses mutex around the problematic store and subsequent access;
if this causes performance problems later a better fix is to do all the
ABI binding in gc/walk where it is single-threaded.
Change-Id: I488f28ab75beb8351c856fd50b0095cab463642e
Reviewed-on: https://go-review.googlesource.com/c/go/+/298109
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Also handles case where OpArg does not escape but has its address
taken.
May have exposed a lurking bug in 1.16 expandCalls,
if e.g., loading len(someArrayOfstructThing[0].secondStringField)
from a local. Maybe.
For #40724.
Change-Id: I0298c4ad5d652b5e3d7ed6a62095d59e2d8819c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/293396
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The 32 bit versions are easily implement with a single instruction, while the
8 bit versions require a bit more effort but use the same atomic instructions
via rewrite rules.
Change-Id: I42e8d457b239c8f75e39a8e282fc88c1bb292a99
Reviewed-on: https://go-review.googlesource.com/c/go/+/268098
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This allows the use of CLONE_VFORK and CLONE_VM for fork/exec, preventing
'fork/exec ...: cannot allocate memory' failures from occuring when attempting
to execute commands from a Go process that has a large memory footprint.
Additionally, this should reduce the latency of fork/exec on these platforms.
Fixes#31936
Change-Id: I4e28cf0763173145cacaa5340680dca9ff449305
Reviewed-on: https://go-review.googlesource.com/c/go/+/295849
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
in progress; doesn't fully work until they are also passed on
register on the caller side.
For #40724.
Change-Id: I29a6680e60bdbe9d132782530214f2a2b51fb8f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/293394
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Change-Id: Ib82e1c8c549c91e20c5aff5e50736617c6831f8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/277792
Run-TryBot: Baokun Lee <bk@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
This CL applies CL 267999 to mips64.
Updates #42385
Change-Id: Ideab21be0d8c1a36b3be7411b24adac70a3d16e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/297771
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
types thought it knew how to do this, but that's a lie, because types
doesn't know what the ABI is.
includes extra checking to help prevent things from accidentally working
if they need to be changed but aren't.
For #40724.
Change-Id: I166cd948f262344b7bebde6a2c25e7a7f878bbfb
Reviewed-on: https://go-review.googlesource.com/c/go/+/293393
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
About one run out of 3 it fails on my laptop, and
I am tired of having to be a nanny for my tests just
because of this one flaky test. This has been a problem
for months.
Updates #32218.
Change-Id: I2871d4c6f47e9432d189ed7bdcda8f9c0871cfc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/297469
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If we don't actually require the listed module, we previously
implicitly resolved "latest", but also (erroneously) forgot to apply
exclusions and retractions for it. But there is really no need to
resolve "latest" in this case at all — now we omit the version from
the reported module info entirely.
Fixes#44296
Change-Id: Id595f52f597c7213bd65b73bf066a678d9e1d694
Reviewed-on: https://go-review.googlesource.com/c/go/+/297150
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
For #44296
Change-Id: I310f99ccd406622e39f3fbfa12f7a3bee39602db
Reviewed-on: https://go-review.googlesource.com/c/go/+/297149
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
In CL 251159, I removed a hard-coded special case changing the
rewriting behavior for std dependencies in GOROOT/src/vendor and
GOROOT/src/cmd/vendor. Unfortunately, that caused packages in 'std' to
be reported as stale when run within GOROOT/src.
This change restores the special-case behavior, but plumbs it through
the PackageOpts explicitly instead of comparing strings stored in
global variables.
Fixes#44725
Change-Id: If084fe74972ce1704715ca79b0b7e092dd90c88b
Reviewed-on: https://go-review.googlesource.com/c/go/+/297869
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Previously, mvs.Downgrade could introduce spurious dependencies if the
downgrade computed for one module lands on a “hidden” version (such as
a pseudo-version) due to a requirement introduced by the downgrade for
another module.
To eliminate those spurious dependencies, we can add one more call to
BuildList to recompute the “actual” downgraded versions, and then
including only those actual versions in the final call to BuildList.
For #36460
Change-Id: Icc6b54aa004907221b2bcbbae74598b0e4100776
Reviewed-on: https://go-review.googlesource.com/c/go/+/294294
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
...and run commands from there.
This removes the requirement that bootstrap must not run inside a module
by ensuring that enclosing modules do not interfere with bootstrap.
Fixes#44209.
Change-Id: I700a81829226770b8160c8ff04127b855b6e26bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/296610
Trust: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
