Keith Randall [Fri, 17 May 2019 20:31:12 +0000 (13:31 -0700)]
testing: callerName only needs one PC in the traceback
callerName requested 2 PCs from Callers, and that causes
both to be looked up in the file/line mapping.
We really only need to do the work for one PC.
(And in fact the caller doesn't need file/line at all, but
the Callers API can't express that.)
We used to request 2 PCs because in 1.11 and earlier we
stored an inline skip count in the second entry.
That's not necessary any more (as of 1.12).
Fixes #32093
Change-Id: I7b272626ef6496e848ee8af388cdaafd2556857b
Reviewed-on: https://go-review.googlesource.com/c/go/+/177858
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Caleb Spare <cespare@gmail.com>
Filippo Valsorda [Fri, 17 May 2019 16:00:05 +0000 (12:00 -0400)]
crypto/tls: fix TestVerifyHostnameResumed
In TLS 1.3 session tickets are delivered after the handshake, and it
looks like now the Google servers wait until the first flight of data to
send them (or our timeout is too low). Cause some data to be sent so we
can avoid the guessing game.
Dmitri Shuralyov [Sun, 12 May 2019 23:21:33 +0000 (19:21 -0400)]
net/http/httputil: remove os.Stderr claim in ReverseProxy.ErrorLog docs
The motivation for doing so is to avoid making inaccurate claims.
Logging may not go to os.Stderr if anyone overrides the log package's
default output via https://godoc.org/log#SetOutput. Saying that
the standard logger is used should be sufficient to explain the
behavior, and users can infer that os.Stderr is used by default,
unless it's changed.
This change is the same as what was applied to http.Server.ErrorLog
documentation in CL 53950.
Jay Conrod [Wed, 15 May 2019 16:47:05 +0000 (12:47 -0400)]
cmd/go: don't attempt to downgrade to incompatible versions
When we downgrade a module (using 'go get m@none' or similar), we
exclude versions of other modules that depend on it. We'll try
previous versions (in the "versions" list returned by the proxy or in
codeRepo.Versions for vcs) until we find a version that doesn't
require an excluded module version.
If older versions of a module are broken for some reason,
mvs.Downgrade currently panics. With this change, we ignore versions
with errors during downgrade.
A frequent cause of this is incompatible v2+ versions. These are
common if a repository tagged v2.0.0 before migrating to modules, then
tagged v2.0.1 with a go.mod file later. v2.0.0 is incorrectly
considered part of the v2 module.
Fixes #31942
Change-Id: Icaa75c5c93f73f18a400c22f18a8cc603aa4011a
Reviewed-on: https://go-review.googlesource.com/c/go/+/177337
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Jean de Klerk [Fri, 17 May 2019 00:15:39 +0000 (18:15 -0600)]
errors: update As example to include else case
The current example illustrates using As when the error is able to be
interpreted as an os.PathError, but elides the "else" case. This CL adds the
small extra else case to make it clear that it's not safe to assume As will
return true.
This CL also squash the err instantiation and the err nil check into one line
for brevity.
Change-Id: I3d3ab483ffb38fb2788d0498b3f03229a87dd7c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/177717 Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Filippo Valsorda [Thu, 16 May 2019 23:13:29 +0000 (19:13 -0400)]
crypto/tls: add support for Ed25519 certificates in TLS 1.2 and 1.3
Support for Ed25519 certificates was added in CL 175478, this wires them
up into the TLS stack according to RFC 8422 (TLS 1.2) and RFC 8446 (TLS 1.3).
RFC 8422 also specifies support for TLS 1.0 and 1.1, and I initially
implemented that, but even OpenSSL doesn't take the complexity, so I
just dropped it. It would have required keeping a buffer of the
handshake transcript in order to do the direct Ed25519 signatures. We
effectively need to support TLS 1.2 because it shares ClientHello
signature algorithms with TLS 1.3.
While at it, reordered the advertised signature algorithms in the rough
order we would want to use them, also based on what curves have fast
constant-time implementations.
Client and client auth tests changed because of the change in advertised
signature algorithms in ClientHello and CertificateRequest.
Jay Conrod [Thu, 16 May 2019 16:38:41 +0000 (12:38 -0400)]
cmd/go: don't panic when explaining lost upgrades due to downgrades
If a user runs 'go get mod@vers' where the module transitively
requires itself at a newer version, 'go get' attempts to perform a
downgrade, which necessarily excludes the requested version of the
module.
Previously, we called mvs.BuildList with the requested module
version as the target. This panicked because BuildList doesn't allow
the target module (typically the main module) to require a newer
version of itself.
With this change, when we lose an upgrade due to a downgrade, we call
mvs.BuildList through a wrapper that treats the lost module version as
requirement of a synthetic root module, rather than the target
module. This avoids the panic.
This change also starts reporting errors when an upgraded module is
lost entirely (downgrades caused the module to be completely removed
from the build list).
Fixes #31491
Change-Id: I70ca261c20af7553cad2d3b840a1eaf3d18a4191
Reviewed-on: https://go-review.googlesource.com/c/go/+/177602
Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Michael Anthony Knyszek [Tue, 14 May 2019 16:39:43 +0000 (16:39 +0000)]
runtime: mark newly-mapped memory as scavenged
On most platforms newly-mapped memory is untouched, meaning the pages
backing the region haven't been faulted in yet. However, we mark this
memory as unscavenged which means the background scavenger
aggressively "returns" this memory to the OS if the heap is small.
The only platform where newly-mapped memory is actually unscavenged (and
counts toward the application's RSS) is on Windows, since
(*mheap).sysAlloc commits the reservation. Instead of making a special
case for Windows, I change the requirements a bit for a sysReserve'd
region. It must now be both sysMap'd and sysUsed'd, with sysMap being a
no-op on Windows. Comments about memory allocation have been updated to
include a more up-to-date mental model of which states a region of memory
may be in (at a very low level) and how to transition between these
states.
Now this means we can correctly mark newly-mapped heap memory as
scavenged on every platform, reducing the load on the background
scavenger early on in the application for small heaps. As a result,
heap-growth scavenging is no longer necessary, since any actual RSS
growth will be accounted for on the allocation codepath.
Finally, this change also cleans up grow a little bit to avoid
pretending that it's freeing an in-use span and just does the necessary
operations directly.
fanzha02 [Sun, 5 May 2019 03:35:37 +0000 (03:35 +0000)]
cmd/compile: fix the error of absorbing boolean tests into block(FGE, FGT)
The CL 164718 mistyped the comparison flags. The rules for floating
point comparison should be GreaterThanF and GreaterEqualF. Fortunately,
the wrong optimizations were overwritten by other integer rules, so the
issue won't cause failure but just some performance impact.
The fixed CL optimizes the floating point test as follows.
Change-Id: Iea954fdbb8272b2d642dae0f816dc77286e6e1fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/177121 Reviewed-by: Ben Shi <powerman1st@163.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Jason A. Donenfeld [Sun, 12 May 2019 12:34:30 +0000 (14:34 +0200)]
os: pass correct environment when creating Windows processes
This is CVE-2019-11888.
Previously, passing a nil environment but a non-nil token would result
in the new potentially unprivileged process inheriting the parent
potentially privileged environment, or would result in the new
potentially privileged process inheriting the parent potentially
unprivileged environment. Either way, it's bad. In the former case, it's
an infoleak. In the latter case, it's a possible EoP, since things like
PATH could be overwritten.
Not specifying an environment currently means, "use the existing
environment". This commit amends the behavior to be, "use the existing
environment of the token the process is being created for." The behavior
therefore stays the same when creating processes without specifying a
token. And it does the correct thing when creating processes when
specifying a token.
Fixes #32000
Change-Id: Ia57f6e89b97bdbaf7274d6a89c1d9948b6d40ef5
Reviewed-on: https://go-review.googlesource.com/c/go/+/176619
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
David Chase [Thu, 2 May 2019 17:35:07 +0000 (13:35 -0400)]
cmd/compile: add debugging and stats output to numberlines
This is useful for debugging line number assignment and
also for making sense of pathological line number inputs.
Activated with
-gcflags=-d=ssa/number_lines/stats=1 (the bit matters)
-gcflags=-d=ssa/number_lines/debug
Stats:
"SUM_LINE_RANGE",
SUM for f in files {MAX line in f {line}-MIN line in f {line}}
"MAXMIN_LINE_RANGE",
MAX for f in files {MAX line in f {line}} -
MIN for f in files {MIN line in f {line}}
"MAXFILE", maxfile,
MAX for f in files {f}
"NFILES", len(entries)
| files |
Change-Id: I8a7336e6370452fe2e3a62de17606db9bd6a6fd3
Reviewed-on: https://go-review.googlesource.com/c/go/+/174947
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Russ Cox [Wed, 15 May 2019 19:10:32 +0000 (15:10 -0400)]
testing: panic on calls to Short/Verbose before Parse
CL 121936 added this diagnostic to avoid a panic accessing *short.
(Hence the "This shouldn't really be a panic" comment.)
That CL was right to produce a clearer error than a plain memory fault,
but I think wrong to print+exit instead of panicking. I just ran into
one of these in a real program, and there is no indication anywhere
of how the program reached this point. The panic will show that.
So change print+exit to a panic with a helpful message, in contrast
to the original panic with an unhelpful message and the current
helpful message without stack trace.
Change-Id: Ib2bae1dead4ccde92f00fa3a34c05241ff7690c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/177419
Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Wed, 15 May 2019 18:31:48 +0000 (14:31 -0400)]
misc/cgo: disable testcarchive, testplugin during -short test (including all.bash)
These tests take 20 seconds each to rebuild the entire world
in their respective modes. That's too much for short mode,
including all.bash on developer machines.
Keep doing it on builders and if someone runs 'go test' by hand
in that directory.
Russ Cox [Tue, 14 May 2019 17:38:15 +0000 (13:38 -0400)]
cmd/go: rename renamed testing import
_go_testing is equally unlikely and much less concerning
than testing_xxxxxxxxxxxx if it appears in an error message
(as it does, for example, in https://storage.googleapis.com/go-build-log/0d543f89/linux-amd64_3467a10e.log).
Russ Cox [Fri, 10 May 2019 02:57:45 +0000 (22:57 -0400)]
cmd/vet/all: delete
The work of running full vet on std and cmd during local development
has moved to go test, which of course runs during all.bash.
For errors in other GOOS/GOARCH combinations, the misc-compile
builders (running buildall.bash) also now run go vet std cmd.
The vetall builder need not do anything anymore.
Make it a no-op until it can be retired, and remove
cmd/vet/all and its special case in the go command.
Russ Cox [Thu, 9 May 2019 22:55:02 +0000 (18:55 -0400)]
cmd/go: run full 'go vet' during 'go test' for packages in GOROOT
Now that the main tree complies with 'go vet', enable all vet checks
during 'go test' in the main tree. This helps surface helpful errors
while developing, instead of having to wait for the misc-vet-vetall builder.
During 'go test', the additional vet checks are essentially free:
the vet invocations themselves take only 8 seconds total for the entire tree.
Also update buildall.bash (used by the misc-compile builders)
to run 'go vet std cmd' for each GOOS/GOARCH pair.
This is not as free, since in general it can require recompiling
packages with their tests included before invoking vet.
(That compilation was going on anyway in the 'go test' case.)
On my Mac laptop, ./buildall.bash freebsd used to take
68+16+17+18 = 119 seconds for make.bash and then
the builds of the three freebsd architectures.
Now it takes 68+16+23+17+23+18+24 = 189 seconds, 60% longer.
Some of this is spent doing unnecessary cgo work.
Still, this lets us shard the vet checks and match all.bash.
Damien Neil [Mon, 13 May 2019 23:46:31 +0000 (16:46 -0700)]
fmt: support %w
When fmt.Errorf is provided with a %w verb with an error operand,
return an error implementing an Unwrap method returning that operand.
It is invalid to use %w with other formatting functions, to use %w
multiple times in a format string, or to use %w with a non-error
operand. When the Errorf format string contains an invalid use of %w,
the returned error does not implement Unwrap.
Change-Id: I534e20d3b163ab22c2b137b1c9095906dc243221
Reviewed-on: https://go-review.googlesource.com/c/go/+/176998 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
Joel Sing [Tue, 7 May 2019 07:56:49 +0000 (17:56 +1000)]
syscall: implement rawVforkSyscall for linux/ppc64x and linux/s390x
This allows the use of CLONE_VFORK and CLONE_VM for fork/exec, preventing
"fork/exec ...: cannot allocate memory" failures from occuring when attempting
to execute commands from a Go process that has a large memory footprint.
Additionally, this should reduce the latency of fork/exec on these platforms.
The same problem was addressed on linux/amd64 via issue #5838.
Updates #31936
Change-Id: I7ae0fbbeaa29cab944a49a11272a380d497eb2d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/175697
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Fri, 10 May 2019 01:56:53 +0000 (21:56 -0400)]
cmd/go: do not build test packages unnecessarily during go vet
Vet needs export data for the imports of the package it is analyzing.
Vet does not need export data for the package itself, since vet will
do its own type checking. Assuming that vet is just as good as the compiler
at detecting invalid programs, don't run the compiler unnecessarily.
This especially matters for tests without external test files or for
which the external test files do not import the test-augmented original
package. In that case, the test-augmented original package need not
be compiled at all.
Cuts time for 'go clean -cache && go vet -x cmd/compile/internal/ssa'
from 7.6r 24.3u 2.8s to 3.5r 8.5u 1.9s, by not running the compiler
on the augmented test package.
There is still more to be done here - if we do need to build a
test-augmented package, we rerun cgo unnecessarily.
But this is a big help.
For many patterns we can compute the minimum input length at compile time.
If the input is shorter, we can return early and get a huge speedup.
As pointed out by Damian Gryski, Perl's regex engine contains a number of
these kinds of fail-fast optimizations:
https://perldoc.perl.org/perlreguts.html#Peep-hole-Optimisation-and-Analysis
Baokun Lee [Thu, 9 May 2019 03:24:30 +0000 (11:24 +0800)]
cmd/go/internal/renameio: allow write file with the specified permissions
Now renameio package creates file use ioutil.TempFile, which calls
OpenFile with mode 0600, we should support creates a file with given
permission bits.
Fixes #31871
Change-Id: I0436e9f7081f2fce18bf9f3b14d55b02d4d995fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/175958
Run-TryBot: Baokun Lee <nototon@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Robert Griesemer [Tue, 14 May 2019 17:22:04 +0000 (10:22 -0700)]
spec: clarify that slice a expression shares underlying array with operand
The spec was not very precise as to what happens with respect to sharing
if a sliced operand is (a pointer to) an array. Added a small clarification
and a supporting example.
Fixes #31689.
Change-Id: Ic49351bec2033abd3f5428154ec3e9a7c2c9eaa5
Reviewed-on: https://go-review.googlesource.com/c/go/+/177139 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Keith Randall [Mon, 13 May 2019 20:43:49 +0000 (13:43 -0700)]
cmd/compile: make sure to initialize static entries of slices
If a slice's entries are sparse, we decide to initialize it dynamically
instead of statically. That's CL 151319.
But if we do initialize it dynamically, we still need to initialize
the static entries. Typically we do that, but the bug fixed here is
that we don't if the entry's value is itself an array or struct.
To fix, use initKindLocalCode to ensure that both static and
dynamic entries are initialized via code.
Jonathon Lacher [Tue, 14 May 2019 15:11:30 +0000 (15:11 +0000)]
net/http/httputil: remove all fields in Connection header
In the reverseproxy, replace use (Header).Get, which returns only one value
of a multiple value header, with using the Header map directly. Also fixes
corresponding tests which hid the bug, and adds more tests.
Clément Chigot [Mon, 25 Feb 2019 08:44:33 +0000 (09:44 +0100)]
runtime: call atomic.Storeuintptr in noteclear on AIX
The memory might not be synchronized in a thread being woken up after a
semasleep. Using atomic instructions in noteclear function will force
this synchronisation.
Fixes #30189
Change-Id: If7432f29b2a1a56288231822db52f3f8d1d6dbfe
Reviewed-on: https://go-review.googlesource.com/c/go/+/163624
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/go: fix import current directory error message
Fixes #14683
Change-Id: I62c429e4fcc2f20a94d3db8c1f0ca587252c07a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/174130
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Bryan C. Mills [Mon, 13 May 2019 15:22:32 +0000 (11:22 -0400)]
cmd/go: convert semver tags with metadata to pseudoversions
Some repositories include tags like 'v1.0.0-rc.1+oryOS.9'.
If we were to allow such tags, they could become ambiguous: semantic
versioning defines versions that differ only in metadata to have equal
precedence, so if someone added a tag 'v1.0.0-rc.1+other' at a
different commit, then the version 'v1.0.0-rc.1' would become
ambiguous.
However, we should still allow those tags to be used to resolve
versions, and since we can even parse the underlying semantic version,
we can at least use that as the basis for a unique (and well-ordered)
pseudo-version.
Fixes #31713
Change-Id: I5035f76d74ead6e786c04a368595cb5e42d36f91
Reviewed-on: https://go-review.googlesource.com/c/go/+/176905
Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Robert Griesemer [Wed, 8 May 2019 20:21:02 +0000 (13:21 -0700)]
spec: clarify language on package-level variable initialization
The very first paragraph on "Package initialization" stated that
"variables are initialized in declaration order, but after any
variables they might depend on". This phrasing was easily
misread as "declaration order is the first sorting criteria"
and then contradicted what the subsequent paragraphs spelled
out in precise detail.
Instead, variable initialization proceeds by repeatedly determining
a set of ready to initialize variables, and then selecting from that
set the variable declared earliest. That is, declaration order is the
second sorting criteria.
Also, for the purpose of variable initialization, declarations
introducing blank (_) variables are considered like any other
variables (their initialization expressions may have side-effects
and affect initialization order), even though blank identifiers
are not "declared".
This CL adds clarifying language regarding these two issues
and the supporting example.
Both gccgo and go/types implement this behavior. cmd/compile
has a long-standing issue (#22326).
The spec also did not state in which order multiple variables
initialized by a single (multi-value) initialization expression are
handled. This CL adds a clarifying paragraph: If any such variable
is initialized, all that declaration's variables are initialized at
the same time.
This behavior matches user expectation: We are not expecting to
observe partially initialized sets of variables in declarations
such as "var a, b, c = f()".
It also matches existing cmd/compile and go/types (but not gccgo)
behavior.
Finally, cmd/compile, gccgo, and go/types produce different
initialization orders in (esoteric) cases where hidden (not
detected with existing rules) dependencies exist. Added a
sentence and example clarifying how much leeway compilers have
in those situations. The goal is to preserve the ability to
use static initialization while at the same time maintain
the relative initialization order of variables with detected
dependencies.
Fixes #31292.
Updates #22326.
Change-Id: I0a369abff8cfce27afc975998db875f5c580caa2
Reviewed-on: https://go-review.googlesource.com/c/go/+/175980 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Tamir Duberstein [Mon, 13 May 2019 18:20:53 +0000 (14:20 -0400)]
runtime: resolve latent TODOs
These were added in https://go-review.googlesource.com/1224; according
to austin@google.com these annotations are not valuable - resolving by
removing the TODOs.
Jay Conrod [Thu, 9 May 2019 19:42:55 +0000 (15:42 -0400)]
cmd/go: make 'go get' match patterns against packages, not modules
This is a follow-up to CL 174099, fixing an important TODO.
The 'go help modget' documentation will be clarified in anotehr CL,
pending further discussion.
When invoked without -m, 'go get' will no longer match arguments
containing "..." against module paths. If a module's path matches a
pattern but no packages within the module match the pattern, the
module should not be upgraded. For example, if
golang.org/x/tools/playground and golang.org/x/tools are separate
modules, and only golang.org/x/tools is in the build list,
'go get golang.org/x/tools/playground/...' should add
golang.org/x/tools/playground to the build list and leave
golang.org/x/tools alone.
Updates #26902
Change-Id: I2bd18c7950db1aa7bd8527210c1baf2c7d174375
Reviewed-on: https://go-review.googlesource.com/c/go/+/176578
Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
index/suffixarray: index 3-10X faster in half the memory
This CL changes the index/suffixarray construction algorithm from QSufSort to SAIS.
For an N-byte input, QSufSort runs in O(N log N) time and requires
an N-int temporary work space in addition to the N-int output.
In contrast, SAIS runs in O(N) time and, for essentially all real inputs,
is able to use the N-int output buffer as its temporary work space.
(In pathological cases, SAIS must allocate a temporary work space of
at most N/2 ints. There exist more complex variants that guarantee
to avoid the work space in all cases, but they hardly seem worth the cost
given how rare these pathological cases are.)
The SAIS code therefore uses 50% of the memory across the board.
It also runs 3-10X faster on real input text.
This CL also adds more extensive algorithmic tests, including an
exhaustive test over small inputs to catch corner case problems.
Bryan C. Mills [Fri, 10 May 2019 19:26:56 +0000 (15:26 -0400)]
cmd/go/internal/modfetch: fix GOSUMDB test failures
Use cfg.GOSUMDB consistently instead of re-resolving it from the environment.
Set cfg.GOSUMDB to 'off' explicitly in coderepo_test, since it may
include modules that cannot be fetched using a released version of the
'go' command.
Fixes #31964
Change-Id: I17cae9e0c6aa1168ba534e6da4e3652800ac81e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/176538
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
LE Manh Cuong [Fri, 10 May 2019 08:32:24 +0000 (15:32 +0700)]
errors: remove useless condition checking in Is
golang.org/cl/175260 fixed Is panics if target is uncomparable. It did
add an useless condition checking whether target is comparable. Just
remove that condition.
Change-Id: I0a317056479638d209b0a0cbc7010c153558c087
Reviewed-on: https://go-review.googlesource.com/c/go/+/176497 Reviewed-by: Joan Lopez de la Franca Beltran <joanjan14@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Joel Sing [Fri, 10 May 2019 16:21:22 +0000 (02:21 +1000)]
cmd/link: add support for R_AARCH64_LDST128_ABS_LO12_NC relocations
These are encountered when compiling with -linkmode=internal on openbsd/arm64.
Fixes #31940
Change-Id: I851e6a7da0a3fb3e23b4fa2ed8dce3051c680f11
Reviewed-on: https://go-review.googlesource.com/c/go/+/176697
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Tamir Duberstein [Sat, 11 May 2019 18:08:52 +0000 (14:08 -0400)]
net: comment duplicate constant
Change-Id: If5a4d8eff4e51d72fb9dc1d5db2bfe674ec5753b
Reviewed-on: https://go-review.googlesource.com/c/go/+/176717 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Cherry Zhang [Fri, 10 May 2019 19:08:17 +0000 (15:08 -0400)]
test: use a real use function in nilptr2.go
Adjust the dummy use function to a real use. As suggested by the
println calls in the test, nilptr2.go supposes to check that a
used nil pointer dereference panics. This use function is not
real enough so an optimized compiler such as gccgo could
eliminate the call.
The spec requires that even a dummy use would cause a panic.
Unfortunately, due to #31151 this is not true for gccgo at -O1 or
above.
This is silly; there are no non-rewrite lines in the file.
Furthermore, the rulelog file tends to be gigantic
for any non-trivial compilation (measured in gigabytes).
Caleb Spare [Wed, 8 May 2019 20:38:14 +0000 (13:38 -0700)]
cmd/go: move automatic testing.Init call into generated test code
In CL 173722, we moved the flag registration in the testing package into
an Init function. In order to avoid needing changes to user code, we
called Init automatically as part of testing.MainStart.
However, that isn't early enough if flag.Parse is called before the
tests run, as part of package initialization.
Fix this by injecting a bit of code to call testing.Init into test
packages. This runs before any other initialization code in the user's
test package, so testing.Init will be called before any user code can
call flag.Parse.
Jay Conrod [Fri, 10 May 2019 15:49:08 +0000 (11:49 -0400)]
cmd/go: force -coverpkg main packages to be built as libraries
This fixes TestScript/cover_pkgall_multiple_mains, which started
failing after CL 174657.
When compiling main packages with coverage instrumentation
(e.g., for -coverpkg all), we now pass -p with the full import path
instead of '-p main'. This avoids link errors
'duplicate symbol main.main (types 1 and 1)'.
Russ Cox [Fri, 10 May 2019 15:13:06 +0000 (11:13 -0400)]
runtime: fix windows-amd64-2012 build
I forgot that in Go assembly, x+16(SP) is not the same as 16(SP).
The former is the virtual stack pointer (one word below FP on x86)
while the latter is the actual stack pointer.
Bryan C. Mills [Fri, 10 May 2019 15:10:50 +0000 (11:10 -0400)]
cmd/go/testdata/script: remove skips and clarify comments in mod_*_upgrade_pseudo tests
These tests were added in CL 174206.
They required a 'git' binary and network access in an earlier draft,
but now use the test-local module proxy instead, so no longer need to
be skipped when those resources are not present.
Updates #30634
Change-Id: I5f36c6c776209a89bc45d133847df5052b55da59
Reviewed-on: https://go-review.googlesource.com/c/go/+/176537
Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Russ Cox [Thu, 9 May 2019 22:34:29 +0000 (18:34 -0400)]
runtime: fix s390x build
The new prototypes of duffzero and duffcopy must be
accompanied by functions. Otherwise buildmode=shared
(in particular, misc/cgo/testshared) has missing symbols.
The right fix, of course, is to implement these on s390x.
Brad Fitzpatrick [Thu, 9 May 2019 21:04:39 +0000 (21:04 +0000)]
os/user: make Current return better error w/o cgo & complete environment
Fixes #31949
Change-Id: Ib96a43e4c56a00c5ba04e4d213255a063058ae08
Reviewed-on: https://go-review.googlesource.com/c/go/+/176337 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Wed, 8 May 2019 18:56:48 +0000 (14:56 -0400)]
runtime: fix vet complaints for solaris/amd64, illumos/amd64
Working toward making the tree vet-safe instead of having
so many exceptions in cmd/vet/all/whitelist.
This CL makes "go vet -unsafeptr=false runtime" happy for these GOOS/GOARCHes,
while keeping "GO_BUILDER_NAME=misc-vetall go tool dist test" happy too.
Russ Cox [Wed, 8 May 2019 17:59:48 +0000 (13:59 -0400)]
runtime: fix vet complaints for linux/arm64, linux/mips*, linux/ppc64*, linux/s390x
Working toward making the tree vet-safe instead of having
so many exceptions in cmd/vet/all/whitelist.
This CL makes "go vet -unsafeptr=false runtime" happy for these GOOS/GOARCHes,
except for an unresolved complaint on mips/mipsle that is a bug in vet,
while keeping "GO_BUILDER_NAME=misc-vetall go tool dist test" happy too.
Russ Cox [Wed, 8 May 2019 17:16:05 +0000 (13:16 -0400)]
runtime: fix vet complaints for linux/amd64
Working toward making the tree vet-safe instead of having
so many exceptions in cmd/vet/all/whitelist.
This CL makes "GOOS=linux GOARCH=amd64 go vet -unsafeptr=false runtime" happy,
while keeping "GO_BUILDER_NAME=misc-vetall go tool dist test" happy too.