Similar to CL 456556 but for ppc64 instead of arm64.
Change docs about how booleans are stored in registers for ppc64.
We now don't promise to keep the upper bits zeroed; they might be junk.
To test, I changed the boolean generation instructions (MOVBZload* and ISEL*
with boolean type) to OR in 0x100 to the result. all.bash still passed,
so I think nothing else is depending on the upper bits of booleans.
Update #57184
Change-Id: Ie66f8934a0dafa34d0a8c2a37324868d959a852c
Reviewed-on: https://go-review.googlesource.com/c/go/+/456437
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: KAMPANAT THUMWONG (KONG PC) <1992kongpc.kth@gmail.com>
Run-TryBot: Archana Ravindar <aravind5@in.ibm.com>
Tested by temporarily changing sysdir to use a directory where
the expected files were all symlinks. We should consider using
a different approach that doesn't rely on sysdir, but for now
do a minimal fix.
Fixes#57210
Change-Id: Ifb1becef03e014ceb48290ce13527b3e103c0e07
Reviewed-on: https://go-review.googlesource.com/c/go/+/456557
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
ARM64 maintains booleans in the low byte of registers. Upper parts
of that register are junk.
This rule is using all 32 bits of a boolean-containing register, which
is wrong. Change the rule to only look at the low bit.
Fixes#57184
Change-Id: Ibbef86b2be859df3d06d993db00e1231c481c428
Reviewed-on: https://go-review.googlesource.com/c/go/+/456556
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
In the wrappers for getgrnam_r and similar, the structs to be returned
are allocated on the C stack and may be uninitialized. If the call to
the wrapped C function returns an error (such as ERANGE), it may leave
the struct uninitialized, expecting that the caller will not read it.
However, when that struct is returned to Go, it may be read by the Go
garbage collector. If the uninitialized struct fields happen to
contain wild pointers, the Go garbage collector will throw an error.
(Prior to CL 449335, the Go runtime would not scan the struct fields
because they did not reside in Go memory.)
Fix this by always zeroing the struct before the C call.
Fixes#57170.
Change-Id: I241ae8e4added6f9a406dac37a7f6452341aa0cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/456121
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Type inference uses a trick of "renaming" type parameters in the type
parameter list to avoid cycles during unification. This separates the
identity of type parameters from type arguments. When this trick was
introduced in CL 385494, we restricted its application to scenarios
where inference is truly self-recursive: the type parameter list being
inferred was the same as the type parameter list of the outer function
declaration. Unfortunately, the heuristic used to determine
self-recursiveness was flawed: type-checking function literals clobbers
the type-checker environment, losing information about the outer
signature.
We could fix this by introducing yet more state into the type-checker
(e.g. a 'declSig' field that would hold the signature of the active
function declaration), but it is simpler to just avoid this optimization
and always perform type parameter renaming. We can always optimize
later.
This CL removes the check for true self-recursion, always performing the
renaming.
Fixesgolang/go#57155
Change-Id: I34c7617005c1f0ccfe2192da0e5ed104be6b92c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/456236
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The -v flag value is "test2json", not "json", since it emits output
in a custom format that the cmd/test2json tool interprets.
The cmd/test2json documentation and implementation have this right.
For #54202.
Change-Id: I2b52861d926e14488aa9fc89fff8c26da32ca710
Reviewed-on: https://go-review.googlesource.com/c/go/+/456124
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Fix a buglet in cmd/cover in how we handle package name/path for the
"go build -o foo.exe *.go" and "go run *.go" cases.
The go command assigns a dummy import path of "command-line-arguments"
to the main package built in these cases; rather than expose this
dummy to the user in coverage reports, the cover tool had a special
case hack intended to rewrite such package paths to "main". The hack
was too general, however, and was rewriting the import path of all
packages with (p.name == "main") to an import path of "main". The hack
also produced unexpected results for cases such as
go test -cover foo.go foo_test.go
This patch removes the hack entirely, leaving the package path for
such cases as "command-line-arguments".
Fixes#57169.
Change-Id: Ib6071db5e3485da3b8c26e16ef57f6fa1712402c
Reviewed-on: https://go-review.googlesource.com/c/go/+/456237
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
These short timeouts can overrun due to system scheduling delay
(or GC latency) on a slow or heavily-loaded host.
Moreover, if the test deadlocks we will probably want to know what the
GC goroutines were doing at the time. With an arbitrary timeout, we
never get that information; however, if we allow the test to time out
completely we will get a goroutine dump (and, if GOTRACEBACK is
configured in the environment, that may even include GC goroutines).
Fixes#57166.
Change-Id: I136501883373c3ce4e250dc8340c60876b375f44
Reviewed-on: https://go-review.googlesource.com/c/go/+/456118
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
- Start handling signals in 'go test' just before starting the test
subprocess instead of just after. (It is unlikely that starting the
process will cause cmd/go to hang in a way that requires signals to
debug, and it is possible that something the test does — such as
sending os.Interrupt to its parent processes — will immediately
send a signal that needs to be handled.)
- In the test-test, don't try to re-parse the parent PIDs after
sending signals, and sleep for a much shorter time interval.
(Overrunning the sleep caused the next call to strconv.Atoi — which
shouldn't even happen! — to fail with a parse error, leading to the
failure mode observed in
https://build.golang.org/log/f0982dcfc6a362f9c737eec3e7072dcc7ef29e32.)
Fixes#56083.
Updates #53563.
Change-Id: I346a95bdda5619632659ea854f98a9e17a6aede7
Reviewed-on: https://go-review.googlesource.com/c/go/+/456115
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
The getpwuid_r function is expected to return ERANGE on overflow.
Accept -1 on AIX as we see that in practice.
This problem was uncovered by, but not caused by, CL 455815,
which introduced a test that forced a buffer overflow.
Change-Id: I3ae94faf1257d2c73299b1478e49769bb807fc4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/456075
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 455716 added TestFromFS. This test was failing on Plan 9
because fromFS didn't return an empty string in case of error.
This change fixes TestFromFS by returning an empty string
in case of error.
Fixes#57142.
Change-Id: Ie50dfba5e70154d641f762fa43f1c26c3d12b6f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/455835
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
Empirically, unread PTY output may be discarded on macOS when the
child process exits.
Fixes#57141.
Tested with 'go test cmd/go -run=TestTerminalPassthrough -count=1000'
on a darwin-amd64-12_0 gomote.
Change-Id: I11508e6429c61488f30e10d9ae0cc94fdf059257
Reviewed-on: https://go-review.googlesource.com/c/go/+/455915
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
This section is complete.
For #54202.
Change-Id: I304cc55a5b8ed53e8b8dff73a5feb5ef39207846
Reviewed-on: https://go-review.googlesource.com/c/go/+/455895
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add some basic material on the changes to code coverage testing
to the release notes.
For #54202.
Change-Id: I28200d43b4952ce8e8ecf46c8fe8e97c81d245e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/453857
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
getpwnam_r and friends return the errno as the result,
not in the global errno. The code changes in CL 449316
inadvertently started using the global errno.
So if a lookup didn't fit in the first buffer size,
it was treated as not found instead of growing the buffer.
Fixes#56942.
Change-Id: Ic5904fbeb31161bccd858e5adb987e919fb3e9d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/455815
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
CL 424854 changed the unified IR writer's handling of type
declarations to write the underlying type rather than the RHS type
expression's type. This in turn allows us to simplify the go/types
importer, because now there's no need to delay caling SetUnderlying.
Fixes#57015.
Change-Id: I80caa61f6cad5b7f9d829939db733a66cfca621c
Reviewed-on: https://go-review.googlesource.com/c/go/+/424876
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
[Re-land of CL 424854, which was reverted as CL 425214.]
When handling a type declaration like:
```
type B A
```
unified IR has been writing out that B's underlying type is A, rather
than the underlying type of A.
This is a bit awkward to implement and adds complexity to importers,
who need to handle resolving the underlying type themselves. But it
was necessary to handle when A was declared like:
```
//go:notinheap
type A int
```
Because we expected A's not-in-heap'ness to be conferred to B, which
required knowing that A was on the path from B to its actual
underlying type int.
However, since #46731 was accepted, we no longer need to support this
case. Instead we can write out B's actual underlying type.
One stumbling point though is the existing code for exporting
interfaces doesn't work for the underlying type of `comparable`, which
is now needed to implement `type C comparable`. As a bit of a hack, we
we instead export its underlying type as `interface{ comparable }`.
Fixes#54512.
Change-Id: I9aa087e0a277527003195ebc7f4fbba6922e788c
Reviewed-on: https://go-review.googlesource.com/c/go/+/455279
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Do not permit access to Windows reserved device names (NUL, COM1, etc.)
via os.DirFS and http.Dir filesystems.
Avoid escapes from os.DirFS(`\`) on Windows. DirFS would join the
the root to the relative path with a path separator, making
os.DirFS(`\`).Open(`/foo/bar`) open the path `\\foo\bar`, which is
a UNC name. Not only does this not open the intended file, but permits
reference to any file on the system rather than only files on the
current drive.
Make os.DirFS("") invalid, with all file access failing. Previously,
a root of "" was interpreted as "/", which is surprising and probably
unintentional.
Fixes CVE-2022-41720
Fixes#56694
Change-Id: I275b5fa391e6ad7404309ea98ccc97405942e0f0
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1663834
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/455362
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jenny Rakoczy <jenny@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/455716
Reviewed-by: Jenny Rakoczy <jenny@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Now that we have newer C compilers on the Windows builders, they
should fully support reproducible builds.
Updates #35006.
Change-Id: I0a8995fe327067c9e73e5578c385ea01ae5dee5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/454504
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
CL 454475 switched from checking CompressedSize to UncompressedSize
when determining if we should consider an archive malformed because
it contains data and added a test for an example of this (a JAR). We
should also remove the hasDataDescriptor check, since that is basically
an alias for CompressedSize > 0. The test didn't catch this because we
didn't actually attempt to read from the returned reader.
Change-Id: Ibc4c1aa9c3a733f3ebf4a956d1e2f8f4900a29cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/455523
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Julie Qiu <julieqiu@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
These environment variables affect cmd/dist, and in turn run.bash.
They exist primarily for the Go build system, but are still needed
sometimes when investigating problems. Document them in one place.
Fixes#46054.
Change-Id: I5dea2ac79b0d203d2f3c9ec2980382f62bead5cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/455517
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
It is possible that CL 455166 fixes this. Try unskipping the test
and see. If it fails again we can skip it again.
Fixes#48655.
Change-Id: Ia81b06cb7608f74adb276bc018e8fc840285bc11
Reviewed-on: https://go-review.googlesource.com/c/go/+/455358
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Pass -Wl,--no-insert-timestamp to the external linker on windows, so
as to suppress generation of the PE file header data/time stamp. This
is in order to make it possible to get reproducible CGO builds on
windows (note that we already zero the timestamp field in question for
internal linkage).
Updates #35006.
Change-Id: I3d69cf1fd32e099bd9bb4b0431a4c5f43e4b08f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/455535
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Provide file/line numbers for errors when we have them.
Make the assembler error text closer to the equivalent errors from the compiler.
Abort further processing when we come across errors.
Fixes#53994
Change-Id: I4d6a037d6d713c1329923fce4c1189b5609f3660
Reviewed-on: https://go-review.googlesource.com/c/go/+/455276
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We know the type argument against which constraint type inference fails:
print the type argument instead of the corresponding type parameter.
Fixes#57096.
Change-Id: Ia1da9c87fac6f8062e4d534b82e895fa4617fddc
Reviewed-on: https://go-review.googlesource.com/c/go/+/455278
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Put comments about what operations do per block of related opcodes
instead of on each line. This is less repetitive and lets us be a bit
more verbose in our descriptions.
Doesn't change the generated code at all.
Change-Id: I98fbd4029df6537b10aac2113a00df121d0fca1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/433736
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
In the profiler, when unwinding the stack, we have special
handling for VDSO calls. Currently, the special handling is only
used when the normal unwinding fails. If the signal lands in the
function that makes the VDSO call (e.g. nanotime1) and after the
stack switch, the normal unwinding doesn't fail but gets a stack
trace with exactly one frame (the nanotime1 frame). The stack
trace stops because of the stack switch. This 1-frame stack trace
is not as helpful. Instead, if vdsoSP is set, we know we are in
VDSO call or right before or after it, so use vdsoPC and vdsoSP
for unwinding. Do the same for libcall.
Also remove _TraceTrap for VDSO unwinding, as vdsoPC and vdsoSP
correspond to a call, not an interrupted instruction.
Fixes#56574.
Change-Id: I799aa7644d0c1e2715ab038a9eef49481dd3a7f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/455166
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
As with all the stuff that call cgo from net package.
Change-Id: I7c42ae44a1d47f4f949b203682217498fcdba92a
GitHub-Last-Rev: 70406493bb
GitHub-Pull-Request: golang/go#57043
Reviewed-on: https://go-review.googlesource.com/c/go/+/454697
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Pratt <mpratt@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: Ian Lance Taylor <iant@google.com>
This adds the nonPGO, non-coverage compiler changes
for the 1.20 release. There's not that much user
visible change.
For #54202.
Change-Id: Ib2964ed5f7e73bb89c720d09b868ab79682f5070
Reviewed-on: https://go-review.googlesource.com/c/go/+/454536
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: David Chase <drchase@google.com>
Without it, at least on ARM64 with older BFD linker, it will
include the file of the object file (which is of a temporary path)
as a debug symbol into the binary, causing the build to be
nondeterministic. Adding a .file directive makes it to create a
STT_FILE symbol with deterministic input, and prevent the linker
creating one using the temporary object file path.
Fixes#57035.
Change-Id: I3ab716b240f60f7a891af2f7e10b467df67d1f31
Reviewed-on: https://go-review.googlesource.com/c/go/+/454838
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Change-Id: I4cff6b2a1fed6acdf754539c3c53a61eaa3b3f84
Reviewed-on: https://go-review.googlesource.com/c/go/+/450176
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Pointed out in review of CL 453602,
but it looks like I forgot to re-upload before submitting.
Change-Id: I8f4fac52ea0f904f6f9b06e13fc8ed2e778f2360
Reviewed-on: https://go-review.googlesource.com/c/go/+/454835
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Julie Qiu <julieqiu@google.com>
This was a regression test added for a 'git' command line
used for build stamping. Unfortunately, 'gpg' has proved to
be extremely fragile:
* In recent versions, it appears to always require 'gpg-agent' to be
installed for anything involving secret keys, but for some reason is
not normally marked as requiring gpg-agent in Debian's package
manager.
* It tries to create a Unix domain socket in a subdirectory of $TMPDIR
without checking the path length, which fails when $TMPDIR is too
long to fit in the 'sun_path' field of a sockaddr_un struct (which
typically tops out somewhere between 92 and 108 bytes).
We could theoretically address those by artificially reducing the
script's TMPDIR length and checking for gpg-agent in addition to gpg,
but arguably those should both be fixed upstream instead. On balance,
the incremental value that this test provides does not seem worth the
complexity of dealing with such a fragile third-party tool.
Updates #50675.
Updates #48802.
Fixes#57034.
Change-Id: Ia3288c2f84f8db86ddfa139b4d1c0112d67079ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/454502
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
(Until it can be made hermetic.)
The gopkg.in service has had a lot of flakiness lately. Go users in
general are isolated from that flakiness by the Go module mirror
(proxy.golang.org), but this test intentionally bypasses the module
mirror because the mirror itself uses cmd/go to download the module.
In the long term, we can redirect the gopkg.in URL to the local
(in-process) vcweb server added for #27494.
In the meantime, let's skip the test to reduce the impact of upstream
outages.
For #54503.
Change-Id: Icf3de7ca416db548e53864a71776fe22b444fcea
Reviewed-on: https://go-review.googlesource.com/c/go/+/454503
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Historically, on Windows filepath.Join("c:", elt) does not insert
a path separator between "c:" and elt, but preserves leading slashes
in elt. Restore this behavior, which was inadvertently changed by
CL 444280.
Fixes#56988
Change-Id: Id728bf311f4093264f8c067d8b801ea9ebef5b5f
Reviewed-on: https://go-review.googlesource.com/c/go/+/453497
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
gcimporter.TestImportTypeparamTests still needs to create full export
data because it loads lots of source files from GOROOT/test that
expect to be able to import arbitrary subsets of the standard library,
so we now skip it in short mode.
On a clean build cache, this reduces
'go test -short cmd/compile/internal/importer go/internal/gcimporter'
on my machine from 21–28s per test to <6s per test.
Updates #56967.
Updates #47257.
Change-Id: I8fd80293ab135e0d2d213529b74e0ca6429cdfc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/454498
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
We're unlikely to get this package out of the door all that soon. For
now add a note that SetFallbackRoots will be most commonly used with
an TBA package, and link the tracking issue.
We could also just remove the "It will most commonly be used ..."
sentence.
Change-Id: Ie96134d757f5b4c69f1878d53c92b5ed602671e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/454056
Reviewed-by: Julie Qiu <julieqiu@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
