cmd/go/internal/modload: allow 'go get' to use replaced versions
'go mod tidy' has been able to use replaced versions since CL 152739,
but 'go get' failed for many of the same paths. Now that we are
recommending 'go get' more aggressively due to #40728, we should make
that work too.
In the future, we might consider factoring out the new replacementRepo
type so that 'go list' can report the new versions as well.
For #41577
For #41416
For #37438
Updates #26241
Change-Id: I9140c556424b584fdd9bdd0a747842774664a7d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/258220
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Austin Clements [Thu, 15 Oct 2020 19:52:58 +0000 (15:52 -0400)]
runtime/internal/atomic: panic nicely on unaligned 64-bit atomics
On 386 and arm, unaligned 64-bit atomics aren't safe, so we check for
this and panic. Currently, we panic by dereferencing nil, which may be
expedient but is pretty user-hostile since it gives no hint of what
the actual problem was.
This CL replaces this with an actual panic. The only subtlety here is
now the atomic assembly implementations are calling back into Go, so
they have to play nicely with stack maps and stack scanning. On 386,
this just requires declaring NO_LOCAL_POINTERS. On arm, this is
somewhat more complicated: first, we have to move the alignment check
into the functions that have Go signatures. Then we have to support
both the tail call from these functions to the underlying
implementation (which requires that they have no frame) and the call
into Go to panic (which requires that they have a frame). We resolve
this by forcing them to have no frame and setting up the frame
manually just before the panic call.
Austin Clements [Thu, 15 Oct 2020 20:11:10 +0000 (16:11 -0400)]
runtime/internal/atomic: drop package prefixes
This drops package prefixes from the assembly code on 386 and arm. In
addition to just being nicer, this allows the assembler to
automatically pick up the argument stack map from the Go signatures of
these functions. This doesn't matter right now because these functions
never call back out to Go, but prepares us for the next CL.
Ross Light [Sat, 26 Sep 2020 15:49:56 +0000 (08:49 -0700)]
net/http: ensure Request.Body.Close is called once and only once
Makes *Request.write always close the body, so that callers no longer
have to close the body on returned errors, which was the trigger for
double-close behavior.
Fixes #40382
Change-Id: I128f7ec70415f240d82154cfca134b3f692191e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/257819 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Damien Neil <dneil@google.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Ross Light [Thu, 27 Aug 2020 20:08:29 +0000 (13:08 -0700)]
net/http: document concurrency expectations for Request.Body
This is primarily aimed at client requests where the user can supply
their own io.ReadCloser, but also clarifies server request behavior.
A server request body can be one of:
In preparation for moving os.FileInfo into io/fs.
Also keep syscall from depending on io again.
We want to keep them separated, in case io ever
needs to start depending on time.
For #41190.
Change-Id: I98350fa03accf4a20c75ddebb0e961aa1ccccd2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/243905
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
Cherry Zhang [Thu, 15 Oct 2020 22:04:08 +0000 (18:04 -0400)]
cmd/internal/objfile: correct file table reading for Go object file
Apparently I never actually understood the new file table in Go
object files. The PC value stream actually encodes the file index
in the per-CU table. I thought it was indexing into a per-function
table, which then contains index to the per-CU table. Remove the
extra indirection.
Change-Id: I0aea5629f7b3888ebe3a04fea437aa15ce89519e
Reviewed-on: https://go-review.googlesource.com/c/go/+/262779
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org>
Lynn Boger [Tue, 6 Oct 2020 21:08:31 +0000 (17:08 -0400)]
cmd/internal/obj/ppc64,cmd/asm/internal/asm/testdata: fix up ppc64 testcases
When a fix was made at the end of the last release related to
NOPs, it was discovered that the ppc64.s testcase was out of date
and contained comments that weren't being processed. Essentially the
instructions in that test were being assembled but there was no
verification that the encodings weres correct. The ppc64enc.s file
was mostly complete and included the valid encodings for verification.
This change moves ppc64enc.s to ppc64.s and adds the instructions
that were missing.
This also adds a minor fix to asm9.go on the assembly of the
addex that was discovered during this testing.
Change-Id: Iaada1563b137849ad195fa88f32ecc9ab3e1e95f
Reviewed-on: https://go-review.googlesource.com/c/go/+/260217
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Russ Cox [Thu, 15 Oct 2020 16:09:56 +0000 (12:09 -0400)]
sort: update comments
- Describe requirements on Less more precisely.
- Standardize on x for the variable name of the data being sorted
(was variously a, p, slice).
- Many other minor wording changes.
This creates space for a different kind of extension field
in LSym without making the struct any larger.
(There are many LSym, so we care about keeping the struct small.)
Michael Matloob [Wed, 14 Oct 2020 20:21:39 +0000 (16:21 -0400)]
cmd/go: rewrite paths for overlaid files using -trimpath
Pass the trimpath flag to cmd/compile to use the correct file paths
for files that are overlaid: that is, the "destination" path in the
overlay's Replace mapping rather than the "source" path.
Also fix paths to go source files provided to the gccgo compiler.
For #39958
Change-Id: I3741aeb2272bd0d5aa32cb28133b61e58264fd39
Reviewed-on: https://go-review.googlesource.com/c/go/+/257198
Trust: Michael Matloob <matloob@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Matthew Dempsky [Tue, 22 Sep 2020 09:19:14 +0000 (02:19 -0700)]
cmd/compile: use staticValue for inlining logic
This CL replaces the ad hoc and duplicated logic for detecting
inlinable calls with a single "inlCallee" function, which uses the
"staticValue" helper function introduced in an earlier commit.
Updates #41474.
Change-Id: I103d4091b10366fce1344ef2501222b7df68f21d
Reviewed-on: https://go-review.googlesource.com/c/go/+/256460 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Ian Lance Taylor [Wed, 14 Oct 2020 23:03:48 +0000 (16:03 -0700)]
runtime: stop preemption during syscall.Exec on Darwin
On current macOS versions a program that receives a signal during an
execve can fail with a SIGILL signal. This appears to be a macOS
kernel bug. It has been reported to Apple.
This CL partially works around the problem by using execLock to not
send preemption signals during execve. Of course some other stray
signal could occur, but at least we can avoid exacerbating the problem.
We can't simply disable signals, as that would mean that the exec'ed
process would start with all signals blocked, which it likely does not
expect.
Fixes #41702
Change-Id: I91b0add967b315671ddcf73269c4d30136e579b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/262438
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Matthew Dempsky [Tue, 22 Sep 2020 03:20:00 +0000 (20:20 -0700)]
cmd/compile: allow inlining of "for" loops
We already allow inlining "if" and "goto" statements, so we might as
well allow "for" loops too. The majority of frontend support is
already there too.
The critical missing feature at the moment is that inlining doesn't
properly reassociate OLABEL nodes with their control statement (e.g.,
OFOR) after inlining. This eventually causes SSA construction to fail.
As a workaround, this CL only enables inlining for unlabeled "for"
loops. It's left to a (yet unplanned) future CL to add support for
labeled "for" loops.
The increased opportunity for inlining leads to a small growth in
binary size. For example:
$ size go.old go.new
text data bss dec hex filename 9740163 320064 230656 10290883 9d06c3 go.old 9793399 320064 230656 10344119 9dd6b7 go.new
Updates #14768.
Fixes #41474.
Change-Id: I827db0b2b9d9fa2934db05caf6baa463f0cd032a
Reviewed-on: https://go-review.googlesource.com/c/go/+/256459
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Matthew Dempsky [Tue, 22 Sep 2020 09:12:03 +0000 (02:12 -0700)]
cmd/compile: improve escape analysis of known calls
Escape analysis is currently very naive about identifying calls to
known functions: it only recognizes direct calls to a declared
function, or direct calls to a closure.
This CL adds a new "staticValue" helper function that can trace back
through local variables that were initialized and never reassigned
based on a similar optimization already used by inlining. (And to be
used by inlining in a followup CL.)
Updates #41474.
Change-Id: I8204fd3b1e150ab77a27f583985cf099a8572b2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/256458
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: David Chase <drchase@google.com>
Matthew Dempsky [Tue, 22 Sep 2020 04:24:00 +0000 (21:24 -0700)]
cmd/compile: set n.Name.Defn for inlined parameters
Normally, when variables are declared and initialized using ":=", we
set the variable's n.Name.Defn to point to the initialization
assignment node (i.e., OAS or OAS2). Further, some frontend
optimizations look for variables that are initialized but never
reassigned.
However, when inl.go inlines calls, it was declaring the inlined
variables, and then separately assigning to them. This CL changes
inl.go tweaks the AST to fit the combined declaration+initialization
pattern.
This isn't terribly useful by itself, but it allows further followup
optimizations.
Updates #41474.
Change-Id: I62a9752c60414305679e0ed15a6563baa0224efa
Reviewed-on: https://go-review.googlesource.com/c/go/+/256457
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Alberto Donizetti [Tue, 13 Oct 2020 13:58:10 +0000 (15:58 +0200)]
cmd/compile: make assignop/convertop reason a return param
On a negative answer, the assignop and convertop functions write the
reason why to a string pointer passed as an argument, likely a C-ism
leftover since the compiler's machine assisted translation to Go.
This change makes why a return parameter.
It also fixes a few places where the assignop/convertop result was
compared to 0. While OXXX's value may be zero now, using the named
constant is more robust.
Change-Id: Id9147ed4c1b97d658d30a2f778f876b7867006b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/261857 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Alberto Donizetti [Thu, 15 Oct 2020 12:48:26 +0000 (14:48 +0200)]
cmd/compile: clean up C->Go translation artifacts in badtype
Change-Id: I576a596ed8e9ce14e3750031d0e338e9276eff1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/262537
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Michael Pratt [Wed, 14 Oct 2020 21:18:27 +0000 (17:18 -0400)]
runtime: remove debugCachedWork
debugCachedWork and all of its dependent fields and code were added to
aid in debugging issue #27993. Now that the source of the problem is
known and mitigated (via the extra work check after STW in gcMarkDone),
these extra checks are no longer required and simply make the code more
difficult to follow.
Remove it all.
Updates #27993
Change-Id: I594beedd5ca61733ba9cc9eaad8f80ea92df1a0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/262350
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Add check in cmd/go/internal/work.BuildInit and
cmd/go/internal/envcmd.checkEnvWrite.
Fixes #38372
Change-Id: I196ea93a0469e4667ef785f7c1dc4574bdf7ff78
Reviewed-on: https://go-review.googlesource.com/c/go/+/228517
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Trust: Michael Matloob <matloob@golang.org>
Jean de Klerk [Tue, 13 Oct 2020 22:16:24 +0000 (16:16 -0600)]
token: more descriptive panics
Currently, there are several panics in token that simply say "illegal!". This CL
adds the values.
This is valuable when the token call is wrapped under several layers and you
can't easily see which value is being passed to token.
Change-Id: Ib04b55cafcd9b9ec6820dcf416fc4d49afaea15f
Reviewed-on: https://go-review.googlesource.com/c/go/+/262017 Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Jean de Klerk <deklerk@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Roland Shoemaker [Mon, 5 Oct 2020 20:18:20 +0000 (13:18 -0700)]
crypto/x509: add signature verification to CreateCertificate
This changes checks the signature generated during CreateCertificate
and returns an error if the verification fails. A benchmark is also
added. For RSA keys the delta looks to be insignificant, but for
ECDSA keys it introduces a much larger delta which is not ideal.
name old time/op new time/op delta
RSA_2048-8 1.38ms ± 6% 1.41ms ± 2% ~ (p=0.182 n=10)
ECDSA_P256-8 42.6µs ± 4% 116.8µs ± 4% +174.00% (p=0.000 n=1
Fixes #40458
Change-Id: I22827795bb9bb6868b4fa47391927db1d3bc19a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/259697
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Emmanuel Odeke <emm.odeke@gmail.com>
Trust: Roland Shoemaker <roland@golang.org>
Tobias Klauser [Tue, 13 Oct 2020 15:07:34 +0000 (17:07 +0200)]
lib/time, time, time/tzdata: use slim tz data format
Follow-up for CL 261363 which had to retain the fat tz data format due
to failing test.
The reason for the failed tests was that when caching location data, the
extended time format past the end of zone transitions was not
considered. The respective change was introduced in (*Location).lookup
by CL 215539.
This slims down zoneinfo.zip (and thus also the embedded copy in
time/tzdata) by ~350KB.
Change-Id: I412f79de98ba45358b8696aca784999b3479135e
Reviewed-on: https://go-review.googlesource.com/c/go/+/261877
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alberto Donizetti [Mon, 12 Oct 2020 13:02:59 +0000 (15:02 +0200)]
cmd/compile: rename strlit, Bool, and Int64 *Node accessors
The Node type has shortcuts to access bool and int Values:
func (n *Node) Int64() int64
for n.Val().U.(*Mpint).Int64()
func (n *Node) Bool() bool
for n.Val().U.(bool)
I was convinced we didn't have one for string literal nodes, until I
noticed that we do, it's just called strlit, it's not a method, and
it's later in the file:
func strlit(n *Node) string
This change, for consistency:
- Renames strlit to StringVal and makes it a *Node method
- Renames Bool and Int64 to BoolVal and Int64Val
- Moves StringVal near the other two
Change-Id: I18e635384c35eb3a238fd52b1ccd322b1a74d733
Reviewed-on: https://go-review.googlesource.com/c/go/+/261361
Trust: Alberto Donizetti <alb.donizetti@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Martin Möhrmann [Mon, 14 Sep 2020 14:55:34 +0000 (16:55 +0200)]
runtime: implement GODEBUG=inittrace=1 support
Setting inittrace=1 causes the runtime to emit a single line to standard error for
each package with init work, summarizing the execution time and memory allocation.
The emitted debug information for init functions can be used to find bottlenecks
or regressions in Go startup performance.
Packages with no init function work (user defined or compiler generated) are omitted.
Tracing plugin inits is not supported as they can execute concurrently. This would
make the implementation of tracing more complex while adding support for a very rare
use case. Plugin inits can be traced separately by testing a main package importing
the plugins package imports explicitly.
$ GODEBUG=inittrace=1 go test
init internal/bytealg @0.008 ms, 0 ms clock, 0 bytes, 0 allocs
init runtime @0.059 ms, 0.026 ms clock, 0 bytes, 0 allocs
init math @0.19 ms, 0.001 ms clock, 0 bytes, 0 allocs
init errors @0.22 ms, 0.004 ms clock, 0 bytes, 0 allocs
init strconv @0.24 ms, 0.002 ms clock, 32 bytes, 2 allocs
init sync @0.28 ms, 0.003 ms clock, 16 bytes, 1 allocs
init unicode @0.44 ms, 0.11 ms clock, 23328 bytes, 24 allocs
...
Inspired by stapelberg@google.com who instrumented doInit
in a prototype to measure init times with GDB.
Fixes #41378
Change-Id: Ic37c6a0cfc95488de9e737f5e346b8dbb39174e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/254659
Trust: Martin Möhrmann <moehrmann@google.com>
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Ian Lance Taylor [Tue, 13 Oct 2020 00:19:49 +0000 (17:19 -0700)]
test: add test that fails with gofrontend
The gofrontend code doesn't correctly handle inlining a function that
refers to a constant with methods.
For #35739
Change-Id: I6bd0b5cd4272dbe9969634b4821e668acacfdcf9
Reviewed-on: https://go-review.googlesource.com/c/go/+/261662
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Matthew Dempsky [Mon, 12 Oct 2020 21:02:36 +0000 (14:02 -0700)]
cmd/compile: fix and improve alias detection
"aliased" is the function responsible for detecting whether we can
turn "a, b = x, y" into just "a = x; b = y", or we need to pre-compute
y and save it in a temporary variable because it might depend on a.
It currently has two issues:
1. It suboptimally treats assignments to blank as writes to heap
memory. Users generally won't write "_, b = x, y" directly, but it
comes up a lot in generated code within the compiler.
This CL changes it to ignore blank assignments.
2. When deciding whether the assigned variable might be referenced by
pointers, it mistakenly checks Class() and Name.Addrtaken() on "n"
(the *value* expression being assigned) rather than "a" (the
destination expression).
It doesn't appear to result in correctness issues (i.e.,
incorrectly reporting no aliasing when there is potential aliasing),
due to all the (overly conservative) rewrite passes before code
reaches here. But it generates unnecessary code and could have
correctness issues if we improve those other passes to be more
aggressive.
This CL fixes the misuse of "n" for "a" by renaming the variables
to "r" and "l", respectively, to make their meaning clearer.
Improving these two cases shaves 4.6kB of text from cmd/go, and 93kB
from k8s.io/kubernetes/cmd/kubelet:
While here, this CL also collapses "memwrite" and "varwrite" into a
single variable. Logically, they're detecting the same thing: are we
assigning to a memory location that a pointer might alias. There's no
need for two variables.
Updates #6853.
Updates #23017.
Change-Id: I5a307b8e20bcd2196e85c55eb025d3f01e303008
Reviewed-on: https://go-review.googlesource.com/c/go/+/261677
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Bryan C. Mills [Fri, 2 Oct 2020 20:25:17 +0000 (16:25 -0400)]
cmd/go/internal/modfetch: remove error return from Lookup
We generally don't care about errors in resolving a repo if the result
we're looking for is already in the module cache. Moreover, we can
avoid some expense in initializing the repo if all of the methods we
plan to call on it hit in the cache — especially when using
GOPROXY=direct.
This also incidentally fixes a possible (but rare) bug in Download:
we had forgotten to reset the downloaded file in case the Zip method
returned an error after writing a nonzero number of bytes.
For #37438
Change-Id: Ib64f10f763f6d1936536b8e1f7d31ed1b463e955
Reviewed-on: https://go-review.googlesource.com/c/go/+/259158
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
cmd/go: adjust ImportMissingError when module lookup is disabled
Previously, ImportMissingError said
"cannot find module providing package …"
even when we didn't even attempt to find such a module.
Now, we write "no module requirement provides package …"
when we did not attempt to identify a suitable module,
and suggest either 'go mod tidy' or 'go get -d' as appropriate.
Fixes #41576
Change-Id: I979bb999da4066828c54d99a310ea66bb31032ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/258298
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Martin Möhrmann [Tue, 13 Oct 2020 06:32:41 +0000 (08:32 +0200)]
internal/cpu: remove unused arm64 capabilities
Change-Id: I038b0fe165931b8ec3ef59f08dc73c8128d56572
Reviewed-on: https://go-review.googlesource.com/c/go/+/261365
Trust: Martin Möhrmann <moehrmann@google.com>
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Tao Qingyun [Tue, 13 Oct 2020 05:56:48 +0000 (05:56 +0000)]
io: add ErrBadWriteCount
Fixes #39978
Change-Id: Ib41459861ba9f7cf0bf1fc95b1479c358c4bdbd8
GitHub-Last-Rev: 19cbb1461ca04a8eb64f0c4f354d8fb81a70d4f3
GitHub-Pull-Request: golang/go#39989
Reviewed-on: https://go-review.googlesource.com/c/go/+/240740
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Lynn Boger [Tue, 13 Oct 2020 13:15:52 +0000 (09:15 -0400)]
cmd/link: update plt size appropriately on ppc64
When attempting to enable internal linking with cgo on ppc64
it was discovered that the plt size was not being updated
after adding entries to it, which resulted in this error:
Cherry Zhang [Mon, 12 Oct 2020 22:00:25 +0000 (18:00 -0400)]
cmd/link: set runtime.text to the address of the first function
In CL 240065 we changed it to set to FlagTextAddr. Normally it
is the address of the first function, except on plan9/amd64
where, as FlagTextAddr is not aligned, it is rounded up. Set it
to the actual text start address.
Fixes #41137.
Change-Id: I1bba67f5eb4e24d9f745a11350fc999ff48bff45
Reviewed-on: https://go-review.googlesource.com/c/go/+/261644
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: David du Colombier <0intro@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com>
Tobias Klauser [Mon, 12 Oct 2020 13:49:59 +0000 (15:49 +0200)]
lib/time, time/tzdata: update tz data to 2020b
Set ZFLAGS="-b fat" as the default was changed to '-b slim', see
http://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
This will make sure that backwards-compatibibilty data is still emitted.
Updates #22487
Change-Id: I310a1b3a91e435673d1df41fbf8bb76abce1f94d
Reviewed-on: https://go-review.googlesource.com/c/go/+/261363
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Fri, 22 May 2020 18:46:52 +0000 (14:46 -0400)]
go/build: reject //go:build without // +build
We are converting from using error-prone ad-hoc syntax // +build lines
to less error-prone, standard boolean syntax //go:build lines.
The timeline is:
Go 1.16: prepare for transition
- Builds still use // +build for file selection.
- Source files may not contain //go:build without // +build.
- Builds fail when a source file contains //go:build lines without // +build lines. <<<
Go 1.17: start transition
- Builds prefer //go:build for file selection, falling back to // +build
for files containing only // +build.
- Source files may contain //go:build without // +build (but they won't build with Go 1.16).
- Gofmt moves //go:build and // +build lines to proper file locations.
- Gofmt introduces //go:build lines into files with only // +build lines.
- Go vet rejects files with mismatched //go:build and // +build lines.
Go 1.18: complete transition
- Go fix removes // +build lines, leaving behind equivalent // +build lines.
This CL provides part of the <<< marked line above in the Go 1.16 step:
rejecting files containing //go:build but not // +build.
For #41184.
Change-Id: I29b8a789ab1526ab5057f613d5533bd2060ba9cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/240600
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Mon, 29 Jun 2020 21:08:49 +0000 (17:08 -0400)]
cmd/asm: reject misplaced go:build comments
We are converting from using error-prone ad-hoc syntax // +build lines
to less error-prone, standard boolean syntax //go:build lines.
The timeline is:
Go 1.16: prepare for transition
- Builds still use // +build for file selection.
- Source files may not contain //go:build without // +build.
- Builds fail when a source file contains //go:build lines without // +build lines. <<<
Go 1.17: start transition
- Builds prefer //go:build for file selection, falling back to // +build
for files containing only // +build.
- Source files may contain //go:build without // +build (but they won't build with Go 1.16).
- Gofmt moves //go:build and // +build lines to proper file locations.
- Gofmt introduces //go:build lines into files with only // +build lines.
- Go vet rejects files with mismatched //go:build and // +build lines.
Go 1.18: complete transition
- Go fix removes // +build lines, leaving behind equivalent // +build lines.
This CL provides part of the <<< marked line above in the Go 1.16 step:
rejecting files containing //go:build but not // +build.
Reject any //go:build comments found after actual assembler code
(include #include etc directives), because the go command itself
doesn't read that far.
For #41184.
Change-Id: Ib460bfd380cce4239993980dd208afd07deff3f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/240602
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Fri, 22 May 2020 19:22:52 +0000 (15:22 -0400)]
cmd/compile: reject misplaced go:build comments
We are converting from using error-prone ad-hoc syntax // +build lines
to less error-prone, standard boolean syntax //go:build lines.
The timeline is:
Go 1.16: prepare for transition
- Builds still use // +build for file selection.
- Source files may not contain //go:build without // +build.
- Builds fail when a source file contains //go:build lines without // +build lines. <<<
Go 1.17: start transition
- Builds prefer //go:build for file selection, falling back to // +build
for files containing only // +build.
- Source files may contain //go:build without // +build (but they won't build with Go 1.16).
- Gofmt moves //go:build and // +build lines to proper file locations.
- Gofmt introduces //go:build lines into files with only // +build lines.
- Go vet rejects files with mismatched //go:build and // +build lines.
Go 1.18: complete transition
- Go fix removes // +build lines, leaving behind equivalent // +build lines.
This CL provides part of the <<< marked line above in the Go 1.16 step:
rejecting files containing //go:build but not // +build.
The standard go command checks only consider the top of the file.
This compiler check, along with a separate go vet check for ignored files,
handles the remainder of the file.
For #41184.
Change-Id: I014006eebfc84ab5943de18bc90449e534f150a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/240601
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ignacio Hagopian [Thu, 8 Oct 2020 20:32:50 +0000 (20:32 +0000)]
net/http/httputil: flush ReverseProxy immediately if Content-Length is -1
Finish up a prior TODO by making ReverseProxy flush immediately
if Content-Length is -1, which is a case that can occur if for
example we have a streamed response, or chunked encoding, or when
the body's length wasn't known.
Fixes #41642
Change-Id: I30babaaf3e14837b99e3ecdc562a0a0e50c579bf
GitHub-Last-Rev: efc019a9fe361082d40bee77317018c3b80451a3
GitHub-Pull-Request: golang/go#41858
Reviewed-on: https://go-review.googlesource.com/c/go/+/260637
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Michael Matloob [Tue, 6 Oct 2020 17:16:46 +0000 (13:16 -0400)]
cmd/go: support walking through overlay directories
Change-Id: I7d9d75aa1dbc34fec5073ca36091c626b9dd4920
Reviewed-on: https://go-review.googlesource.com/c/go/+/261537
Trust: Michael Matloob <matloob@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Cherry Zhang [Mon, 12 Oct 2020 19:37:21 +0000 (15:37 -0400)]
cmd/link: always mark runtime.buildVersion and runtime.modinfo reachable
runtime.buildVersion and runtime.modinfo are referenced in the
.go.buildinfo section, therefore reachable. They should normally
be reachable from the runtime. Just make it explicit, in case.
Change-Id: I60ff3132e0bbb690f4a3cba8bb18735921fbe951
Reviewed-on: https://go-review.googlesource.com/c/go/+/261637
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Russ Cox [Mon, 29 Jun 2020 14:31:03 +0000 (10:31 -0400)]
go/build: add Package.IgnoredOtherFiles
Just like it is useful to report ignored .go files,
it is also useful to report ignored non-.go files.
Also, remove _* and .* files from IgnoredGoFiles.
The fact that they were there at all was a mistake.
This list is for files being ignored due to build constraints.
Change-Id: Ie08252dde9f56bda08647e7ebeab7906e9271c54
Reviewed-on: https://go-review.googlesource.com/c/go/+/240551
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Robert Griesemer [Sat, 10 Oct 2020 00:42:41 +0000 (17:42 -0700)]
cmd/compile/internal/syntax: provide BadExpr where needed, call correct error handler
- For "if" statements without a condition, provide a BadExpr rather than nil
(clients expect IfStmt.Cond != nil since the parser is taking care of
reporting a missing condition).
- For 3-index slice expressions, also provide BadExpr where an index is
required but missing.
- Declare a parser-local error method to hide the embedded error method
so we don't use it by mistake.
Accidentally found while adjusting prototype parser to work for generics.
Change-Id: Iacc211cc60869be05efe9ae630d65dff1dac00a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/261218
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Russ Cox [Mon, 22 Jun 2020 18:45:35 +0000 (14:45 -0400)]
cmd/go: disable automatic go vet -unreachable during go test of std
go test runs a limited number of vet checks by default.
In the standard library, we run more, both to get additional checking
for the standard library and to get experience with whether to enable
any others by default.
One that experience has shown us should not be enabled by default
is go vet -unreachable. When you are testing, it is common to want to
put an early return or a panic into code to bypass a section of code.
That often causes unreachable code. It's incredibly frustrating if the
result is an "unreachable code" error that keeps your test from completing.
Change-Id: Ib194e87759eb65f5a193d771a9880b38d2fd3ba9
Reviewed-on: https://go-review.googlesource.com/c/go/+/240550
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Cherry Zhang [Sat, 10 Oct 2020 15:22:14 +0000 (11:22 -0400)]
cmd/link: only dynamically export necessary symbols on darwin
Currently on darwin, when a symbol needs to be exported, we
export it both statically and dynamically. The dynamic export is
unnecessary for some symbols. Only export the necessary ones.
For special runtime C symbols (e.g. crosscall2), they used to be
exported dynamically, and we had a special case for pclntab to
not include those symbols (otherwise, when the dynamic linker
dedup them, the pclntab entries end up pointing out of the
module's address space). This CL changes it to not export those
symbols, and remove the special case.
Change-Id: I2ab40630742d48a09b86ee150aa5f1f7002b134d
Reviewed-on: https://go-review.googlesource.com/c/go/+/261497
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jeremy Faller <jeremy@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Delete "collision-resistant but" in:
> The hash functions are collision-resistant but not cryptographically secure.
"Collision-resistant" has a precise cryptographic meaning that is
incompatible with "not cryptographically secure".
All that is really meant by it here here is "it's a good hash function",
which should be established already.
Also delete:
> The hash value of a given byte sequence is consistent within a
> single process, but will be different in different processes.
This was added for its final clause in response to #37040,
but "The hash value of a given byte sequence" is by design not a
concept in this package. Only "... of a given seed and byte sequence".
And seeds cannot be shared between processes, so again by design
you can't even set up the appropriate first half of the sentence
to say the second half.
Change-Id: I2c02bee0e804ef3b120cb4752bf89e60f3f5ff5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255968
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alberto Donizetti [Mon, 12 Oct 2020 12:35:24 +0000 (14:35 +0200)]
cmd/compile: use Bool accessor in place of Val.U.(bool)
We have a Bool() accessor for the value in boolean nodes, that we use
elsewhere for n.Val().U.(bool), use it here too. Noticed while reading
the code.
Change-Id: Ie42e014970099a05fe9f02f378af77b63e7e6b13
Reviewed-on: https://go-review.googlesource.com/c/go/+/261360
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Armv8 Reference Manual:
* EOR3 (Three-way Exclusive OR) on C7.2.42
* RAX1 (Rotate and Exclusive OR) on C7.2.217
* XAR (Exclusive OR and Rotate) on C7.2.401
* BCAX (Bit Clear and Exclusive OR) on C7.2.12
Jay Conrod [Fri, 9 Oct 2020 19:16:13 +0000 (15:16 -0400)]
cmd/go: ignore retracted versions when converting revisions to versions
When a module author retracts a version, the go command should act as
if it doesn't exist unless it's specifically requested.
When converting a revision to a version, we should ignore tags for
retracted versions. For example, if the tag v1.0.0 is retracted, and
branch B points to the same revision, we should convert B to a
pseudo-version, not v1.0.0. Similarly, if B points to a commit after
v1.0.0, we should not use v1.0.0 as the base; we can use an earlier
non-retracted tag or no base.
Fixes #41700
Change-Id: Ia596b05b0780e5acfe6616a04e94d24bd342fbae
Reviewed-on: https://go-review.googlesource.com/c/go/+/261079
Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Michael Pratt [Fri, 9 Oct 2020 16:44:07 +0000 (12:44 -0400)]
cmd/compile: drop SSA atomics TODO
These ops have been used for sync/atomic since golang.org/cl/28076.
Change-Id: Ic1445c073273f6b191b97018e8eb6f7ad9c48922
Reviewed-on: https://go-review.googlesource.com/c/go/+/261077
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>