After running mkalldocs.sh this also adds some previously missing parts
to alldocs.go
Change-Id: Ifa624c54543fd31d699a0d4bb5df7b1969bf941c
Reviewed-on: https://go-review.googlesource.com/128915
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
When we added v2.0.0+incompatible we generalized the API
enough to make it easy to also accepting these gopkg-specific
v2-unstable suffixes. Do that.
Fixes#23989.
Change-Id: Ieabed11a5250c2999d73450c10b20f4c645ad445
Reviewed-on: https://go-review.googlesource.com/128901
Reviewed-by: Bryan C. Mills <bcmills@google.com>
For a package in the module root, using the containing directory name
might mean the directory in the module cache, in which case the
executable has a final @v1.2.3 in it, which is no good. Fix that.
While we're here, change go install example.com/cmd/foo/v2 to
install foo instead of the less useful "v2".
Fixes#24667.
Fixes#26869.
Change-Id: Ie40ca1bc9e27955441f1cdb7abd3a1f69034c9f5
Reviewed-on: https://go-review.googlesource.com/128900
Reviewed-by: Bryan C. Mills <bcmills@google.com>
If we're using -mod=vendor then we effectively load
a fake build list from vendor/modules.txt.
Do not write it back to go.mod.
Fixes#26704.
Change-Id: Ie79f2103dc16d0b7fe0c884e77ba726c7e04f2e4
Reviewed-on: https://go-review.googlesource.com/128899
Reviewed-by: Bryan C. Mills <bcmills@google.com>
A very common question is
"why is this package or module being kept
by go mod vendor or go mod tidy?"
go mod why answers that question.
Fixes#26620.
Change-Id: Iac3b6bbdf703b4784f5eed8e0f69d41325bc6d7f
Reviewed-on: https://go-review.googlesource.com/128359
Reviewed-by: Bryan C. Mills <bcmills@google.com>
go list all was not behaving as documented - it did not pick up
test dependencies except when running in "go test" and "go vet".
It should pick them up always.
Also the module loader was ignoring tests when using "go list -test",
which led to load failures.
Fixing all required adjustments to mod_patterns test.
Removed error-prone exact listings.
Fixes#26279.
Fixes#26906.
Change-Id: I9c5acaf2275be20fd2349859589502190d3e7a78
Reviewed-on: https://go-review.googlesource.com/128358
Reviewed-by: Bryan C. Mills <bcmills@google.com>
When a test variant of a package is created, the two versions cannot
share memory for the fields that contain information about their
imports, as these will be different between the two packagse.
Both the Internal.Imports and the Imports fields must be able to be
updated in the test variant without affecting the values of the
original.
Fixesgolang/go#26880
Change-Id: Id61fad7d976e179c6c7711a394ce43ec8302fd7a
Reviewed-on: https://go-review.googlesource.com/128836
Reviewed-by: Russ Cox <rsc@golang.org>
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>
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>
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/128136
Reviewed-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>
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/126956
Reviewed-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/126215
Reviewed-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: 9172e9dc13
GitHub-Pull-Request: golang/go#26448
Reviewed-on: https://go-review.googlesource.com/124775
Reviewed-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: 6d2b54447b
GitHub-Pull-Request: golang/go#26516
Reviewed-on: https://go-review.googlesource.com/125355
Reviewed-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/128435
Reviewed-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/128416
Reviewed-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/126636
Reviewed-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/127215
Reviewed-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/127796
Reviewed-by: Russ Cox <rsc@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/126855
Reviewed-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/126735
Reviewed-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/127157
Reviewed-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>
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/127815
Reviewed-by: Cherry Zhang <cherryyz@google.com>
"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/127795
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This fixes tests on systems where ccache is the default compiler.
Also simplify a prior workaround for this fault.
Fixed#26789
Change-Id: I031ff0b65ace7fc5e284393298e004aa2ad3b6f5
Reviewed-on: https://go-review.googlesource.com/127775
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
