Bryan C. Mills [Thu, 21 Feb 2019 17:34:27 +0000 (12:34 -0500)]
misc/cgo/testcarchive: fix tests in module mode
Updates #30228
Change-Id: I830e3c83416b2e5744f30d1a903a74c50462716b
Reviewed-on: https://go-review.googlesource.com/c/163210
Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Filippo Valsorda [Wed, 13 Feb 2019 08:37:57 +0000 (03:37 -0500)]
crypto/rc4: remove false guarantees from Reset docs 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.
fanzha02 [Thu, 21 Feb 2019 07:53:15 +0000 (07:53 +0000)]
cmd/internal/obj/arm64: fix the bug assembling TSTW
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 Zhang [Mon, 18 Feb 2019 04:12:55 +0000 (23:12 -0500)]
cmd/compile: flow interface data to heap if 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>
Herbie Ong [Wed, 20 Feb 2019 19:30:14 +0000 (11:30 -0800)]
go/build: add go1.13 release tag
Adding this early in the cycle to start regression testing in the master
toolchain.
Change-Id: Ia151429c4f94efbac0aa41ab6bc16e7462b0e303
Reviewed-on: https://go-review.googlesource.com/c/163082
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Wed, 20 Feb 2019 18:44:52 +0000 (10:44 -0800)]
text/scanner: don't liberally consume (invalid) floats or underbars
This is a follow-up on https://golang.org/cl/161199 which introduced
the new Go 2 number literals to text/scanner.
That change introduced a bug by allowing decimal and hexadecimal floats
to be consumed even if the scanner was not configured to accept floats.
This CL changes the code to not consume a radix dot '.' or exponent
unless the scanner is configured to accept floats.
This CL also introduces a new mode "AllowNumberbars" which controls
whether underbars '_' are permitted as digit separators in numbers
or not.
There is a possibility that we may need to refine text/scanner
further (e.g., the Float mode now includes hexadecimal floats
which it didn't recognize before). We're very early in the cycle,
so let's see how it goes.
Change-Id: I6481d314f0384e09ef6803ffad38dc529b1e89a3
Reviewed-on: https://go-review.googlesource.com/c/163079 Reviewed-by: Ian Lance Taylor <iant@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.
Robert Griesemer [Fri, 15 Feb 2019 01:34:29 +0000 (17:34 -0800)]
cmd/compile: accept 'i' suffix orthogonally on all numbers
This change accepts the 'i' suffix on binary and octal integer
literals as well as hexadecimal floats. The suffix was already
accepted on decimal integers and floats.
Note that 0123i == 123i for backward-compatibility (and 09i is
valid).
See also the respective language in the spec change:
https://golang.org/cl/161098
Change-Id: I9d2d755cba36a3fa7b9e24308c73754d4568daaf
Reviewed-on: https://go-review.googlesource.com/c/162878
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Fri, 15 Feb 2019 01:53:14 +0000 (17:53 -0800)]
go/scanner: accept 'i' suffix orthogonally on all numbers
This change accepts the 'i' suffix on binary and octal integer
literals as well as hexadecimal floats. The suffix was already
accepted on decimal integers and floats.
See also the respective language in the spec change:
https://golang.org/cl/161098
Change-Id: I0c182bdf58f8fd1f70090e581b3ccb2f5e2e4e79
Reviewed-on: https://go-review.googlesource.com/c/162880 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Sun, 17 Feb 2019 23:35:52 +0000 (15:35 -0800)]
cmd/compile: don't mix internal float/complex constants of different precision
There are several places where a new (internal) complex constant is allocated
via new(Mpcplx) rather than newMpcmplx(). The problem with using new() is that
the Mpcplx data structure's Real and Imag components don't get initialized with
an Mpflt of the correct precision (they have precision 0, which may be adjusted
later).
In all cases but one, the components of those complex constants are set using
a Set operation which "inherits" the correct precision from the value that is
being set.
But when creating a complex value for an imaginary literal, the imaginary
component is set via SetString which assumes 64bits of precision by default.
As a result, the internal representation of 0.01i and complex(0, 0.01) was
not correct.
Replaced all used of new(Mpcplx) with newMpcmplx() and added a new test.
Fixes #30243.
Change-Id: Ife7fd6ccd42bf887a55c6ce91727754657e6cb2d
Reviewed-on: https://go-review.googlesource.com/c/163000
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Robert Griesemer [Thu, 14 Feb 2019 00:38:01 +0000 (16:38 -0800)]
cmd/gofmt: normalize integer imaginary literals starting with 0
An 'i' suffix on an integer literal marks the integer literal as
a decimal integer imaginary value, even if the literal without the
suffix starts with a 0 and thus looks like an octal value:
0123i == 123i // != 0123 * 1i
This is at best confusing, and at worst a potential source of bugs.
It is always safe to rewrite such literals into the equivalent
literal without the leading 0.
This CL implements this normalization.
Change-Id: Ib77ad535f98b5be912ecbdec20ca1b472c1b4973
Reviewed-on: https://go-review.googlesource.com/c/162538
Run-TryBot: Robert Griesemer <gri@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Thu, 24 Jan 2019 04:47:44 +0000 (20:47 -0800)]
go/types: include test/fixedbugs/bug073.go again in test
This test was excluded from the go/types std lib test
because it tested old behavior (shift count must be
an unsigned int). With the compiler changes made and
the test adjusted accordingly, we can include it again.
Cherry Zhang [Fri, 15 Feb 2019 20:01:29 +0000 (15:01 -0500)]
cmd/compile: guard against loads with negative 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>
Brad Fitzpatrick [Fri, 15 Feb 2019 23:42:32 +0000 (23:42 +0000)]
doc/go1.12: document net/url.Parse now rejecting 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>
Keith Randall [Sun, 20 Jan 2019 18:52:11 +0000 (10:52 -0800)]
cmd/compile: implement shifts by signed amounts
Allow shifts by signed amounts. Panic if the shift amount is negative.
TODO: We end up doing two compares per shift, see Ian's comment
https://github.com/golang/go/issues/19113#issuecomment-443241799 that
we could do it with a single comparison in the normal case.
The prove pass mostly handles this code well. For instance, it removes the
<0 check for cases like this:
if s >= 0 { _ = x << s }
_ = x << len(a)
This case isn't handled well yet:
_ = x << (y & 0xf)
I'll do followon CLs for unhandled cases as needed.
Bryan C. Mills [Wed, 13 Feb 2019 22:37:50 +0000 (17:37 -0500)]
cmd/go: only generate a go.mod file during 'go mod init'
In the general case, we do not know the correct module path for a new
module unless we have checked its VCS tags for a major version. If we
do not know the correct path, then we should not synthesize a go.mod
file automatically from it.
On the other hand, we don't want to run VCS commands in the working
directory without an explicit request by the user to do so: 'go mod
init' can reasonably invoke a VCS command, but 'go build' should not.
Therefore, we should only create a go.mod file during 'go mod init'.
This change removes the previous behavior of synthesizing a file
automatically, and instead suggests a command that the user can opt to
run explicitly.
Updates #29433
Updates #27009
Updates #30228
Change-Id: I8c4554969db17156e97428df220b129a4d361040
Reviewed-on: https://go-review.googlesource.com/c/162699
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Emmanuel T Odeke [Sun, 9 Dec 2018 07:32:15 +0000 (23:32 -0800)]
net/http/httputil: make TestDumpRequest idempotent
TestDumpRequest was failing with -count=2 or more
because for test cases that involved mustReadRequest,
the body was created as a *bufio.Reader. DumpRequest
and DumpRequestOut would then read the body until EOF
and would close it after use.
However, on re-runs of the test, the body would
be terminally exhausted and result in an unexpected
error "http: invalid Read on closed Body".
The update to the test cases adds an extra field "GetReq"
which allows us to construct requests per run of the tests
and hence make the test indefinitely re-runnable/idempotent.
"Req" or "GetReq" are mutually exclusive: either one of them
can be set or nil, but not both.
Cherry Zhang [Sun, 10 Feb 2019 04:31:59 +0000 (23:31 -0500)]
runtime: scan gp._panic in stack scan
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.
Brad Fitzpatrick [Tue, 12 Feb 2019 18:33:24 +0000 (18:33 +0000)]
doc/go1.12: soften, expand crypto/rc4 assembly 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>
Russ Cox [Wed, 30 Jan 2019 01:59:33 +0000 (20:59 -0500)]
strconv: accept underscores in ParseInt, ParseUint, ParseFloat
This CL modifies ParseInt, ParseUint, and ParseFloat
to accept digit-separating underscores in their arguments.
For ParseInt and ParseUint, the underscores are only
allowed when base == 0.
See golang.org/design/19308-number-literals for background.
Robert Griesemer [Thu, 24 Jan 2019 02:10:54 +0000 (18:10 -0800)]
go/types: permit signed integer shift count
Permit shifts by non-constant signed integer shift counts.
Share logic for constant shift counts in non-constant
shifts and improve error messages a little bit.
R=Go1.13
Updates #19113.
Change-Id: Ia01d83ca8aa60a6a3f4c49f026e0c46396f852be
Reviewed-on: https://go-review.googlesource.com/c/159317
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
Robert Griesemer [Tue, 5 Feb 2019 20:42:46 +0000 (12:42 -0800)]
text/scanner: accept new Go2 number literals
This CL introduces text/scanner support for the new binary and octal integer
literals, hexadecimal floats, and digit separators for all number literals.
The new code is closely mirroring the respective code for number literals in
cmd/compile/internal/syntax/scanner.go.
Uniformly use the term "invalid" rather than "illegal" in error messages
to match the respective error messages in the other scanners directly.
Robert Griesemer [Mon, 11 Feb 2019 22:27:43 +0000 (14:27 -0800)]
cmd/compile: do not export float or complex constants with -asmhdr
The -asmhdr flag is used to generate header files for assembly code
such that that code has access to compile-time constants. During
the build these constants end up in the (ephemeral) file go_asm.h.
For historical reasons, floating-point and complex constants are
printed with a 'p' exponent but with decimal mantissa; also, because
of the compiler-internal precision of 512 bits, the mantissae are quite
large (and conversions are comparatively slow).
With the changes to the new Go 2 number literals, the respective
upcoming changes to text/scanner (which in turn is used by the assembler)
will make text/scanner newly accept hexadecimal floats; but also decimal
floats using the incorrect 'p' exponent and report an error in that case.
As a consequence, the assembler will report an error when trying to parse
the before-mentioned decimal floating-point values which are using 'p'
exponents. Since these constants are never needed in the assembly code,
do not emit them in the first place.
Change-Id: I06c7c96b04e8d062441120107992472f87a651b2
Reviewed-on: https://go-review.googlesource.com/c/161904
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Mon, 14 Jan 2019 21:34:42 +0000 (13:34 -0800)]
text/scanner: don't crash when calling TokenText in error handler
Make sure Scanner.tokEnd is set before we call Scanner.Error
and update documentation accordingly.
(Until now tokEnd was only set before returning from Scan,
so a call to TokenText during error handling may have crashed.)
While at it, tighten a check in Scanner.TokenText to ensure
Scanner.tokEnd >= Scanner.tokPos if we have a token.
Also, silence error messages to Stderr in unrelated TestIllegalExponent.
Robert Griesemer [Wed, 30 Jan 2019 06:12:13 +0000 (22:12 -0800)]
cmd/gofmt: normalize number prefixes and exponents
Rewrite non-decimal number prefixes to always use a lower-case base
("0X" -> "0x", etc.), and rewrite exponents to use a lower-case 'e'
or 'p'. Leave hexadecimal digits and 0-octals alone.
Comparing the best time of 3 runs of `time go test -run All` with
the time for a gofmt that doesn't do the rewrite shows no increase
in runtime for this bulk gofmt application (in fact on my machine
I see a small decline, probably due to cache effects).
R=Go1.13
Updates #12711.
Updates #19308.
Updates #29008.
Change-Id: I9c6ebed2ffa0a6a001c59412a73382090955f5a9
Reviewed-on: https://go-review.googlesource.com/c/160184 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Wed, 30 Jan 2019 00:00:45 +0000 (16:00 -0800)]
go/types: add tests for new Go 2 number literals
This CL ensures that go/types can now handle the new
Go 2 number literals. The relevant changes enabling
them in go/types were made in go/constant in the CL
https://golang.org/cl/160239.
Robert Griesemer [Tue, 29 Jan 2019 23:41:50 +0000 (15:41 -0800)]
go/constant: accept new Go2 number literals
This CL introduces go/constant support for the new binary and octal integer
literals, hexadecimal floats, and digit separators for all number literals.
Robert Griesemer [Mon, 28 Jan 2019 23:29:23 +0000 (15:29 -0800)]
go/scanner: accept new Go2 number literals
This CL introduces go/scanner support for the new binary and octal integer
literals, hexadecimal floats, and digit separators for all number literals.
The new code is closely mirroring the respective code for number literals in
cmd/compile/internal/syntax/scanner.go.
If the number starts with "0x" or "0X", digit is any hexadecimal digit;
otherwise, digit is any decimal digit. If the accepted number is not valid,
errors are reported accordingly.
See the new test cases in scanner_test.go for a selection of valid and
invalid numbers and the respective error messages.
Robert Griesemer [Tue, 22 Jan 2019 23:20:50 +0000 (15:20 -0800)]
cmd/compile/internal/syntax: allow more than one rune "unread"
Make it possible to "unread" more than one byte before the most
recently read rune. Use a better name than ungetr2 and make it
slightly more efficient.
Daniel Martí [Fri, 8 Feb 2019 11:22:48 +0000 (11:22 +0000)]
doc: remove last pieces of advice to set GOROOT
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>
Justin Li [Wed, 23 Jan 2019 15:15:06 +0000 (15:15 +0000)]
database/sql: document Stmt lifetime
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*`.
Filippo Valsorda [Tue, 5 Feb 2019 20:27:56 +0000 (15:27 -0500)]
crypto/tls: disable RSA-PSS in TLS 1.2
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.
Filippo Valsorda [Mon, 4 Feb 2019 23:08:43 +0000 (18:08 -0500)]
crypto/x509: consider parents by Subject if AKID has no match
If a certificate somehow has an AKID, it should still chain successfully
to a parent without a SKID, even if the latter is invalid according to
RFC 5280, because only the Subject is authoritative.
This reverts to the behavior before #29233 was fixed in 770130659. Roots
with the right subject will still be shadowed by roots with the right
SKID and the wrong subject, but that's been the case for a long time, and
is left for a more complete fix in Go 1.13.
Updates #30079
Change-Id: If8ab0179aca86cb74caa926d1ef93fb5e416b4bb
Reviewed-on: https://go-review.googlesource.com/c/161097 Reviewed-by: Adam Langley <agl@golang.org>
Yasser Abdolmaleki [Wed, 6 Feb 2019 06:14:44 +0000 (22:14 -0800)]
test/chan: fix broken link to Squinting at Power Series
Change-Id: Idee94a1d93555d53442098dd7479982e3f5afbba
Reviewed-on: https://go-review.googlesource.com/c/161339 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
alkesh26 [Tue, 5 Feb 2019 10:05:10 +0000 (10:05 +0000)]
doc: fix a typo
Change-Id: Ia830f59d6f6ca1bc506ec298ccfc154d9f94f01d
GitHub-Last-Rev: 3ab18d4fd1a8d4295713cbb7ff74f30b3838b6d3
GitHub-Pull-Request: golang/go#30067
Reviewed-on: https://go-review.googlesource.com/c/160829
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Keith Randall [Fri, 1 Feb 2019 23:27:53 +0000 (15:27 -0800)]
cmd/compile: fix crash when memmove argument is not the right type
Make sure the argument to memmove is of pointer type before we try to
get the element type.
This has been noticed for code that uses unsafe+linkname so it can
call runtime.memmove. Probably not the best thing to allow, but the
code is out there and we'd rather not break it unnecessarily.
Fixes #30061
Change-Id: I334a8453f2e293959fd742044c43fbe93f0b3d31
Reviewed-on: https://go-review.googlesource.com/c/160826
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Yuval Pavel Zholkover [Fri, 1 Feb 2019 11:51:31 +0000 (13:51 +0200)]
cmd/cgo: ignore unrecognized GCC warning group pragmas
CL 159859 causes build failure with old clang versions (3.4.1) on FreeBSD 10.3/10.4.
Update #29962
Update #27619
Change-Id: I78264ac5d8d17eeae89a982e89aac988eb22b286
Reviewed-on: https://go-review.googlesource.com/c/160777
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Anthony Knyszek [Tue, 29 Jan 2019 19:58:29 +0000 (19:58 +0000)]
runtime: add credit system for scavenging
When scavenging small amounts it's possible we over-scavenge by a
significant margin since we choose to scavenge the largest spans first.
This over-scavenging is never accounted for.
With this change, we add a scavenge credit pool, similar to the reclaim
credit pool. Any time scavenging triggered by RSS growth starts up, it
checks if it can cash in some credit first. If after using all the
credit it still needs to scavenge, then any extra it does it adds back
into the credit pool.
This change mitigates the performance impact of golang.org/cl/159500 on
the Garbage benchmark. On Go1 it suggests some improvements, but most of
that is within the realm of noise (Revcomp seems very sensitive to
GC-related changes, both postively and negatively).
Michael Anthony Knyszek [Fri, 25 Jan 2019 17:40:40 +0000 (17:40 +0000)]
runtime: scavenge memory upon allocating from scavenged memory
Because scavenged and unscavenged spans no longer coalesce, memory that
is freed no longer has a high likelihood of being re-scavenged. As a
result, if an application is allocating at a fast rate, it may work fast
enough to undo all the scavenging work performed by the runtime's
current scavenging mechanisms. This behavior is exacerbated by the
global best-fit allocation policy the runtime uses, since scavenged
spans are just as likely to be chosen as unscavenged spans on average.
To remedy that, we treat each allocation of scavenged space as a heap
growth, and scavenge other memory to make up for the allocation.
This change makes performance of the runtime slightly worse, as now
we're scavenging more often during allocation. The regression is
particularly obvious with the garbage benchmark (3%) but most of the Go1
benchmarks are within the margin of noise. A follow-up change should
help.
Ian Lance Taylor [Mon, 28 Jan 2019 20:31:55 +0000 (12:31 -0800)]
cmd/cgo: disable GCC 9 warnings triggered by cgo code
GCC 9 has started emitting warnings when taking the address of a field
in a packed struct may cause a misaligned pointer. We use packed
structs in cgo to ensure that our field layout matches the C
compiler's layout. Our pointers are always aligned, so disable the warning
Fixes #29962
Change-Id: I7e290a7cf694a2c2958529e340ebed9fcd62089c
Reviewed-on: https://go-review.googlesource.com/c/159859
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Dmitri Shuralyov [Tue, 29 Jan 2019 18:58:21 +0000 (13:58 -0500)]
CONTRIBUTORS: second round of updates for Go 1.12
This update has been automatically generated using the updatecontrib
command at CL 160277:
cd gotip
go run golang.org/x/build/cmd/updatecontrib
Actions taken (relative to CONTRIBUTORS at origin/master):
Added Aaron Cannon <cannona@fireantproductions.com>
Added Andzej Maciusovic <andzej.maciusovic@gmail.com>
Added Douglas Danger Manley <doug.manley@gmail.com>
Added Federico Bond <federicobond@gmail.com>
Added Frew Schmidt <github@frew.co>
Added GitHub User @saitarunreddy (21041941) <saitarunreddypalla@gmail.com>
Added GitHub User @tell-k (26263) <ffk2005@gmail.com>
Added Guilherme Caruso <gui.martinscaruso@gmail.com>
Added Jay Taylor <outtatime@gmail.com>
Added Juan Pablo Civile <elementohb@gmail.com>
Added Julien Kauffmann <julien.kauffmann@freelan.org>
Added Maya Rashish <maya@NetBSD.org>
Added Parminder Singh <parmsingh101@gmail.com>
Added Peter Dotchev <dotchev@gmail.com>
Added Quinten Yearsley <qyearsley@chromium.org>
Added Ross Smith II <ross@smithii.com>
Added Sean Chen <oohcode@gmail.com>
Added Sebastiaan van Stijn <github@gone.nl>
Added Sebastian Schmidt <yath@google.com>
Added Sebastien Williams-Wynn <sebastien@cytora.com>
Added Viacheslav Poturaev <vearutop@gmail.com>
Added Yohei Takeda <yo.tak0812@gmail.com>
Used GitHub User @saitarunreddy (21041941) form for saitarunreddy <saitarunreddypalla@gmail.com> https://github.com/golang/build/commit/269e03a [build]
Used GitHub User @tell-k (26263) form for tell-k <ffk2005@gmail.com> https://github.com/golang/tools/commit/85a87a81 [tools]
Used GitHub name "Akhil Indurti" for smasher164 <aindurti@gmail.com> https://github.com/golang/go/commit/a7af474359 [build go]
Used GitHub name "Guilherme Caruso" for GuilhermeCaruso <gui.martinscaruso@gmail.com> https://github.com/golang/go/commit/5fae09b738 [go]
Used GitHub name "Ivan Markin" for nogoegst <nogoegst@users.noreply.github.com> https://github.com/golang/go/commit/a1addf15df [go]
Used GitHub name "Keiji Yoshida" for yosssi <yoshida.keiji.84@gmail.com> https://github.com/golang/lint/commit/ac6833c [lint]
Used GitHub name "Marwan Sulaiman" for marwan-at-work <marwan.sameer@gmail.com> https://github.com/golang/go/commit/92caeef892 [go]
Used GitHub name "Michalis Kargakis" for kargakis <mkargaki@redhat.com> https://github.com/golang/go/commit/e243d242d7 [go]
Used GitHub name "Robin Eklind" for mewmew <rnd0x00@gmail.com> https://github.com/golang/go/commit/b8620afb8d [go proposal.git]
Used GitHub name "Sean Chen" for two <oohcode@gmail.com> https://github.com/golang/sys/commit/302c3dd [sys]
Used GitHub name "Sebastien Williams-Wynn" for GiantsLoveDeathMetal <sebastien@cytora.com> https://github.com/golang/go/commit/4e056ade24 [go]
Used GitHub name "Yohei Takeda" for yo-tak <yo.tak0812@gmail.com> https://github.com/golang/go/commit/8b7cf898af [go]
Given that the scope of updatecontrib is only to add contributors to
CONTRIBUTORS file, without having to check CLAs or deal with legal
matters, we can relax the requirement of having a space in the name
before it gets added to the CONTRIBUTORS file. That will be done
in a later change.
Ian Lance Taylor [Wed, 30 Jan 2019 00:34:27 +0000 (16:34 -0800)]
os: make openFdAt act like openFileNolog
- add EINTR loop on Darwin
- return PathError on error
- call newFile rather than NewFile
This tries to minimize the possibility of any future changes.
It would be nice to put openFdAt in the same file as openFileNolog,
but build tags forbid.
Updates #29983
Change-Id: I866002416d6473fbfd80ff6ef09b2bc4607f2934
Reviewed-on: https://go-review.googlesource.com/c/160181
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
kim yongbin [Thu, 27 Dec 2018 02:33:15 +0000 (11:33 +0900)]
doc/go1.12: add notes about 'go doc -src'
Change-Id: Iaf67fcbb145277327e24150b29ff38f6c65f6a03
Reviewed-on: https://go-review.googlesource.com/c/155781 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Mon, 28 Jan 2019 02:03:32 +0000 (21:03 -0500)]
cmd/link: fix confusing error on unresolved symbol
Currently, if an assembly file includes a static reference to an
undefined symbol, and another package also has an undefined reference
to that symbol, the linker can report an error like:
x: relocation target zero not defined for ABI0 (but is defined for ABI0)
Since the symbol is referenced in another package, the code in
ErrorUnresolved that looks for alternative ABI symbols finds that
symbol in the symbol table, but doesn't check that it's actually
defined, which is where the "but is defined for ABI0" comes from. The
"not defined for ABI0" is because ErrorUnresolved failed to turn the
static symbol's version back into an ABI, and it happened to print the
zero value for an ABI.
This CL fixes both of these problems. It explicitly maps the
relocation version back to an ABI and detects if it can't be mapped
back (e.g., because it's a static reference). Then, if it finds a
symbol with a different ABI in the symbol table, it checks to make
sure it's a definition, and not simply an unresolved reference.
Fixes #29852.
Change-Id: Ice45cc41c1907919ce5750f74588e8047eaa888c
Reviewed-on: https://go-review.googlesource.com/c/159518
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>