| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Id5f76204b8cd3fe67c21c5adfd3a4e456a8cad14
Reviewed-on: https://go-review.googlesource.com/c/go/+/167704
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Change-Id: I6d3a615c5f72e9aa29d23e127af98d6e836da173
Reviewed-on: https://go-review.googlesource.com/c/go/+/167699
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit f832a97e454a5e2bed336321965fd2382b2af868)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167702
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Change-Id: I99832fa4f2c3ec28e2dad46cf7607f3766948031
Reviewed-on: https://go-review.googlesource.com/c/go/+/167698
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit d3bb45d9046bb7d12c4fc9cdaf122f36d001fd31)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167701
|
|
for versioned binaries"
This reverts commit 746edd459d26f07f69fcb6bddfafaaae7c5a2911 (CL 167384).
Reason for revert: Dmitri identified a potential problem in https://go-review.googlesource.com/c/go/+/140863/11#message-db0ff6bb2c7b06161ca47de771c4465afa8b1102, and we'd like more time to investigate without holding up the 1.12 release branch.
Updates #27283
Updates #30266
Updates #30821
Change-Id: I49d7bbbe200e80b81899c3bcbf7844717af010aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/167617
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
typedef
Fixes #30816
Updates #30646
Change-Id: I5b7e986b0588e87b9781cce01445e3c55c06b6fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/165897
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit a6436a5655f56bb904871fece7db43a3ad3bf415)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167497
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
|
|
versioned binaries
`go build` has chosen the last element of the package import path
as the default output name when -o option is given. That caused
the output of a package build when the module root is the major
version component such as 'v2'.
A similar issue involving `go install` was fixed in
https://golang.org/cl/128900. This CL refactors the logic added
with the change and makes it available as
internal/load.DefaultExecName.
This CL makes 'go test' to choose the right default test binary
name when the tested package is in the module root. (E.g.,
instead of v2.test, choose pkg.test for the test of 'path/pkg/v2')
Fixes #27283
Fixes #30266
Change-Id: I6905754f0906db46e3ce069552715f45356913ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/140863
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit bf94fc3ae387fc09929443393741919fac6727af)
Reviewed-on: https://go-review.googlesource.com/c/go/+/167384
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Trying to call a method on a nil interface is a panic in Go. For
example:
var stringer fmt.Stringer
println(stringer.String()) // nil pointer dereference
In https://golang.org/cl/143097 we started recovering panics encountered
during function and method calls. However, we didn't handle this case,
as text/template panics before evalCall is ever run.
In particular, reflect's MethodByName will panic if the receiver is of
interface kind and nil:
panic: reflect: Method on nil interface value
Simply add a check for that edge case, and have Template.Execute return
a helpful error. Note that Execute shouldn't just error if the interface
contains a typed nil, since we're able to find a method to call in that
case.
Finally, add regression tests for both the nil and typed nil interface
cases.
Fixes #30464.
Change-Id: Iffb21b40e14ba5fea0fcdd179cd80d1f23cabbab
Reviewed-on: https://go-review.googlesource.com/c/161761
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
(cherry picked from commit 15b4c71a912846530315c3e854feaaa9d0d54220)
Reviewed-on: https://go-review.googlesource.com/c/go/+/164457
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Currently, runtime.KeepAlive applied on a stack object doesn't
actually keeps the stack object alive, and the heap object
referenced from it could be collected. This is because the
address of the stack object is rematerializeable, and we just
ignored KeepAlive on rematerializeable values. This CL fixes it.
Updates #30476.
Fixes #30478.
Change-Id: Ic1f75ee54ed94ea79bd46a8ddcd9e81d01556d1d
Reviewed-on: https://go-review.googlesource.com/c/164537
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit 40df9cc6062492cd323f2251dd1583d200d1207e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/164627
|
|
Instead of trying to guess type of constants in the AST,
which is hard, use the "var cgo%d Type = Constant"
so that typechecking is left to the Go compiler.
The previous code could still fail in some cases
for constants imported from other modules
or defined in other, non-cgo files.
Fixes #30527
Change-Id: I2120cd90e90a74b9d765eeec53f6a3d2cfc1b642
Reviewed-on: https://go-review.googlesource.com/c/go/+/164897
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 711ea1e716b0c620cd9bcdd405eccae230d6dcbb)
Reviewed-on: https://go-review.googlesource.com/c/go/+/165748
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Previously, the result of sorting a map[interface{}] containing
multiple concrete types was non-deterministic. To ensure consistent
results, sort first by type name, then by concrete value.
Fixes #30484
Change-Id: I10fd4b6a74eefbc87136853af6b2e689bc76ae9d
GitHub-Last-Rev: 1b07f0c275716e1b2834f74f9c67f897bae82882
GitHub-Pull-Request: golang/go#30406
Reviewed-on: https://go-review.googlesource.com/c/163745
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 9d40fadb1c3245a318b155ee3e19a4de139401dc)
Reviewed-on: https://go-review.googlesource.com/c/go/+/164617
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Make sure the side effects inside short-circuited operations (&& and ||)
happen correctly.
Before this CL, we attached the side effects to the node itself using
exprInPlace. That caused other side effects in sibling expressions
to get reordered with respect to the short circuit side effect.
Instead, rewrite a && b like:
r := a
if r {
r = b
}
That code we can keep correctly ordered with respect to other
side-effects extracted from part of a big expression.
exprInPlace seems generally unsafe. But this was the only case where
exprInPlace is called not at the top level of an expression, so I
don't think the other uses can actually trigger an issue (there can't
be a sibling expression). TODO: maybe those cases don't need "in
place", and we can retire that function generally.
This CL needed a small tweak to the SSA generation of OIF so that the
short circuit optimization still triggers. The short circuit optimization
looks for triangle but not diamonds, so don't bother allocating a block
if it will be empty.
Go 1 benchmarks are in the noise.
Fixes #30567
Change-Id: I19c04296bea63cbd6ad05f87a63b005029123610
Reviewed-on: https://go-review.googlesource.com/c/go/+/165617
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit 4a9064ef41ccc65454564536f40cf7d5a00db8ad)
Reviewed-on: https://go-review.googlesource.com/c/go/+/165858
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
packages
The -coverpkg lets users specify a list of packages that should have
coverage instrumentation. This may include packages not transitively
imported by tests. For each tested package, the synthetic main package
imports all covered packages so they can be registered with
testing.RegisterCover. This makes it possible for a main package to
import another main package.
When we compile a package with p.Internal.BuildInfo set (set on main
packages by Package.load in module mode), we set
runtime/debug.modinfo. Multiple main packages may be passed to the
linker because of the above scenario, so this causes duplicate symbol
errors.
This change copies p.Internal.BuildInfo to the synthetic main package
instead of the internal test package. Additionally, it forces main
packages imported by the synthetic test main package to be recompiled
for testing. Recompiled packages won't have p.Internal.BuildInfo set.
Fixes #30684
Change-Id: I06f028d55905039907940ec89d2835f5a1040203
Reviewed-on: https://go-review.googlesource.com/c/go/+/164877
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 10156b678336f7628a7f1fdd84ffe2a28d66969a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/166318
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
with Go 1.11 - 1.11.3
Updates #30446
Change-Id: If069f72fa9735f839df92f3ede3bf7b6d7a695a5
Reviewed-on: https://go-review.googlesource.com/c/164317
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit e32203f647370897c6a28018c16cfd9584849569)
Reviewed-on: https://go-review.googlesource.com/c/go/+/164318
|
|
for paths with major-version suffixes
Fixes #30665
Change-Id: Icbcfdb3907bc003ac17a8c7df17ecb41daf82eb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/166117
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
(cherry picked from commit 1ab9f6837d6da80dad41657a913e47fa13a4fee8)
Reviewed-on: https://go-review.googlesource.com/c/go/+/166317
|
|
EvalSymlinks was mishandling cases like "/x/../../y" or "../../../x"
where there is an extra ".." that goes past the start of the path.
Updates #30520
Fixes #30586
Change-Id: I07525575f83009032fa1a99aa270c8d42007d276
Reviewed-on: https://go-review.googlesource.com/c/go/+/164762
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 294edb272d5d145665bdf8b4254609eae0363a8d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/165197
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Updates #30555
Fixes #30579
Change-Id: Ib894b4f3cdba23a18a69c9470cf69ceb83591a4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/165057
Run-TryBot: Baokun Lee <nototon@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit c74659290a473cf932ec6bc96bfa7e96a930676e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/165058
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
There's a "lib/time" sub-section in the Go 1.12 relase notes that
points to a non-existent golang.org/pkg/lib/time page.
The note is about a change in the tz database in the src/lib/time
directory, but the section's title (and the link) should probably just
refer to the time package.
Change-Id: Ibf9dacd710e72886f14ad0b7415fea1e8d25b83a
Reviewed-on: https://go-review.googlesource.com/c/164977
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 0dc62565401eba11bf9aec127c6c9f5aa4ecf1c9)
Reviewed-on: https://go-review.googlesource.com/c/164964
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
With stack objects, when we scan the stack, it scans defers with
tracebackdefers, but it seems to me that tracebackdefers doesn't
include the func value itself, which could be a stack allocated
closure. Scan it explicitly.
Alternatively, we can change tracebackdefers to include the func
value, which in turn needs to change the type of stkframe.
Updates #30453.
Fixes #30470.
Change-Id: I55a6e43264d6952ab2fa5c638bebb89fdc410e2b
Reviewed-on: https://go-review.googlesource.com/c/164118
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit 4f4c2a79d4f952b96d58aec2926b4c894245071b)
Reviewed-on: https://go-review.googlesource.com/c/164629
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
not an absolute path
If GOCACHE is set but is not an absolute path, we cannot build.
And GOCACHE=off also returns the error message "build cache is
disabled by GOCACHE=off".
Fixes #30493
Change-Id: I24f64bc886599ca0acd757acada4714aebe4d3ae
Reviewed-on: https://go-review.googlesource.com/c/164200
Run-TryBot: Baokun Lee <nototon@gmail.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 13d24b685a6d7b05a249f85be91c390f5595f745)
Reviewed-on: https://go-review.googlesource.com/c/164717
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Fixes #30431
Change-Id: I379e78a1c385942a19e1a10b91d732f9a73899e6
Reviewed-on: https://go-review.googlesource.com/c/164041
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit d7518ac51879011a732440d4a49dc7043759e2c8)
Reviewed-on: https://go-review.googlesource.com/c/164077
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Revert CL 137055, which changed Clean("\\somepath\dir\") to return
"\\somepath\dir" on Windows. It's not entirely clear this is correct,
as this path is really "\\server\share\", and as such the trailing
slash may be the path on that share, much like "C:\". In any case, the
change broke existing code, so roll it back for now and rethink for 1.13.
Updates #27791
Updates #30307
Change-Id: I69200b1efe38bdb6d452b744582a2bfbb3acbcec
Reviewed-on: https://go-review.googlesource.com/c/163077
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
(cherry picked from commit 153c0da89bca6726545cf4451053235b552d3d51)
Reviewed-on: https://go-review.googlesource.com/c/163078
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Go 1.12 is released, but it's currently not listed in the
https://golang.org/project page.
Change-Id: Ib5820f74245e4c986014c64eb40fa2911473e64b
Reviewed-on: https://go-review.googlesource.com/c/163837
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 467456b0afcbe8b74c49b356f0e5d41d1c6efc9f)
Reviewed-on: https://go-review.googlesource.com/c/163727
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Current assembler reports error when it assembles
"TSTW $1689262177517664, R3", but go1.11 was building
fine.
Fixes #30334
Change-Id: I9c16d36717cd05df2134e8eb5b17edc385aff0a9
Reviewed-on: https://go-review.googlesource.com/c/163259
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ben Shi <powerman1st@163.com>
(cherry picked from commit 2ef8abb41f2565e38e520c18773308b3cf005af6)
Reviewed-on: https://go-review.googlesource.com/c/163419
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Change-Id: I2fa947f75c0ace671ad8b99c4fab3ad7b178cedf
Reviewed-on: https://go-review.googlesource.com/c/163725
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Change-Id: I845375d2b3824211b80885228ba5b45503cba1a6
Reviewed-on: https://go-review.googlesource.com/c/163722
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 8bffb8546cb8ed1c849989ddf2b151edc983a616)
Reviewed-on: https://go-review.googlesource.com/c/163723
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Change-Id: Ib6a0f5c35b1efc3f3c8e7ca2a5c4f35bf8bf5e5d
Reviewed-on: https://go-review.googlesource.com/c/163720
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 9d26ec85fc5657409d415caf647b11f614dd48c8)
Reviewed-on: https://go-review.googlesource.com/c/163721
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Using go get prevents the failure case of when the
user doesn't have the repo on their machine.
Change-Id: I9c1174087728b5b06b578b0d52df6eeb7e8c7a3c
Reviewed-on: https://go-review.googlesource.com/c/163718
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 2f9728aacdf90d21a530f68c6887cfe545954935)
Reviewed-on: https://go-review.googlesource.com/c/163719
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
for mid-stack inlining tracebacks
A recent change to fix stacktraces for inlined functions
introduced a regression on ppc64le when compiling position
independent code. That happened because ginsnop2 was called for
the purpose of inserting a NOP to identify the location of
the inlined function, when ginsnop should have been used.
ginsnop2 is intended to be used before deferreturn to ensure
r2 is properly restored when compiling position independent code.
In some cases the location where r2 is loaded from might not be
initialized. If that happens and r2 is used to generate an address,
the result is likely a SEGV.
This fixes that problem.
Fixes #30283
Change-Id: If70ef27fc65ef31969712422306ac3a57adbd5b6
Reviewed-on: https://go-review.googlesource.com/c/163337
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 2d3474043cd35ba06d3566df520e8550c479944f)
Reviewed-on: https://go-review.googlesource.com/c/163717
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
offset from readonly constants
CL 154057 adds guards agaist out-of-bound reads from readonly
constants. It turns out that in dead code, the offset can also
be negative. Guard against negative offset as well.
Fixes #30257.
Change-Id: I47c2a2e434dd466c08ae6f50f213999a358c796e
Reviewed-on: https://go-review.googlesource.com/c/162819
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit dca707b2a040642bb46aa4da4fb4eb6188cc2502)
Reviewed-on: https://go-review.googlesource.com/c/162827
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
and deprecate it
Nothing in Go can truly guarantee a key will be gone from memory (see
#21865), so remove that claim. That makes Reset useless, because
unlike most Reset methods it doesn't restore the original value state,
so deprecate it.
Change-Id: I6bb0f7f94c7e6dd4c5ac19761bc8e5df1f9ec618
Reviewed-on: https://go-review.googlesource.com/c/162297
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit b35dacaac57b039205d9b07ea24098e2c3fcb12e)
Reviewed-on: https://go-review.googlesource.com/c/163438
|
|
CONVIFACE of a non-direct interface escapes
Consider the following code:
func f(x []*T) interface{} {
return x
}
It returns an interface that holds a heap copy of x (by calling
convT2I or friend), therefore x escape to heap. The current
escape analysis only recognizes that x flows to the result. This
is not sufficient, since if the result does not escape, x's
content may be stack allocated and this will result a
heap-to-stack pointer, which is bad.
Fix this by realizing that if a CONVIFACE escapes and we're
converting from a non-direct interface type, the data needs to
escape to heap.
Running "toolstash -cmp" on std & cmd, the generated machine code
are identical for all packages. However, the export data (escape
tags) differ in the following packages. It looks to me that all
are similar to the "f" above, where the parameter should escape
to heap.
io/ioutil/ioutil.go:118
old: leaking param: r to result ~r1 level=0
new: leaking param: r
image/image.go:943
old: leaking param: p to result ~r0 level=1
new: leaking param content: p
net/url/url.go:200
old: leaking param: s to result ~r2 level=0
new: leaking param: s
(as a consequence)
net/url/url.go:183
old: leaking param: s to result ~r1 level=0
new: leaking param: s
net/url/url.go:194
old: leaking param: s to result ~r1 level=0
new: leaking param: s
net/url/url.go:699
old: leaking param: u to result ~r0 level=1
new: leaking param: u
net/url/url.go:775
old: (*URL).String u does not escape
new: leaking param content: u
net/url/url.go:1038
old: leaking param: u to result ~r0 level=1
new: leaking param: u
net/url/url.go:1099
old: (*URL).MarshalBinary u does not escape
new: leaking param content: u
flag/flag.go:235
old: leaking param: s to result ~r0 level=1
new: leaking param content: s
go/scanner/errors.go:105
old: leaking param: p to result ~r0 level=0
new: leaking param: p
database/sql/sql.go:204
old: leaking param: ns to result ~r0 level=0
new: leaking param: ns
go/constant/value.go:303
old: leaking param: re to result ~r2 level=0, leaking param: im to result ~r2 level=0
new: leaking param: re, leaking param: im
go/constant/value.go:846
old: leaking param: x to result ~r1 level=0
new: leaking param: x
encoding/xml/xml.go:518
old: leaking param: d to result ~r1 level=2
new: leaking param content: d
encoding/xml/xml.go:122
old: leaking param: leaking param: t to result ~r1 level=0
new: leaking param: t
crypto/x509/verify.go:506
old: leaking param: c to result ~r8 level=0
new: leaking param: c
crypto/x509/verify.go:563
old: leaking param: c to result ~r3 level=0, leaking param content: c
new: leaking param: c
crypto/x509/verify.go:615
old: (nothing)
new: leaking closure reference c
crypto/x509/verify.go:996
old: leaking param: c to result ~r1 level=0, leaking param content: c
new: leaking param: c
net/http/filetransport.go:30
old: leaking param: fs to result ~r1 level=0
new: leaking param: fs
net/http/h2_bundle.go:2684
old: leaking param: mh to result ~r0 level=2
new: leaking param content: mh
net/http/h2_bundle.go:7352
old: http2checkConnHeaders req does not escape
new: leaking param content: req
net/http/pprof/pprof.go:221
old: leaking param: name to result ~r1 level=0
new: leaking param: name
cmd/internal/bio/must.go:21
old: leaking param: w to result ~r1 level=0
new: leaking param: w
Fixes #29353.
Change-Id: I7e7798ae773728028b0dcae5bccb3ada51189c68
Reviewed-on: https://go-review.googlesource.com/c/162829
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit 0349f29a55fc194e3d51f748ec9ddceab87a5668)
Reviewed-on: https://go-review.googlesource.com/c/163203
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
certificates in TLS 1.2
In https://golang.org/cl/160998, RSA-PSS was disabled for
(most of) TLS 1.2. One place where we can't disable it is in a Client
Hello which offers both TLS 1.2 and 1.3: RSA-PSS is required by TLS 1.3,
so to offer TLS 1.3 we need to offer RSA-PSS, even if the server might
select TLS 1.2.
The good news is that we want to disable RSA-PSS mostly when we are the
signing side, as that's where broken crypto.Signer implementations will
bite us. So we can announce RSA-PSS in the Client Hello, tolerate the
server picking TLS 1.2 and RSA-PSS for their signatures, but still not
do RSA-PSS on our side if asked to provide a client certificate.
Client-TLSv12-ClientCert-RSA-PSS-Disabled changed because it was indeed
actually using RSA-PSS.
Updates #30055
Change-Id: I5ecade744b666433b37847abf55e1f08089b21d4
Reviewed-on: https://go-review.googlesource.com/c/163039
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
|
|
Change-Id: I6e7035db4b3e2a09e5655eb7646eea9d99fb7118
Reviewed-on: https://go-review.googlesource.com/c/162917
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 4c89a10fb9f4fcb2ed01b6e7325e53b4bc487fc2)
Reviewed-on: https://go-review.googlesource.com/c/162889
Reviewed-by: Zhou Peng <p@ctriple.cn>
|
|
ASCII CTLs
Updates #27302
Updates #22907
Change-Id: Iac6957f3517265dfb9c662efb7af31192e3bfd6c
Reviewed-on: https://go-review.googlesource.com/c/162960
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit ef454fd586ee30d8b35b5895320619ebde2beb98)
Reviewed-on: https://go-review.googlesource.com/c/162826
|
|
message
Updates #30263
Change-Id: Iefb3d8baf815c19eaf915a59048e1da799ca0cdf
Reviewed-on: https://go-review.googlesource.com/c/162957
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit e1acd854f754f496be341211e9deee53fc7e3404)
Reviewed-on: https://go-review.googlesource.com/c/162958
|
|
mounted nosuid
Fixes #30258
Change-Id: I73b63eb9d3aca00f562fdc3af010e96269bb6b9c
Reviewed-on: https://go-review.googlesource.com/c/162891
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
(cherry picked from commit 5fcc24074f8e48cd8404bd250c2c268aca2bc3d2)
Reviewed-on: https://go-review.googlesource.com/c/162818
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
|
|
Change-Id: I15279e4aa9306bde925929907a7b5e7ef5d8b642
GitHub-Last-Rev: 6bc2d66aecd424b322ec0c23b280e74cb22e08c3
GitHub-Pull-Request: golang/go#30193
Reviewed-on: https://go-review.googlesource.com/c/162018
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 1edd2a34c1bcf2133b659878e8b59e401eb8cc24)
Reviewed-on: https://go-review.googlesource.com/c/162359
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
removal text
Change-Id: I46fa43f6c5ac49386f4622e1363d8976f49c0894
Reviewed-on: https://go-review.googlesource.com/c/162019
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit c75ee696c341cef94b00409b3692f3df82af1c71)
Reviewed-on: https://go-review.googlesource.com/c/162357
|
|
include godoc
Updates #30029
Change-Id: I88e09035d675e7a6855ada0262eb42636c9822cc
Reviewed-on: https://go-review.googlesource.com/c/162417
Reviewed-by: Andrew Bonventre <andybons@golang.org>
(cherry picked from commit 7cf31d8f4116420e396c5e8690c043b2ce83f90a)
Reviewed-on: https://go-review.googlesource.com/c/162557
|
|
Fstatat
Updates #30197
Change-Id: I08b592fbd477d6879eb5d3b7fcbbc8322ea90103
Reviewed-on: https://go-review.googlesource.com/c/162078
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit cf4dc25503e6fb630280f8de0f11112aecb94b57)
Reviewed-on: https://go-review.googlesource.com/c/162197
|
|
Change-Id: I6801676335924414ce50249df2b7bea08886b203
Reviewed-on: https://go-review.googlesource.com/c/162360
Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit 48bb61166711f47eb401f245c704a5a4887d4503)
Reviewed-on: https://go-review.googlesource.com/c/162497
|
|
In runtime.gopanic, the _panic object p is stack allocated and
referenced from gp._panic. With stack objects, p on stack is dead
at the point preprintpanics runs. gp._panic points to p, but
stack scan doesn't look at gp. Heap scan of gp does look at
gp._panic, but it stops and ignores the pointer as it points to
the stack. So whatever p points to may be collected and clobbered.
We need to scan gp._panic explicitly during stack scan.
To test it reliably, we introduce a GODEBUG mode "clobberfree",
which clobbers the memory content when the GC frees an object.
Fixes #30150.
Change-Id: I11128298f03a89f817faa221421a9d332b41dced
Reviewed-on: https://go-review.googlesource.com/c/161778
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit af8f4062c24cb36af4dc24fbaffd23aa7f7bde36)
Reviewed-on: https://go-review.googlesource.com/c/162358
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
Updates #30199
Change-Id: Ib4586e3facb8c0985c8882482d94843b648b9d2f
Reviewed-on: https://go-review.googlesource.com/c/162257
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit ffd096db2b1cff6399eb1f86e5652564ee8ee362)
Reviewed-on: https://go-review.googlesource.com/c/162238
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Change-Id: Iac838b852061a8469e4e201670a589fa2bed9f04
Reviewed-on: https://go-review.googlesource.com/c/161900
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Fixes #30166
Change-Id: I4704b57ed48197f512cd1b818e1f7d2fffc0d9ce
Reviewed-on: https://go-review.googlesource.com/c/161898
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
install.html still insisted that GOROOT must be set if a binary install
of Go is set up in a custom directory. However, since 1.10, this has
been unnecessary as the GOROOT will be found based on the location of
the 'go' binary being run.
Likewise, install-source.html includes an 'export GOROOT' line in a
section that only talks about explicitly setting GOARCH and GOOS, which
is optional. We don't want to have users think it is recommended to set
GOROOT here either, so remove the unnecessary line.
Change-Id: I7dfef09f9a1d003e0253b793d63ea40d5cf1837f
Reviewed-on: https://go-review.googlesource.com/c/161758
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
runtime/internal/atomic/atomic_mipsx.go enforces 64-bit alignment.
Change-Id: Ifdc36e1c0322827711425054d10f1c52425a13fa
Reviewed-on: https://go-review.googlesource.com/c/161697
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Change-Id: I46046cddceff2d44a7b2517db1ebf7acdf5f2b90
GitHub-Last-Rev: 7fb9f26476d2764f07d068ce612bf79b1e7f44b4
GitHub-Pull-Request: golang/go#30144
Reviewed-on: https://go-review.googlesource.com/c/161718
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
When prepared on a DB, prepared statement code in database/sql handles everything to keep the prepared statement alive as it moves across the connection pool. Understanding this is an important part of using this API correctly, but it was only documented indirectly via `(*Tx) Prepare*`.
Change-Id: Ic8757e0150d59e675d9f0252f6c15aef2cc2e831
GitHub-Last-Rev: 55dba87458542cb631baac80aeea0c3607d8f421
GitHub-Pull-Request: golang/go#29890
Reviewed-on: https://go-review.googlesource.com/c/159077
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
|
|
Most of the issues that led to the decision on #30055 were related to
incompatibility with or faulty support for RSA-PSS (#29831, #29779,
v1.5 signatures). RSA-PSS is required by TLS 1.3, but is also available
to be negotiated in TLS 1.2.
Altering TLS 1.2 behavior based on GODEBUG=tls13=1 feels surprising, so
just disable RSA-PSS entirely in TLS 1.2 until TLS 1.3 is on by default,
so breakage happens all at once.
Updates #30055
Change-Id: Iee90454a20ded8895e5302e8bcbcd32e4e3031c2
Reviewed-on: https://go-review.googlesource.com/c/160998
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
|
