| Age | Commit message (Collapse) | Author |
|---|
|
I forgot to run trybots on CL 123758, and the test failed on Windows because I
hard-coded a slash-delimited path.
Use the tent-in-a-box operator ([/\\]) to make the path platform-agnostic.
Change-Id: I9113ab60d21152c11e2ebdf822b58a44b1b38574
Reviewed-on: https://go-review.googlesource.com/125115
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Change-Id: Ie706c43c9a11cf30ca0f2139a4e9eabac8c75c75
Reviewed-on: https://go-review.googlesource.com/125096
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Update #26469
Change-Id: Id8b8d1c0db48374d5d3dc663a77187a73f60c9a5
Reviewed-on: https://go-review.googlesource.com/125037
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Fixes #25980.
Change-Id: I33c8e72871ffbb1cd1babbcd5dabc8cac0bbcaed
Reviewed-on: https://go-review.googlesource.com/123758
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
The test runs far too long for -short mode (4 seconds).
Also removed useless test of now-disconnected knob
(GO_SSA_PHI_LOC_CUTOFF), which cuts 4 seconds to 2 seconds (which
is still too long), and finished removing the disconnected knob.
Updates #26469.
Change-Id: I6c594227c4a5aaffee46832049bdbbf570d86e60
Reviewed-on: https://go-review.googlesource.com/125075
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
If the the package cannot be built,
"go test" and "go vet" should not run the "vet" tool.
In that case only errors from the compilers will be displayed.
Fixes #26125
Change-Id: I5da6ba64bae5f44feaf5bd4e765eea85533cddd4
Reviewed-on: https://go-review.googlesource.com/123938
Run-TryBot: Yury Smolsky <yury@smolsky.by>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
CL 123577 added TestScript. The install_rebuild_gopath
test was failing on Plan 9 because it defines a GOPATH
using the ':' separator, while Plan 9 expects the '\000'
separator in environment variables.
This change fixes the script engine by defining a new
":" environment variable set to OS-specific path list
separator.
The install_rebuild_gopath test has been updated to use
"${:}" instead of ":".
Fixes #26421.
Change-Id: I58a97f882cdb48cc0836398b0d98a80ea58041ba
Reviewed-on: https://go-review.googlesource.com/124435
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
When using callbacks, it is not necessarily a deadlock if there is no
runnable goroutine, since a callback might still be pending. If there
is no callback pending, Node.js simply exits with exit code zero,
which is not desired if the Go program is still considered running.
This is why an explicit check on exit is used to trigger the "deadlock"
error. This CL makes it so this is Go's normal "deadlock" error, which
includes the stack traces of all goroutines.
Updates #26382
Change-Id: If88486684d0517a64f570009a5ea0ad082679a54
Reviewed-on: https://go-review.googlesource.com/123936
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
It's important for a smooth transition for non-module users
not to change operation in GOPATH/src by default in Go 1.11,
even if go.mod exists in a downloaded dependency.
Even so, users create go.mod and then are confused about
why 'go get' commands seem to behave oddly, when in fact
they are getting the old 'go get'.
Try to split the difference by printing a warning in 'go get'
when run in a tree that would normally be considered a
module if only it were outside GOPATH/src.
Change-Id: I55a1cbef127f3f36de54a8d7b93e1fc64bf0a708
Reviewed-on: https://go-review.googlesource.com/124859
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
If there was a mod and non-mod meta tag for a given prefix,
the meta tag extractor was already dropping the non-mod meta tag.
But we might have mod and non-mod meta tags with different
prefixes, in which case the mod tag should prevail when both match.
Fixes #26200.
Change-Id: I17ab361338e270b9fa03999ad1954f2bbe0f5017
Reviewed-on: https://go-review.googlesource.com/124714
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
This patch ports the existing optimized P256 implementation to arm64.
name old time/op new time/op delta
pkg:crypto/ecdsa goos:linux goarch:arm64
SignP256 539µs ±13% 43µs ± 2% -91.95% (p=0.000 n=20+20)
SignP384 13.2ms ± 1% 13.2ms ± 1% ~ (p=0.739 n=10+10)
VerifyP256 1.57ms ± 0% 0.12ms ± 0% -92.40% (p=0.000 n=18+20)
KeyGeneration 391µs ± 0% 25µs ± 0% -93.62% (p=0.000 n=9+9)
pkg:crypto/elliptic goos:linux goarch:arm64
BaseMult 1.66ms ± 0% 1.65ms ± 1% ~ (p=0.079 n=9+10)
BaseMultP256 389µs ± 0% 22µs ± 1% -94.28% (p=0.000 n=19+20)
ScalarMultP256 1.03ms ± 0% 0.09ms ± 0% -91.25% (p=0.000 n=19+20)
name old alloc/op new alloc/op delta
pkg:crypto/ecdsa goos:linux goarch:arm64
SignP256 5.47kB ± 0% 3.20kB ± 0% -41.50% (p=0.000 n=20+20)
SignP384 2.32MB ± 0% 2.32MB ± 0% ~ (p=0.739 n=10+10)
VerifyP256 7.65kB ± 4% 0.98kB ± 0% -87.24% (p=0.000 n=20+20)
KeyGeneration 1.41kB ± 0% 0.69kB ± 0% -51.05% (p=0.000 n=9+10)
pkg:crypto/elliptic goos:linux goarch:arm64
BaseMult 224B ± 0% 224B ± 0% ~ (all equal)
BaseMultP256 1.12kB ± 0% 0.29kB ± 0% -74.29% (p=0.000 n=20+20)
ScalarMultP256 1.59kB ± 7% 0.26kB ± 0% -83.91% (p=0.000 n=20+20)
name old allocs/op new allocs/op delta
pkg:crypto/ecdsa goos:linux goarch:arm64
SignP256 67.0 ± 0% 35.0 ± 0% -47.76% (p=0.000 n=20+20)
SignP384 17.5k ± 0% 17.5k ± 0% ~ (p=0.725 n=10+10)
VerifyP256 97.2 ± 3% 17.0 ± 0% -82.52% (p=0.000 n=20+20)
KeyGeneration 21.0 ± 0% 13.0 ± 0% -38.10% (p=0.000 n=10+10)
pkg:crypto/elliptic goos:linux goarch:arm64
BaseMult 5.00 ± 0% 5.00 ± 0% ~ (all equal)
BaseMultP256 16.0 ± 0% 6.0 ± 0% -62.50% (p=0.000 n=20+20)
ScalarMultP256 19.9 ± 6% 5.0 ± 0% -74.87% (p=0.000 n=20+20)
Fixes #22806
Change-Id: I12b343a27e6544189334f99c84242bb59db70a76
Reviewed-on: https://go-review.googlesource.com/121360
Run-TryBot: Vlad Krasnov <vlad@cloudflare.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Vlad Krasnov <vlad@cloudflare.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Updates http2 to x/net/http2 git rev a680a1efc54 for:
http2: reject large SETTINGS frames or those with duplicates
https://golang.org/cl/124735
Change-Id: I2168d1d1eef9c63b1a9c06b514b77fae16f920ed
Reviewed-on: https://go-review.googlesource.com/125036
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Change-Id: I5a82aec66332f52e304f647758221b5f30b4e2b6
Reviewed-on: https://go-review.googlesource.com/124701
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
This was an unfortunate debugging print introduced
while working on the unfortunately large CL 123576.
At least now we're done with that awfulness.
Change-Id: Ib83db59382a799f649832d22d3c6f039d2ef9d2c
Reviewed-on: https://go-review.googlesource.com/125015
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
go.sum accumulates cruft as modules are added and removed as
direct and indirect dependencies. Instead of exposing all that cruft,
let "go mod -sync" clean it out.
Fixes #26381.
Change-Id: I7c9534cf7cc4579f7f82646d00ff691c87a13c4a
Reviewed-on: https://go-review.googlesource.com/124713
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
People are (understandably) confused by creating go.mod files in GOPATH/src
and then having the go command not use modules in those directories.
We can't change that behavior (or we'll break non-module users of GOPATH)
but we can force 'go mod' (including 'go mod -init') to fail loudly in that case.
If this is not enough, the next step would be to print a warning every time
the go command is run in a GOPATH/src directory with a go.mod but
module mode hasn't triggered. But that will annoy all the non-module users.
Hopefully anyone confused will eventually run a 'go mod' command of
some kind, which will fail loudly.
Fixes #26365.
Change-Id: I8c5fe987fbc3f8d2eceb1138e6862a391ade150c
Reviewed-on: https://go-review.googlesource.com/124708
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Also document module use of GOPATH including GOPATH/src/mod
and GOPATH/bin (unless GOBIN is set).
Fixes #26399.
Fixes #26406.
Change-Id: I7be8eaf110f4fa6fc76ea4cd39aea3dd8addf0b0
Reviewed-on: https://go-review.googlesource.com/124707
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Now pkg@none actually removes the pkg instead of dying.
For #26342.
Change-Id: I9df7281ed8fd24480109b36f33a563f92e279244
Reviewed-on: https://go-review.googlesource.com/124796
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Change-Id: Iba68b3aaf4a132bd4ca44edf4912a46549d2ef8f
Reviewed-on: https://go-review.googlesource.com/124700
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
The original pseudo-version design used versions of the form
v0.0.0-yyyymmddhhmmss-abcdef123456
These were intentionally chosen to be valid semantic versions
that sort below any explicitly-chosen semantic version (even v0.0.0),
so that they could be used before anything was tagged but after
that would essentially only be useful in replace statements
(because the max operation during MVS would always prefer
a tagged version).
Then we changed the go command to accept hashes on the
command line, so that you can say
go get github.com/my/proj@abcdef
and it will download and use v0.0.0-yyyymmddhhmmss-abcdef123456.
If you were using v1.10.1 before and this commit is just little bit
newer than that commit, calling it v0.0.0-xxx is confusing but
also harmful: the go command sees the change from v1.10.1 to
the v0.0.0 pseudoversion as a downgrade, and it downgrades other
modules in the build. In particular if some other module has
a requirement of github.com/my/proj v1.9.0 (or later), the
pseudo-version appears to be before that, so go get would
downgrade that module too. It might even remove it entirely,
if every available version needs a post-v0.0.0 version of my/proj.
This CL introduces new pseudo-version forms that can be used
to slot in after the most recent explicit tag before the commit.
If the most recent tagged commit before abcdef is v1.10.1,
then now we will use
v1.10.2-0.yyyymmddhhmmss-abcdef123456
This has the right properties for downgrades and the like,
since it is after v1.10.1 but before almost any possible
successor, such as v1.10.2, v1.10.2-1, or v1.10.2-pre.
This CL also uses those pseudo-version forms as appropriate
when mapping a hash to a pseudo-version. This fixes the
downgrade problem.
Overall, this CL reflects our growing recognition of pseudo-versions
as being like "untagged prereleases".
Issue #26150 was about documenting best practices for how
to work around this kind of accidental downgrade problem
with additional steps. Now there are no additional steps:
the problem is avoided by default.
Fixes #26150.
Change-Id: I402feeccb93e8e937bafcaa26402d88572e9b14c
Reviewed-on: https://go-review.googlesource.com/124515
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Repos written before the introduction of semantic import versioning
introduced tags like v2.0.0, v3.0.0, and so on, expecting that
(1) the import path would remain unchanged, and perhaps also
(2) there would be at most one copy of the package in a build.
We've always accommodated these by mapping them into the
v0/v1 version range, so that if you ran
go get k8s.io/client-go@v8.0.0
it would not complain about v8.x.x being a non-v1 version and
instead would map that version to a pseudo-version in go.mod:
require k8s.io/client-go v0.0.0-20180628043050-7d04d0e2a0a1
The pseudo-version fails to capture two important facts: first,
that this really is the v8.0.0 tag, and second, that it should be
preferred over any earlier v1 tags.
A related problem is that running "go get k8s.io/client-go"
with no version will choose the latest v1 tag (v1.5.1), which
is obsolete.
This CL introduces a new version suffix +incompatible that
indicates that the tag should be considered an (incompatible)
extension of the v1 version sequence instead of part of its
own major version with its own versioned module path.
The requirement above can now be written:
require k8s.io/client-go v8.0.0+incompatible
(The +metadata suffix is a standard part of semantic versioning,
and that suffix is ignored when comparing two versions for
precedence or equality. As part of canonicalizing versions
recorded in go.mod, the go command has always stripped all
such suffixes. It still strips nearly all: only +incompatible is
preserved now.)
In addition to recognizing the +incompatible, the code that
maps a commit hash to a version will use that form when
appropriate, so that
go get k8s.io/client-go@7d04d0
will choose k8s.io/client-go@v8.0.0+incompatible.
Also, the code that computes the list of available versions from
a given source code repository also maps old tags to +incompatible
versions, for any tagged commit in which a go.mod file does not exist.
Therefore
go list -m -versions k8s.io/client-go@latest
will show
k8s.io/client-go v1.4.0 v1.5.0 v1.5.1 v2.0.0-alpha.0+incompatible ... v8.0.0+incompatible
and similarly
go get k8s.io/client-go
will now choose v8.0.0+incompatible as the meaning of "latest tagged version".
The extraction of +incompatible versions from source code repos
depends on a codehost.Repo method ReadFileRevs, to do a bulk read
of multiple revisions of a file. That method is only implemented for git in this CL.
Future CLs will need to add support for that method to the other repository
implementations.
Documentation for this change is in CL 124515.
Fixes #26238.
Change-Id: I5bb1d7a46b5fffde34a3c0e6f8d19d9608188cea
Reviewed-on: https://go-review.googlesource.com/124384
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Windows networking doesn't work without this environment variable (#25210).
Re-enable TestScript on Windows, and fix two minor failures.
Fixes #26457.
Change-Id: Id9bea49dfb58403195c29c3d831a532ef0f9a233
Reviewed-on: https://go-review.googlesource.com/124858
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
TSAN for Go only supports heap address in the range [0x00c000000000,
0x00e000000000). However, we currently create heap hints of the form
0xXXc000000000 for XX between 0x00 and 0x7f. Even for XX=0x01, this
hint is outside TSAN's supported heap address range.
Fix this by creating a slightly different set of hints in race mode,
all of which fall inside TSAN's heap address range.
This should fix TestArenaCollision flakes. That test forces the
runtime to use later heap hints. Currently, this always results in
TSAN "failed to allocate" failures on Windows (which happens to have a
slightly more constrained TSAN layout than non-Windows). Most of the
time we don't notice these failures, but sometimes it crashes TSAN,
leading to a test failure.
Fixes #25698.
Change-Id: I8926cd61f0ee5ee00efa77b283f7b809c555be46
Reviewed-on: https://go-review.googlesource.com/123780
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
|
|
Code fix was in CL 122556. This is a corresponding test case.
Fixes #26426
Change-Id: Ib8769f367aed8bead029da0a8d2ddccee1d1dccb
Reviewed-on: https://go-review.googlesource.com/124535
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
The backwards incompatible changes were undone in CL 120355, while still
preserving the additions needed for assignments in templates to work.
Change-Id: Ie76a798916ef36509c88e171a04bb2cf2a3d7e8e
Reviewed-on: https://go-review.googlesource.com/124917
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Until we figure out how to deal with gdb on Darwin (doesn't
read compressed DWARF from binaries), avoid compressing
DWARF in that case so that the test will still yield meaningful
results.
This is also reported to be a problem for Windows.
Problem also exists for lldb, but this test doesn't check
lldb.
Updates #25925
Change-Id: I85c0e5db75f3329957290500626a3ac7f078f608
Reviewed-on: https://go-review.googlesource.com/124712
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
|
|
I don't know why it's failing.
Filed #26457.
Change-Id: I84833293a572c5a1a25135bd01cb88518fc7441e
Reviewed-on: https://go-review.googlesource.com/124857
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Pointed out in CL 122396.
An empty prefix has already been handled above.
Change-Id: Ib94df0a9c8c0517f932b90126232111caa9ad289
Reviewed-on: https://go-review.googlesource.com/124797
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Change-Id: I249bb848c9911948dbd84cd88ad043a61ed6ea6b
Reviewed-on: https://go-review.googlesource.com/124699
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Change-Id: Iba185e00e9df2462e9089566053f6c64e24a6a92
Reviewed-on: https://go-review.googlesource.com/124698
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Change-Id: I8a36fad061bdf9a19f40531511f3f5717db13b60
Reviewed-on: https://go-review.googlesource.com/124697
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Change-Id: If0976d15027db795f1383ef709c49c838cbb6953
Reviewed-on: https://go-review.googlesource.com/124696
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
It was flaky on slower machines.
Per report at https://github.com/golang/go/issues/23399#issuecomment-405792381
Change-Id: I7cab02821f78b5ce02ea51089d7eb51723f9705f
Reviewed-on: https://go-review.googlesource.com/124835
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Completely replace the opener, which had become not only stale
but bad, expand the discussion of the gopher, and generally provide
prose more connected to the present than to the programming world
of 2007.
Fixes #26107
Change-Id: I5e72f0c81e71d1237fe142dc26114991329a6996
Reviewed-on: https://go-review.googlesource.com/124616
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Change-Id: Ic1ff580573711a6c91c1d5e3eb019a298a2fec49
Reviewed-on: https://go-review.googlesource.com/124837
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Change-Id: I9008afdc8c38c440ea083a4f2bed0d2253e112f0
Reviewed-on: https://go-review.googlesource.com/124836
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Change-Id: I3e2a19fe90334f0c1ed1593c7a9a3a458f15d8e8
Reviewed-on: https://go-review.googlesource.com/124799
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Change-Id: Ib488a78802ad730e7c6b3618eab24c259f4bebd1
Reviewed-on: https://go-review.googlesource.com/124798
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Change-Id: I30d2b4b94f26300f2cf7b4ecd328a4875d69db51
Reviewed-on: https://go-review.googlesource.com/124777
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
The final API uses 'region' instead of 'span' from the proposal.
Change-Id: I305da891a360596fff89b10bc6de3090289b5396
Reviewed-on: https://go-review.googlesource.com/124815
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Change-Id: Ie4e81b88cc8035fddf9c074363a1b35bcae3d470
Reviewed-on: https://go-review.googlesource.com/124778
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
If one tries to use promoted fields in a struct literal, the compiler
errors correctly. However, if the embedded fields are of struct pointer
type, the field.Type.Sym.Name expression below panics.
This is because field.Type.Sym is nil in that case. We can simply use
field.Sym.Name in this piece of code though, as it only concerns
embedded fields, in which case what we are after is the field name.
Added a test mirroring fixedbugs/issue23609.go, but with pointer types.
Fixes #26416.
Change-Id: Ia46ce62995c9e1653f315accb99d592aff2f285e
Reviewed-on: https://go-review.googlesource.com/124395
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
Change-Id: I806d411c075cdc66322112b6ee5e50f58462bc6b
Reviewed-on: https://go-review.googlesource.com/124776
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Text based on CL 124655.
Change-Id: I7c4866ce829cb28a4c60cd8ced3ef99047a38c54
Reviewed-on: https://go-review.googlesource.com/124711
Reviewed-by: Austin Clements <austin@google.com>
|
|
If a filepath.WalkFunc is called with an non-nil err argument, it's possible
that the info argument will be nil. The comment above filepath.WalkFunc now
reflects this.
Fixes #26425
Change-Id: Ib9963b3344587d2993f1698c5a801f2d1286856b
GitHub-Last-Rev: 553fc266b570d0c47efe12b3b670f88112e3b334
GitHub-Pull-Request: golang/go#26435
Reviewed-on: https://go-review.googlesource.com/124635
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Change-Id: I25b93a84996ab1c17d64089b4c2ffabdff3365ec
Reviewed-on: https://go-review.googlesource.com/124710
Reviewed-by: Austin Clements <austin@google.com>
|
|
Change-Id: Id06e5139f16cd7a85c59a3dcf2020cf647fcdea0
Reviewed-on: https://go-review.googlesource.com/124709
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Change-Id: I357eea0efb04392e1a4671d20190a2052bf548de
Reviewed-on: https://go-review.googlesource.com/124706
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Update text/scanner and text/template sections.
Change-Id: I1a273e99ff400870053cca63cea68fb7a9b56764
Reviewed-on: https://go-review.googlesource.com/124705
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
This doesn't auto-deploy to golang.org, only tip.golang.org.
Change-Id: I112743ada2c1393e21edcc9075127f40da9e6270
Reviewed-on: https://go-review.googlesource.com/124755
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
