go/master long-term tracking #4
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Replaces //go:linkname by assembly functions for syscall functions on aix/ppc64. Since the new runtime internal ABI, this was triggering an error if syscall.Syscall6 was called by others packages like x/sys/unix. This commit should remove every future occurences of this problem. Fixes golang#28769 Change-Id: I6a4bf77472ee1e974bdb76b27e74275e568f5a76 Reviewed-on: https://go-review.googlesource.com/c/153997 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Previously, RepoRootForImportPath trimmed certain "..." wildcards from
package patterns (even though its name suggests that the argument must
be an actual import path). It trimmed at the first path element that
was literally "..." (although wildcards in general may appear within a
larger path element), and relied on a subsequent check in
RepoRootForImportPath to catch confusing resolutions.
However, that causes 'go get' with wildcard patterns in fresh paths to
fail as of CL 154101: a wildcard pattern is not a valid import path,
and fails the path check. (The existing Test{Vendor,Go}Get* packages
in go_test.go and vendor_test.go catch the failure, but they are all
skipped when the "-short" flag is set — including in all.bash — and we
had forgotten to run them separately.)
We now trim the path before any element that contains a wildcard, and
perform the path check (and repo resolution) on only that prefix. It
is possible that the expanded path after fetching the repo will be
invalid, but a repository can contain directories that are not valid
import paths in general anyway.
Fixes golang#29241
Change-Id: I70fb2f7fc6603b7d339fd6c02e8cdeacfc93fc4b
Reviewed-on: https://go-review.googlesource.com/c/154108
Reviewed-by: Russ Cox <rsc@golang.org>
Updates to x/net git rev 891ebc4b82d6e74f468c533b06f983c7be918a96 for: http2/hpack: track the beginning of a header block https://go-review.googlesource.com/c/153978 Updates golang#29187 Change-Id: Ie2568b3f8d6aaa3f097a4ac25d3acdc794f5ff5c Reviewed-on: https://go-review.googlesource.com/c/154118 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matt Layher <mdlayher@gmail.com>
… use We shouldn't pollute people's flags with this debugging flag that was never really meant to be public. It's certainly not documented. So keep it for now, but don't register it unless it looks like it's in use (by looking at os.Args). Kinda gross, but less gross than before. Fixes golang#28619 Change-Id: I47498948a26a71ff36f9658a6d9dac73fd0a3016 Reviewed-on: https://go-review.googlesource.com/c/154217 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org>
Change-Id: Id71aad4cf6149e0ba15f7fec0b74517827c37866 Reviewed-on: https://go-review.googlesource.com/c/154303 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Change-Id: Ic098bd69fa9e3f7b2ed6c451a7a266167c0cde94 Reviewed-on: https://go-review.googlesource.com/c/154302 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
cmd/go/main.go sets GOCACHE explicitly, so if we don't save some metadata about how DefaultDir arrived at its answer we will be unable to reconstruct it later. Fixes golang#29243 Change-Id: Ic8bb859ab045a29c91f6a4527e65aedabf874d53 Reviewed-on: https://go-review.googlesource.com/c/154309 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
CL 146297 ignored archive members with short names that don't have the .o suffix, however, it also ignored .syso files as well. This change restores the original .syso behavior and adds a test. As the test is basically following a shell script, we make use of the existing cmd/go/testdata/script framework. To support running C compiler in the script, we added a `cc` command, which runs the C compiler along with correct platform specific arguments. Fixes golang#29253. Change-Id: If8520151c4d6a74ab9fe84d34bff9a4480688815 Reviewed-on: https://go-review.googlesource.com/c/154109 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Alan Donovan <adonovan@google.com>
Updates golang#26148 Change-Id: I704efafca39e4397caf2db0146d83d309c761dd1 Reviewed-on: https://go-review.googlesource.com/c/154357 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
Similar to to macOS' CF* types and JNI's jobject and derived types, the EGLDisplay type is declared as a pointer but can contain non-pointers (see golang#27054). Fix it the same way: map EGLDisplay to uintptr in Go. Fixes golang#27054 RELNOTE=yes Change-Id: I6136f8f8162687c5493b30ed324e29efe55a8fd7 Reviewed-on: https://go-review.googlesource.com/c/154417 Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Fixes golang#29271 Change-Id: Iff6a16c659ad6ec1b4d9559fcbcd40196086c60e Reviewed-on: https://go-review.googlesource.com/c/154380 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
This fixes a few different issues that led to hangs and general flakiness in the TestDebugCall* tests. 1. This fixes missing wake-ups in two error paths of the SIGTRAP signal handler. If the goroutine was in an unknown state, or if there was an unknown debug call status, we currently don't wake the injection coordinator. These are terminal states, so this resulted in a hang. 2. This adds a retry if the target goroutine is in a transient state that prevents us from injecting a call. The most common failure mode here is that the target goroutine is in _Grunnable, but this was previously masked because it deadlocked the test. 3. Related to 2, this switches the "ready" signal from the target goroutine from a blocking channel send to a non-blocking channel send. This makes it much less likely that we'll catch this goroutine while it's in the runtime performing that send. 4. This increases GOMAXPROCS from 2 to 8 during these tests. With the current setting of 2, we can have at most the non-preemptible goroutine we're injecting a call in to and the goroutine that's trying to make it exit. If anything else comes along, it can deadlock. One particular case I observed was in TestDebugCallGC, where runtime.GC() returns before the forEachP that prepares sweeping on all goroutines has finished. When this happens, the forEachP blocks on the non-preemptible loop, which means we now have at least three goroutines that need to run. Fixes golang#25519. Updates golang#29124. Change-Id: I7bc41dc0b865b7d0bb379cb654f9a1218bc37428 Reviewed-on: https://go-review.googlesource.com/c/154112 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
The OpenBSD armv7 port has working VFPv3 these days - re-enable the VFP detection code so that GOARM=7 is used by default on openbsd/arm. Change-Id: I0271d81c048d2d55becd2803c19e5f1542076357 Reviewed-on: https://go-review.googlesource.com/c/154378 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
It appears calling GetFileInformationByHandleEx with FILE_ATTRIBUTE_TAG_INFO fails on FAT file system. FAT does not support symlinks, so assume there are no symlnks when GetFileInformationByHandleEx returns ERROR_INVALID_PARAMETER. Fixes golang#29214 Change-Id: If2d9f3288bd99637681ab5fd4e4581c77b578a69 Reviewed-on: https://go-review.googlesource.com/c/154377 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
This commit fixes error messages displayed on aix/ppc64 with external linking. Change-Id: I5311d36f30394be717827891e070db249482814a Reviewed-on: https://go-review.googlesource.com/c/151041 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently we reset the write barrier buffer before processing the pointers in it. As a result, if there were any write barriers in the code that processes the buffer, it would corrupt the write barrier buffer and cause us to mark objects without later scanning them. As far as I can tell, this shouldn't be happening, but rather than relying on hope (and incomplete static analysis), this CL changes wbBufFlush1 to poison the write barrier buffer while processing it, and only reset it once it's done. Updates golang#27993. (Unlike many of the other changes for this issue, there's no need to roll back this CL. It's a good change in its own right.) Change-Id: I6d2d9f1b69b89438438b9ee624f3fff9f009e29d Reviewed-on: https://go-review.googlesource.com/c/154537 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
…rror A prior optimization (https://golang.org/cl/106175) removed the generation of unnecessary method expression wrappers, but also eliminated the generation of the wrapper for error.Error which was still required. Special-case error type in the optimization. Fixes golang#29304. Change-Id: I54c8afc88a2c6d1906afa2d09c68a0a3f3e2f1e3 Reviewed-on: https://go-review.googlesource.com/c/154578 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: Ifb16fd28105efd05cebbd615b52e45330b77cede Reviewed-on: https://go-review.googlesource.com/c/154600 Reviewed-by: Ian Lance Taylor <iant@golang.org>
This commit updates the new symbol addressing made for aix/ppc64 according to feedbacks given in CL 151039. Change-Id: Ic4eb9943dc520d65f7d084adf8fa9a2530f4d3f9 Reviewed-on: https://go-review.googlesource.com/c/151302 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently we only know the slot address and the value being written in the throwOnGCWork crash tracebacks, and we have to infer the old value from what's dumped by gcWork.checkPut. Sometimes these old values don't make sense, like when we see a write of a nil pointer to a freshly-allocated object, yet we observe marking a value (where did that pointer come from?). This CL adds the old value of the slot and the first two pointers in the buffer to the traceback. For golang#27993. Change-Id: Ib70eead1afb9c06e8099e520172c3a2acaa45f80 Reviewed-on: https://go-review.googlesource.com/c/154597 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Many of the crashes observed in golang#27993 involve committing the new _defer object at the end of newdefer. It would be helpful to know if the _defer was just allocated or was retrieved from the defer pool. In order to indicate this in the traceback, this CL duplicates the tail of newdefer so that the PC/line number will tell us whether d is new or not. For golang#27993. Change-Id: Icd3e23dbcf00461877bb082b6f18df701149a607 Reviewed-on: https://go-review.googlesource.com/c/154598 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
This captures the stack trace where mark completion observed that each P had no work, and then dumps this if that P later discovers more work. Hopefully this will help bound where the work was created. For golang#27993. Change-Id: I4f29202880d22c433482dc1463fb50ab693b6de6 Reviewed-on: https://go-review.googlesource.com/c/154599 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: If65518c76a865c03266be76b1c21c76e1c8b4763 Reviewed-on: https://go-review.googlesource.com/c/153828 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: I2a5613377a38815fb8746c5bfb07ccbbc2e6dd0b Reviewed-on: https://go-review.googlesource.com/c/153829 Reviewed-by: Adam Langley <agl@golang.org>
sysUsed on Windows cares about the result from the VirtualAlloc syscall returning exactly the address that was passed to it. However, VirtualAlloc aligns the address its given to the kernel's allocation granularity, so the returned address may not be the same. Note that this wasn't an issue in the past because we only sysUsed regions owned by spans, and spans are always a multiple of 8K, which is a multiple of the allocation granularity on most Windows machines. Change-Id: I3f5ccd63c6bbbd8b7995945ecedee17573b31667 Reviewed-on: https://go-review.googlesource.com/c/153677 Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Rick Hudson <rlh@golang.org>
When a println arg contains a call to an inlineable function
that itself contains a switch, that switch statement will be
walked twice, once by the walkexprlist formerly in the
OPRINT/OPRINTN case, then by walkexprlistcheap in walkprint.
Remove the first walkexprlist, it is not necessary.
walkexprlist =
s[i] = walkexpr(s[i], init)
walkexprlistcheap = {
s[i] = cheapexpr(n, init)
s[i] = walkexpr(s[i], init)
}
Seems like this might be possible in other places, i.e.,
calls to inlineable switch-containing functions.
See also golang#25776.
Fixes golang#29220.
Change-Id: I3781e86aad6688711597b8bee9bc7ebd3af93601
Reviewed-on: https://go-review.googlesource.com/c/154497
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This commit move data addresses to 0x200000000 for XCOFF executables. .data and .bss must always be position-independent on AIX. This modification allows to detect more easily if they aren't, as segfault will be triggered. Change-Id: Ied7a5b72b9f4ff9f870a1626cf07c48110635e62 Reviewed-on: https://go-review.googlesource.com/c/151040 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change adds the treapIter type which provides an iterator abstraction for walking over an mTreap. In particular, the mTreap type now has iter() and rev() for iterating both forwards (smallest to largest) and backwards (largest to smallest). It also has an erase() method for erasing elements at the iterator's current position. For golang#28479. While the expectation is that this change will slow down Go programs, the impact on Go1 and Garbage is negligible. Go1: https://perf.golang.org/search?q=upload:20181214.6 Garbage: https://perf.golang.org/search?q=upload:20181214.11 Change-Id: I60dbebbbe73cbbe7b78d45d2093cec12cc0bc649 Reviewed-on: https://go-review.googlesource.com/c/151537 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Rick Hudson <rlh@golang.org>
This change modifies the behavior of span allocations to no longer prefer the free treap over the scavenged treap. While there is an additional cost to allocating out of the scavenged treap, the current behavior of preferring the unscavenged spans can lead to unbounded growth of a program's virtual memory footprint. In small programs (low # of Ps, low resident set size, low allocation rate) this behavior isn't really apparent and is difficult to reproduce. However, in relatively large, long-running programs we see this unbounded growth in free spans, and an unbounded amount of heap growths. It still remains unclear how this policy change actually ends up increasing the number of heap growths over time, but switching the policy back to best-fit does indeed solve the problem. Change-Id: Ibb88d24f9ef6766baaa7f12b411974cc03341e7b Reviewed-on: https://go-review.googlesource.com/c/148979 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Fixes golang#29260 Change-Id: I419b74d06380113f4bd32b9aeb053c3be36208d5 Reviewed-on: https://go-review.googlesource.com/c/154584 Reviewed-by: Alan Donovan <adonovan@google.com>
Updates golang#29983 Change-Id: Ifdf8aa9c92e053374e301a4268d85e277c15f0b5 Reviewed-on: https://go-review.googlesource.com/c/160182 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fixes golang#29983 Change-Id: I24077bde991e621c23d00973b2a77bb3a18e4ae7 Reviewed-on: https://go-review.googlesource.com/c/160180 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Damien Neil <dneil@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
Note the removal of the go tool tour command in the Go 1.12 release notes. Updates golang#24819 Change-Id: I258ab9401ea2cc06a83328c67299376fcf23c980 Reviewed-on: https://go-review.googlesource.com/c/158618 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Andrew Bonventre <andybons@golang.org>
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> golang/build@269e03a [build] Used GitHub User @tell-k (26263) form for tell-k <ffk2005@gmail.com> golang/tools@85a87a81 [tools] Used GitHub name "Akhil Indurti" for smasher164 <aindurti@gmail.com> golang@a7af474359 [build go] Used GitHub name "Guilherme Caruso" for GuilhermeCaruso <gui.martinscaruso@gmail.com> golang@5fae09b738 [go] Used GitHub name "Ivan Markin" for nogoegst <nogoegst@users.noreply.github.com> golang@a1addf15df [go] Used GitHub name "Keiji Yoshida" for yosssi <yoshida.keiji.84@gmail.com> golang/lint@ac6833c [lint] Used GitHub name "Marwan Sulaiman" for marwan-at-work <marwan.sameer@gmail.com> golang@92caeef892 [go] Used GitHub name "Michalis Kargakis" for kargakis <mkargaki@redhat.com> golang@e243d242d7 [go] Used GitHub name "Robin Eklind" for mewmew <rnd0x00@gmail.com> golang@b8620afb8d [go proposal.git] Used GitHub name "Sean Chen" for two <oohcode@gmail.com> golang/sys@302c3dd [sys] Used GitHub name "Sebastien Williams-Wynn" for GiantsLoveDeathMetal <sebastien@cytora.com> golang@4e056ade24 [go] Used GitHub name "Yohei Takeda" for yo-tak <yo.tak0812@gmail.com> golang@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. Updates golang#12042 Change-Id: I70248f3c82a836ee829256898e931e638ee45eb4 Reviewed-on: https://go-review.googlesource.com/c/160261 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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 golang#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>
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. Garbage: https://perf.golang.org/search?q=upload:20190131.3 Go1: https://perf.golang.org/search?q=upload:20190131.2 Updates golang#14045. Change-Id: I44a7e6586eca33b5f97b6d40418db53a8a7ae715 Reviewed-on: https://go-review.googlesource.com/c/159500 Reviewed-by: Austin Clements <austin@google.com>
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). Garbage: https://perf.golang.org/search?q=upload:20190131.5 Go1: https://perf.golang.org/search?q=upload:20190131.4 Performance change with both changes: Garbage: https://perf.golang.org/search?q=upload:20190131.7 Go1: https://perf.golang.org/search?q=upload:20190131.6 Change-Id: I87bd3c183e71656fdafef94714194b9fdbb77aa2 Reviewed-on: https://go-review.googlesource.com/c/160297 Reviewed-by: Austin Clements <austin@google.com>
CL 159859 causes build failure with old clang versions (3.4.1) on FreeBSD 10.3/10.4. Update golang#29962 Update golang#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>
Fixes golang#30043 Change-Id: I4ecfff7d8a9432240c1927f7484786fe1182b773 Reviewed-on: https://go-review.googlesource.com/c/160797 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We are copying the results to uninitialized stack space. Write barrier is not needed. Fixes golang#30041. Change-Id: Ia91d74dbafd96dc2bd92de0cb479808991dda03e Reviewed-on: https://go-review.googlesource.com/c/160737 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Keith Randall <khr@golang.org>
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 golang#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>
Fixes golang#30065 Change-Id: I3d0fb03bab397548653d5f3b386cfe2980ac1030 Reviewed-on: https://go-review.googlesource.com/c/160830 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Change-Id: Ib0a0d04aaaaa3c213fdb8646bd9b7dfdadae40d4 Reviewed-on: https://go-review.googlesource.com/c/160831 Reviewed-by: Filippo Valsorda <filippo@golang.org>
Expand modules documentation to clarify why @none is useful. The wording is the one suggested by rsc on the issue. Fixes golang#26684 Change-Id: I76dc4ff87e50f1dd8536fd9ac1fd938adb29bee3 Reviewed-on: https://go-review.googlesource.com/c/161037 Reviewed-by: Bryan C. Mills <bcmills@google.com>
Fixes golang#22447 Fixes golang#22448 Change-Id: Ia24f42c31e014c79040ff927f1247dfb2318de4f Reviewed-on: https://go-review.googlesource.com/c/160778 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Change-Id: Ia830f59d6f6ca1bc506ec298ccfc154d9f94f01d GitHub-Last-Rev: 3ab18d4 GitHub-Pull-Request: golang#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>
Change-Id: If3bab2dd5278ebc621235164e9d6ff710ba326ee Reviewed-on: https://go-review.googlesource.com/c/160898 Reviewed-by: Adam Langley <agl@golang.org>
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>
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 golang#29233 was fixed in 7701306. 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 golang#30079 Change-Id: If8ab0179aca86cb74caa926d1ef93fb5e416b4bb Reviewed-on: https://go-review.googlesource.com/c/161097 Reviewed-by: Adam Langley <agl@golang.org>
Updates golang#30055 Change-Id: If68615c8e9daa4226125dcc6a6866f29f3cfeef1 Reviewed-on: https://go-review.googlesource.com/c/160997 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
Most of the issues that led to the decision on golang#30055 were related to incompatibility with or faulty support for RSA-PSS (golang#29831, golang#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 golang#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>
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: 55dba87 GitHub-Pull-Request: golang#29890 Reviewed-on: https://go-review.googlesource.com/c/159077 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Change-Id: I46046cddceff2d44a7b2517db1ebf7acdf5f2b90 GitHub-Last-Rev: 7fb9f26 GitHub-Pull-Request: golang#30144 Reviewed-on: https://go-review.googlesource.com/c/161718 Reviewed-by: Brad Fitzpatrick <bradfitz@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>
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>
… tidy' Fixes golang#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>
changkun
pushed a commit
that referenced
this pull request
Apr 12, 2019
Most chars in URLs are lowercase, so check that first. Performance change: String-4 7.62µs ± 1% 7.27µs ± 3% -4.61% (p=0.008 n=5+5) QueryEscape/#00-4 92.6ns ± 3% 90.3ns ± 1% -2.48% (p=0.016 n=5+5) QueryEscape/#1-4 515ns ± 4% 510ns ± 2% ~ (p=0.683 n=5+5) QueryEscape/#2-4 375ns ± 1% 343ns ± 1% -8.52% (p=0.008 n=5+5) QueryEscape/#3-4 758ns ± 1% 699ns ± 1% -7.83% (p=0.008 n=5+5) QueryEscape/#4-4 6.06µs ± 1% 5.74µs ± 1% -5.38% (p=0.008 n=5+5) PathEscape/#00-4 140ns ± 1% 135ns ± 2% -3.85% (p=0.008 n=5+5) PathEscape/#1-4 511ns ± 3% 507ns ± 3% ~ (p=0.587 n=5+5) PathEscape/#2-4 372ns ± 1% 342ns ± 2% -8.22% (p=0.008 n=5+5) PathEscape/#3-4 747ns ± 1% 685ns ± 1% -8.30% (p=0.008 n=5+5) PathEscape/#4-4 5.94µs ± 1% 5.64µs ± 3% -4.98% (p=0.008 n=5+5) QueryUnescape/#00-4 111ns ± 4% 110ns ± 2% ~ (p=0.952 n=5+5) QueryUnescape/#1-4 390ns ± 0% 391ns ± 2% ~ (p=0.714 n=5+5) QueryUnescape/#2-4 297ns ± 5% 295ns ± 3% ~ (p=0.524 n=5+5) QueryUnescape/#3-4 543ns ± 3% 556ns ± 2% +2.39% (p=0.032 n=5+5) QueryUnescape/#4-4 3.23µs ± 3% 3.22µs ± 2% ~ (p=1.000 n=5+5) PathUnescape/#00-4 111ns ± 1% 110ns ± 3% ~ (p=0.881 n=5+5) PathUnescape/#1-4 389ns ± 2% 386ns ± 2% ~ (p=0.444 n=5+5) PathUnescape/#2-4 297ns ± 1% 295ns ± 3% ~ (p=0.738 n=5+5) PathUnescape/#3-4 557ns ± 3% 553ns ± 2% ~ (p=0.810 n=5+5) PathUnescape/#4-4 2.94µs ± 2% 2.97µs ± 2% ~ (p=0.222 n=5+5) Change-Id: I7e6d64cd5f8f5218cb40f52f0015168a8674aabb Reviewed-on: https://go-review.googlesource.com/c/go/+/168883 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
changkun
pushed a commit
that referenced
this pull request
Jun 7, 2019
Build result string via string.Builder to avoid allocation. As side effect some performance boots. name old time/op new time/op delta QueryUnescape/#00-4 114ns ± 0% 98ns ± 1% -13.89% (p=0.000 n=4+5) QueryUnescape/#1-4 401ns ± 2% 383ns ± 1% -4.54% (p=0.008 n=5+5) QueryUnescape/#2-4 300ns ± 2% 274ns ± 2% -8.66% (p=0.008 n=5+5) QueryUnescape/#3-4 564ns ± 2% 542ns ± 2% -4.04% (p=0.008 n=5+5) QueryUnescape/#4-4 3.27µs ± 2% 3.34µs ± 8% ~ (p=0.690 n=5+5) PathUnescape/#00-4 112ns ± 2% 99ns ± 3% -11.25% (p=0.008 n=5+5) PathUnescape/#1-4 392ns ± 2% 374ns ± 6% ~ (p=0.063 n=5+5) PathUnescape/#2-4 296ns ± 2% 274ns ± 2% -7.43% (p=0.008 n=5+5) PathUnescape/#3-4 556ns ± 2% 537ns ± 1% -3.45% (p=0.008 n=5+5) PathUnescape/#4-4 2.99µs ± 1% 3.00µs ± 1% ~ (p=0.690 n=5+5) name old allocs/op new allocs/op delta QueryUnescape/#00-4 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.008 n=5+5) QueryUnescape/#1-4 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.008 n=5+5) QueryUnescape/#2-4 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.008 n=5+5) QueryUnescape/#3-4 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.008 n=5+5) QueryUnescape/#4-4 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.008 n=5+5) PathUnescape/#00-4 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.008 n=5+5) PathUnescape/#1-4 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.008 n=5+5) PathUnescape/#2-4 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.008 n=5+5) PathUnescape/#3-4 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.008 n=5+5) PathUnescape/#4-4 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.008 n=5+5) Change-Id: I7cba5eb53bebef7b1fdd44598eed47241ce83167 Reviewed-on: https://go-review.googlesource.com/c/go/+/166463 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
changkun
pushed a commit
that referenced
this pull request
Jul 26, 2020
unsafe.Pointer safety rule #4 says "The compiler handles a Pointer converted to a uintptr in the argument list of a call". Within escape analysis, we've always required this be a single conversion unsafe.Pointer->uintptr conversion, but the corresponding logic in order is somewhat laxer, allowing arbitrary chains of OCONVNOPs from unsafe.Pointer to uintptr. This CL changes order to be stricter to match escape analysis. Passes toolstash-check. Change-Id: Iadd210d2123accb2020f5728ea2a47814f703352 Reviewed-on: https://go-review.googlesource.com/c/go/+/229578 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.