-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge upstream master
into microsoft/main
#247
Merged
microsoft-golang-review-bot
merged 14 commits into
microsoft/main
from
dev/auto-merge/microsoft/main
Nov 2, 2021
Merged
Merge upstream master
into microsoft/main
#247
microsoft-golang-review-bot
merged 14 commits into
microsoft/main
from
dev/auto-merge/microsoft/main
Nov 2, 2021
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
Fixes #49213 Change-Id: I2bfc151b74b0d14efbd00e5d28584f4180126c5d Reviewed-on: https://go-review.googlesource.com/c/go/+/359656 Trust: Robert Griesemer <gri@golang.org> Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> TryBot-Result: Go Bot <gobot@golang.org>
If a identical input is already present in the corpus, don't re-add it. This may happen when the same input produces a different coverage map, causing the coordinator to think it has found a new input. This fixes a race between reading/writing cached inputs. Fixes #48721 Change-Id: I4807602f433c2b99396d25ceaa58b827796b3555 Reviewed-on: https://go-review.googlesource.com/c/go/+/359755 Trust: Roland Shoemaker <roland@golang.org> Trust: Katie Hockman <katie@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Katie Hockman <katie@golang.org>
Fixes #49234. Change-Id: I64c1eab0dce2bbe990343b43a32858a6c9f3dcda Reviewed-on: https://go-review.googlesource.com/c/go/+/359878 Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
This benchmark simulates object starvation in order to force Ps to steal objects from other Ps. Extracted from CL 314229. Change-Id: Iee31df355ba04d80fbd91c4414e397a375e6d6d7 Reviewed-on: https://go-review.googlesource.com/c/go/+/360256 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Trust: Cherry Mui <cherryyz@google.com>
…r message When type inference cannot infer type arguments it prints the list of inferred type arguments (often empty) at the end of the error message. This was meant as debugging support only. Removed for now. Eventually we should provide a better error message. Fixes #49272. Change-Id: I68d43a6ace91081009cab0f2fbad7bfbddf5e76b Reviewed-on: https://go-review.googlesource.com/c/go/+/360554 Trust: Robert Griesemer <gri@golang.org> Trust: Dan Scales <danscales@google.com> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Previously, when resolving references of form (https://golang.org/?hello).ResolveReference(?) we only used URL.RawQuery to determine whether or not a query part is defined. Go 1.7 introduced URL.ForceQuery as a flag for the situation where a query part is provided but empty. But we did not use it in ResolveReference. This leads to the erroneous output https://golang.org/?hello when the correct output should be https://golang.org/? This commit rectifies that error. Fixes #46033 Change-Id: I05bc0b48bf2bbf13b4ddc0dd10599ea613dc2188 Reviewed-on: https://go-review.googlesource.com/c/go/+/317930 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Damien Neil <dneil@google.com>
Co-authored-by: Alex Willmer <alex@moreati.org.uk> (GitHub @moreati) Co-authored-by: Alexander Yastrebov <yastrebov.alex@gmail.com> Co-authored-by: David Anderson <dave@natulte.net> (Tailscale CLA) Co-authored-by: David Crawshaw <crawshaw@tailscale.com> (Tailscale CLA) Co-authored-by: Dmytro Shynkevych <dmytro@tailscale.com> (Tailscale CLA) Co-authored-by: Elias Naur <mail@eliasnaur.com> Co-authored-by: Joe Tsai <joetsai@digital-static.net> (Tailscale CLA) Co-authored-by: Jonathan Yu <jawnsy@cpan.org> (GitHub @jawnsy) Co-authored-by: Josh Bleecher Snyder <josharian@gmail.com> (Tailscale CLA) Co-authored-by: Maisem Ali <maisem@tailscale.com> (Tailscale CLA) Co-authored-by: Manuel Mendez (Go AUTHORS mmendez534@...) Co-authored-by: Matt Layher <mdlayher@gmail.com> Co-authored-by: Noah Treuhaft <noah.treuhaft@gmail.com> (GitHub @nwt) Co-authored-by: Stefan Majer <stefan.majer@gmail.com> Co-authored-by: Terin Stock <terinjokes@gmail.com> (Cloudflare CLA) Co-authored-by: Tobias Klauser <tklauser@distanz.ch> Fixes #46518 Change-Id: I0041f9e1115d61fa6e95fcf32b01d9faee708712 Reviewed-on: https://go-review.googlesource.com/c/go/+/339309 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Trust: Brad Fitzpatrick <bradfitz@golang.org>
…type In case of reference to method call of an imported fully-instantiated type, nameNode.Func will be nil causes checkFetchBody panic. To fix this, make sure checkFetchBody is only called when Func is not nil. Fixes #49246 Change-Id: I32e9208385a86d4600d8ebf6f5efd8fca571ea16 Reviewed-on: https://go-review.googlesource.com/c/go/+/360056 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Trust: Dan Scales <danscales@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
golang.org/x/sys contains similar code and also needs updating. Change-Id: Id00177397639075d4792eb253829d8042941b70c Reviewed-on: https://go-review.googlesource.com/c/go/+/360602 Trust: Josh Bleecher Snyder <josharian@gmail.com> Trust: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: I63aac663da4ce7bdd198d385f87929c74f6a5cf8 Reviewed-on: https://go-review.googlesource.com/c/go/+/360601 Trust: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The main item of interest here is the allocs. BenchmarkReadWriteMsgUDPAddrPort-8 195920 6450 ns/op 176 B/op 5 allocs/op Change-Id: I358bd18888ce254b6c6d5d5c920e6d22ce5a2ef4 Reviewed-on: https://go-review.googlesource.com/c/go/+/360595 Trust: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Instead of implementing ReadMsgUDPAddrPort in terms of ReadMsgUDP, do it the other way around. This keeps the code minimal while still avoiding allocs. We could also rearrange ReadMsgUDP to be mid-stack inlined to avoid allocating the *UDPAddr, but anyone who's trying to eliminate allocs should use ReadMsgUDPAddrPort instead anyway, because ReadMsgUDP will always allocate at least once (the IP slice). name old time/op new time/op delta ReadWriteMsgUDPAddrPort-8 5.26µs ± 3% 5.29µs ± 6% ~ (p=0.429 n=12+13) name old alloc/op new alloc/op delta ReadWriteMsgUDPAddrPort-8 176B ± 0% 128B ± 0% -27.27% (p=0.000 n=15+15) name old allocs/op new allocs/op delta ReadWriteMsgUDPAddrPort-8 5.00 ± 0% 4.00 ± 0% -20.00% (p=0.000 n=15+15) Change-Id: I15228cb4ec4f13f2f390407b6c62c44c228e7201 Reviewed-on: https://go-review.googlesource.com/c/go/+/360596 Trust: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is one step towards optimizing WriteMsgUDPAddrPort. Further steps remain, namely to avoid the syscall.Sockaddr interface, as we do for UDPConn.WriteToUDP and UDPConn.ReadFromUDP. A previous change optimized ReadMsgUDPAddrPort by having ReadMsgUDP call ReadMsgUDPAddrPort rather than the other way around. This change does not implement WriteMsgUDP in terms of WriteMsgUDPAddrPort, because a few layers deep, on posix platforms only (in ipToSockaddrInet4 and ipToSockaddrInet6), is special handling of zero-length IP addresses and IPv4zero. It treats IP(nil) as equivalent to 0.0.0.0 or ::, and 0.0.0.0 as equivalent to :: in an IPv6 context. Based on the comments, I suspect that this treatment was intended for the Listen* API, not the Write* API, but it affects both, and I am nervous about changing the behavior for Write*. The netip package doesn't have a way to represent a "zero-length IP address" as distinct from an invalid IP address (which is a good thing), so to implement WriteMsgUDP using WriteMsgUDPAddrPort, we would have to duplicate this special handling at the start of WriteMsgUDP. But this handling depends on whether the UDPConn is an IPv4 or an IPv6 conn, which is also platform-specific information. As a result, every attempt I made to implement WriteMsgUDP using WriteMsgUDPAddrPort while preserving behavior ended up being considerably worse than copy/paste/modify. This does mean that WriteMsgUDP and WriteMsgUDPAddrPort will have different behavior in these cases. name old time/op new time/op delta ReadWriteMsgUDPAddrPort-8 5.29µs ± 6% 5.02µs ± 7% -5.14% (p=0.000 n=13+15) name old alloc/op new alloc/op delta ReadWriteMsgUDPAddrPort-8 128B ± 0% 64B ± 0% -50.00% (p=0.000 n=15+15) name old allocs/op new allocs/op delta ReadWriteMsgUDPAddrPort-8 4.00 ± 0% 2.00 ± 0% -50.00% (p=0.000 n=15+15) Change-Id: Ia78eb49734f4301d7772dfdbb5a87e4d303a9f7a Reviewed-on: https://go-review.googlesource.com/c/go/+/360597 Trust: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
microsoft-golang-bot
requested review from
microsoft-golang-review-bot and
a team
as code owners
November 2, 2021 04:41
microsoft-golang-review-bot
approved these changes
Nov 2, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Auto-approving.
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.
🔃 This is an automatically generated PR merging upstream
master
intomicrosoft/main
.This PR should auto-merge itself when PR validation passes. If CI fails and you need to make fixups, be sure to use a merge commit, not a squash or rebase!
After these changes, the difference between upstream and the branch is: