go mod download provides a way to force downloading
of a particular module version into the download cache
and also to locate its cached files.

Forcing downloads is useful for warming caches, such as
in base docker images.

Finding the cached files allows caching proxies to use
go mod download as the way to obtain module files
on cache miss.

Fixes #26577.
Fixes #26610.

Change-Id: Ib8065bcce07c9f5105868ec1d87887ef4871f07e
Reviewed-on: https://go-review.googlesource.com/128355
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Fixes golang/go#26372

Change-Id: I30716ba56f829c6e36ccd50471e118084bad7360
Reviewed-on: https://go-review.googlesource.com/128902Reviewed-by: Russ Cox <rsc@golang.org>

See the added comment for the reasoning behind the workaround.

Fixes #26868.

Change-Id: Idede020ec88a49595dc233d9a1346b12691186f4
Reviewed-on: https://go-review.googlesource.com/128815
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Recent versions of Delve pay attention to the debugging changes
for 1.11, which causes different (better!) debugging behavior.
Update the reference data to reflect this.

Change-Id: I2efa165aa71769ace9f7885b4ce3420cd9b2d3a3
Reviewed-on: https://go-review.googlesource.com/128697
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

No test because testing this would require building a new toolchain
with a different experiment.

Fixes #26883

Change-Id: Iadd513d0920ef12463006dd2a61e94370dd13f68
Reviewed-on: https://go-review.googlesource.com/128735
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates #26906.

Change-Id: I61b08180aefe9cfc109a1009ca251ee6970eb2df
Reviewed-on: https://go-review.googlesource.com/128879
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Updates #26904.

Change-Id: If7f381c3f3a41bd62c5f8bcf4f92720badcaf5c6
Reviewed-on: https://go-review.googlesource.com/128878Reviewed-by: Russ Cox <rsc@golang.org>

This change replaces https://golang.org/cl/125835.

Updates #26317.

Change-Id: I38ae1f93e5f5c86737a4b489df498c18b179781d
Reviewed-on: https://go-review.googlesource.com/128637Reviewed-by: Russ Cox <rsc@golang.org>

modload.Import contains a loop that looks for the module containing a package.
Because we overload Import to locate both packages and modules, that loop
contains a bunch of special-cases for modules with empty roots.

In this change, we factor out the loop into a new function (QueryPackage) and
use that directly in modget.getQuery. That restores the invariant that
the paths passed to modload.Import must be importable packages, and fixes 'go
get' lookups for packages that have moved between a module and submodules with
the same path prefix.

Updates #26602.

Change-Id: I8bc8340c17f2df062d03ce720f4dc18b2ba406b2
Reviewed-on: https://go-review.googlesource.com/128136Reviewed-by: Russ Cox <rsc@golang.org>

Previously, we reported errors directly in (*loader).load via base.Errorf.
Unfortunately, (*loader).load can be called from contexts in which such errors
should not be considered fatal, such as by load.PackagesAndErrors.

Instead, we save the errors in pkg.err and modify Lookup to return that error.

This change is a bit awkward: we end up suppressing a "no Go files" error for
packages at the root of newly-imported modules, even if they really do contain
source files. I believe that that's due to a special-case lookup for modules in
the build list, which allows us to "validate" imports for modules in the build
list even though we haven't actually downloaded their sources (or verified that
they actually contain the requested package). The fix for that issue is in the
change that follows this one.

Fixes #26602.

Change-Id: I16f00ceb143fbb797cfc3cb07fd08aeb6154575b
Reviewed-on: https://go-review.googlesource.com/127936
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

In my previous change, I didn't use the correct functions for continuing
to record type informations after errors. Change to using the correct
functions, and add a comment to clarify in expr.go.

Updates #22467

Change-Id: I66ebb636ceb2b994db652343430f0551db0050c3
Reviewed-on: https://go-review.googlesource.com/128835
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This test passes, but it encodes several behaviors that I think are bugs.
I suggest that we check it in as-is, and we can update it as the bugs are fixed.

Change-Id: Icb073de9cb13036dbccadb4ff2cb3169ffb56236
Reviewed-on: https://go-review.googlesource.com/128137
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I16d36c8e22c84a3266520d86e41ff71ef826ae70
Reviewed-on: https://go-review.googlesource.com/128555
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I45a675c5f699b23284a2a50b33cb22882f4b3b80
Reviewed-on: https://go-review.googlesource.com/128016Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #26713.

Tested with Git 2.7.4. Older Gits may or may not work.

Change-Id: Ib72d751388dfbb50030191ae40f788d1402834b2
Reviewed-on: https://go-review.googlesource.com/126956Reviewed-by: Russ Cox <rsc@golang.org>

In previous versions of Go including 1.10, an empty line would break the
alignment of elements within an expression list.

golang.org/cl/104755 changed the heuristic, with the side effect that
empty lines no longer broke the table alignment.

Reintroduce the behavior and add a regression test for it.

Fixes #26352.

Change-Id: I410bcff4cba25c7f8497d46bd7890a2c7ee11d46
Reviewed-on: https://go-review.googlesource.com/125260
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

One first round of low-hanging fruit, excluding anything unclear.

Also fixed a bug where, if a contributor had different emails under
different CLAs, only the first one was added to AUTHORS.

Updates #12042

Change-Id: Id7b06c885d74b4718ef2d74d149513a7c0f40c91
Reviewed-on: https://go-review.googlesource.com/126215Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

https://golang.org/pkg/bufio/#example_Scanner_custom is not directly
runnable in the playground via godoc, but if I copy+paste the code into
https://play.golang.org/ then it runs just fine.

This seems to be due to the blank identifier being considered unresolved
in the following line in the example:

_, err = strconv.ParseInt(string(token), 10, 32)

But that's the whole point of blank identifiers- they're not supposed
to be resolved.  So let's skip adding the blank identifier to
doc.playExample's unresolved map.

Fixes #26447

Change-Id: I52bc7d99be1d14a61dc012d10c18349d52ba4c51
GitHub-Last-Rev: 9172e9dc1378b0f37f96fc2e1ade4dda9d848398
GitHub-Pull-Request: golang/go#26448
Reviewed-on: https://go-review.googlesource.com/124775Reviewed-by: Robert Griesemer <gri@golang.org>

For contributors looking for new issues to contribute to it can be
difficult to find issues that need a fix and don't already have a fix
being considered. There are several labels that help guide the way
already, like `NeedsFix`, `HelpWanted`. But many issues with this label
will already have a CL. For new contributors this can be especially
difficult.

Fixes #26494

Change-Id: Ifd38ea65e362b4c580207a06f959646e49ac594f
GitHub-Last-Rev: 6d2b54447b2ee754a6d025f5de3ebd8326e035eb
GitHub-Pull-Request: golang/go#26516
Reviewed-on: https://go-review.googlesource.com/125355Reviewed-by: Andrew Bonventre <andybons@golang.org>
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Because methods are type-checked before the receiver base type
is "complete" (i.e., they are checked as part of the receiver
base type), situations occur where aliases of those base types
are used (in those methods) but the alias types are not known
yet (even though their base types are known).

This fix is a temporary work-around that looks syntactically
for the base types of alias types and uses those base types
when we refer to an "incomplete" alias type. The work-around
is completely localized and guarded with a flag so it can be
disabled at short notice.

The correct fix (slated for 1.12) is to decouple type-checking
of methods from their receiver base types. See issue #26854.

Fixes #26390.

Change-Id: I66cc9d834b220c254ac00e671a137cf8a3da59c1
Reviewed-on: https://go-review.googlesource.com/128435Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

Add my current personal email in both A+C, but keep old one too.
Add my @golang.org email to CONTRIBUTORS.

Change-Id: Idba258e465a8d657372dbeb6cb734744d493e5d4
Reviewed-on: https://go-review.googlesource.com/128416Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The old code used splice on a 2GB []byte when not in short mode, meaning
that running 'go test net' when one had 4GB or less free memory would
easily result in "out of memory" runtime panics.

Instead, use a much smaller size that is still big enough to not fit
into a single splice(2) syscall. The new size is just 5MB, so the test
uses a fraction of the memory it used to, and there's no longer a need
for a different size on short mode.

This also speeds up the test, which goes from ~1.23s to ~0.01s on my
laptop.

Fixes #26867.

Change-Id: Iae1daa5c0995b549f41992f44339be32ca1ee5e4
Reviewed-on: https://go-review.googlesource.com/128535
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Andrei Tudor Călin <mail@acln.ro>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

* TestAtomicCoverpkgAll -> Script/cover_atomic_pkgall.txt and make it
* non-short
* TestCoverpkgAllRuntime -> Script/cover_pkgall_runtime.txt and make it
* non-short
* TestCpuprofileTwice -> Script/cpu_profile_twice.txt and make it
* non-short
* TestGoTestMainTwice -> make it non-short

Updates #26472

Change-Id: I24f3d4c2a8b6e317adb369a1b1426e693f9571ed
Reviewed-on: https://go-review.googlesource.com/126636Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Before this change, 'go get <module>@none' for a module not in the build list
would add the module to go.mod (with the explicit version string "none").
Subsequent go commands would fail with 'invalid module version "none"'.

Change-Id: Iebcaeab89eb19959f0a9aeda836f179962953313
Reviewed-on: https://go-review.googlesource.com/127215Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: Ia2948a88c6d45a31be17b3d7415559cd53c289ce
Reviewed-on: https://go-review.googlesource.com/128015Reviewed-by: Russ Cox <rsc@golang.org>

A module like "gopkg.in/macaroon.v2" might have a test with a "_test" package
suffix (see https://golang.org/cmd/go/#hdr-Test_packages).
When we compile that test, its ImportStack entry includes the "_test" suffix
even though nothing else can actually import it via that path.
When we look up the module containing such a package, we must use the original
path, not the suffixed one.

On the other hand, an actual importable package may also be named with the
suffix "_test", so we need to be careful not to strip the suffix if it is
legitimately part of the path. We cannot distinguish that case by examining
srcDir or the ImportStack: the srcDir contaning a module doesn't necessarily
bear any relationship to its import path, and the ImportStack doesn't tell us
whether the suffix is part of the original path.

Fortunately, LoadImport usually has more information that we can use: it
receives a parent *Package that includes the original import path.

Fixes #26722

Change-Id: I1f7a4b37dbcb70e46af1caf9a496dfdd59ae8b17
Reviewed-on: https://go-review.googlesource.com/127796Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I09532546c96b3758f76528fb5010dafc638139b8
Reviewed-on: https://go-review.googlesource.com/128135Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This commits adds []interface{} and map[string]interface{} as quick
ways to create JavaScript arrays and objects. They correspond to the
JavaScript notations [...] and {...}. A type alias can be used for
a concise notation.

Change-Id: I98bb08dbef1e0f3bd3d65c732d6b09e1520026ba
Reviewed-on: https://go-review.googlesource.com/126855Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The package arch didn't have a definition as you can see in https://tip.golang.org/pkg/cmd/asm/internal/arch/

Change-Id: I07653b396393a75c445d04dbae5e22e90a0d5133
GitHub-Last-Rev: a859e9410f38073853687b933f53eb6570af3216
GitHub-Pull-Request: golang/go#26817
Reviewed-on: https://go-review.googlesource.com/127929
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #26721

Change-Id: Icc4660327a9ba668c88f8d9e0b9f206ba8f6dc27
Reviewed-on: https://go-review.googlesource.com/127975Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

GIT_TRACE write message to stderr, while run1 merge both stdout and
stderr. So function which call run1 and rely on its output will failed
to parse the result when run1 success.

By using cmd.Output(), we ensure only cmd standard out is returned.

Fixes #19682

Change-Id: I7002df17fe68aea1860ddc7382c68cc23548bd90
Reviewed-on: https://go-review.googlesource.com/126735Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

"expanded imports paths" should read "expanded import paths." Run
mkalldocs.sh to pick up other changes which were not committed to
alldocs.go.

Change-Id: Iaa61e022d65f9464e8ff93a92cfba27dadf679cf
Reviewed-on: https://go-review.googlesource.com/127157Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Reportedly on some new Fedora systems the linker is producing extra
load segments, basically making the dynamic section non-executable.
We were assuming that the first load segment could be used to
determine the program's load offset, but that is no longer true.
Use the first executable load segment instead.

Fixes #26369

Change-Id: I5ee31ddeef2e8caeed3112edc5149065a6448456
Reviewed-on: https://go-review.googlesource.com/127895
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #26507

Change-Id: I967e4f897ca891c70ca8bb0e66b984530c240815
Reviewed-on: https://go-review.googlesource.com/127835Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Notify readers that interval notation is used.
Fixes: #26765

Change-Id: Id02a7fcffbf41699e85631badeee083f5d4b2201
Reviewed-on: https://go-review.googlesource.com/127549Reviewed-by: Rob Pike <r@golang.org>

Fixes #26792

Change-Id: I9a878180af28e3939b654fd88bed150010dffde0
Reviewed-on: https://go-review.googlesource.com/127856
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

gcWriteBarrier and wbBufFlush assume that not writing to an argument
variable is sufficient to not clobber the corresponding argument slot.
This assumption lets us simplify the write barrier assembly code,
speed up the flush path, and reduce the stack usage of the write
barrier.

But it is an assumption, so this CL documents it to make this clear.

Alternatively, we could separate the register spill slots from the
argument slots in the write barrier, but that loses the advantages
above. On the other hand, it's extremely unlikely that we'll change
the behavior of the compiler to start clobbering argument slots (if
anything, we'd probably change it to *not* clobber argument slots even
if you wrote to the arguments).

Fixes #25512.

Change-Id: Ib2cf29c0d90956ca02b997ef6e7fa56fc8044efe
Reviewed-on: https://go-review.googlesource.com/127815Reviewed-by: Cherry Zhang <cherryyz@google.com>

Updates #25289

Change-Id: I662760b921be625aca988cd0b43c648ac5dfd814
Reviewed-on: https://go-review.googlesource.com/127837Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

"BFI $0, R1, $7, R2" is expected to copy bit 0~6 from R1 to R2, and
left R2's other bits unchanged.

But the assembler rejects it with error "illegal bit number", and
BFIW/SBFIZ/SBFIZW/UBFIZ/UBFIZW have the same problem.

This CL fixes that issue and adds corresponding test cases.

fixes #26736

Change-Id: Ie0090a0faa38a49dd9b096a0f435987849800b76
Reviewed-on: https://go-review.googlesource.com/127159
Run-TryBot: Ben Shi <powerman1st@163.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

We were passing untrimmed paths to ModPackageModuleInfo, which was then failing
the build because it was asked to resolve an invalid path.

Fixes #26722

Change-Id: I043cc9c26f2188c5e005c0353620d9c55b339df9
Reviewed-on: https://go-review.googlesource.com/127795Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>