[pull] master from golang:master - #209
Open
pull[bot] wants to merge 15 commits into
Open
Conversation
The comment mentions programs with //go:debug decoratemappings=0, but the test code has it set to 1. This doesn't run in the standard set of shorttests, only on the longtest builders, but it was skipped. For #72772 Change-Id: Ia9701011fc6f8708a422fbed328570196a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/823964 Auto-Submit: Michael Matloob <matloob@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Matloob <matloob@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Unify has long supported decoding a unify.Value into a Go value. We use this extensively post-unification in simdgen to extract the results of unification in a much more convenient (and type-safe) way. This implements the inverse: encoding a Go value to a unify.Value. It follows the same rules, so we'll be able to use the Go types defined in simdgen to produce well-formed unify.Values. Change-Id: I929f0d3225789da644f32fb284e54208f3c510d3 Reviewed-on: https://go-review.googlesource.com/c/go/+/823226 Reviewed-by: Junyang Shao <shaojunyang@google.com> Auto-Submit: Austin Clements <austin@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
Currently, the XED loader populates a fully dynamically-typed unify.Def directly for operations. This CL transitions to populating a well-typed Go Operand type and then mapping it into a unify value. In addition to using strong typing, this lets us use the common operand sorting code. No changes to generated files. Change-Id: Ic4ab7405dd68a85b626194c9c04f655514dcb5a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/823227 Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Austin Clements <austin@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Same as the prior change, but for the ARM64 (NEON) and SVE loaders. This CL transitions them from populating operands as a dynamically-typed unify.Def to populating a well-typed Go Operand type and then mapping it into a unify value. No changes to generated files. Change-Id: Ic8a11e234186b5b56f062173e5ebf14573de006d Reviewed-on: https://go-review.googlesource.com/c/go/+/823228 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Austin Clements <austin@google.com>
specgen had its own GOROOT finding logic. Drop that and converge it with the gentools GOROOT logic, which is robust to a broken Go tree. Change-Id: Ieac45bc4f29c3e5d8b05d9d52d65a326b84fcb56 Reviewed-on: https://go-review.googlesource.com/c/go/+/826904 Auto-Submit: Austin Clements <austin@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Currently, there are two things in _gen that depend on a working devel tree: gentools imports internal/diff, which only works if _gen is under the std module; and specgen uses golang.org/x/tools/go/packages to load and type-check simd/internal/spec. This CL addresses both of these, making it possible to run the generators with any toolchain back to Go 1.26. We fix the internal/diff import by simply duplicating the package contents (when are we going to have a standard diff package?). The specgen issue is more subtle: go/packages invokes the go tool, and the go tool will find std's go.mod, which says it requires Go 1.28, which forces it to use a devel toolchain. To fix this, we migrate away from go/packages to invoking the type checker directly. simd/internal/spec is a very lightweight package with almost no imports, so this is fine. Change-Id: I3b113f91d98251def3d004ba0905e9ef641f0689 Reviewed-on: https://go-review.googlesource.com/c/go/+/826905 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Austin Clements <austin@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
This CL deletes the ureader from testimporter and uses importer.ReadPackage directly. Change-Id: Ia594ec04acd370f8dc302aae6953fdc7d4e47ccd Reviewed-on: https://go-review.googlesource.com/c/go/+/829604 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
Fixes #81288 Change-Id: I983f6d3fa052582706cb3ce1ac55ac2d6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/830004 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Nicholas Husin <husin@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 828504 ("net/http: don't pin bufio buffers on idle HTTP/1
keep-alive connections") broke keep-alive connections over net.Conn
implementations whose deadline errors don't wrap
os.ErrDeadlineExceeded, such as gVisor's gonet (used by Tailscale's
netstack). Its idle buffer release probe sets a short read deadline
and uses errors.Is(err, os.ErrDeadlineExceeded) to distinguish
"connection merely idle" from a real error, so a bespoke timeout error
caused the server to close every keep-alive connection about 50ms
after each response. Likewise in connReader.handleReadErrorLocked.
So use old-school net.Error checks instead for compatibility.
CL 828504 also introduced a second bug, present even with modern
net.Conn implementations: the probe's expected timeout error reached
connReader.handleReadErrorLocked, which canceled the connection-level
context that every subsequent request's context on that connection
derives from. Any request arriving after an idle period longer than
50ms thus began with an already-canceled Context.
Updates #80735
Change-Id: Ia69d79e8e1fc30aec9e716ed5691db7474b05f0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/830364
Reviewed-by: Nicholas Husin <nsh@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Davanum Srinivas (dims) <davanum@gmail.com>
In HTTP/1, if we close a response body early prior to EOF, while allowing a concurrent read to happen, a deadlock will occur if the read reaches EOF. This is because both calls wait on the same eofc channel, and the persistConn readLoop only sends one value to the channel. This problem only occurs after the implementation of automatic response body draining; prior to that, closing the response body early will cause the eofc channel to be closed, unblocking all calls. Fix this by making sure that bodyEOFSignal.earlyCloseFn and bodyEOFSignal.fn are mutually exclusive. Additionally, disambiguate between when a response body has been closed early vs when reading it returns a non-EOF error. Otherwise, when the body read returns a non-EOF error, persistConn readLoop will linger around trying to send to eofc until the response body is closed rather than exiting immediately. Fixes #81404 Change-Id: I706ba39afd08b605fa80bb9d99114f4f6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/829984 Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This adds specgen directives for marking methods/functions as commutative and for noting the documentation category of all functions in a file. Commutativity information will be necessary for spec to replace categories.yaml, and categories were valuable in my apisum tool (which has inspired a lot of the approach of spec). Change-Id: I3f948abc3c0ab967284f645adfe50b5e337d2e81 Reviewed-on: https://go-review.googlesource.com/c/go/+/826906 Auto-Submit: Austin Clements <austin@google.com> TryBot-Bypass: David Chase <drchase@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
The current "zL=xL" constraint doesn't apply width rounding, so we
don't get
(Float64x2).ConverToFloat32() Float32x4
This changes the constraint to z={zB}{zN}x{xL}, which does apply width
rounding, so we do get the width-rounded method.
Change-Id: I9248f858459aa83ec516f016e682506771ad7385
Reviewed-on: https://go-review.googlesource.com/c/go/+/828144
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Austin Clements <austin@google.com>
The setting of math_big_pure_go dates to when we required Go 1.4 to bootstrap the compiler in CL 31142, and its considerations don't apply anymore. The setting of purego was added in CL 415934 so that we could run bootstrap using a gccgo compiler, but we can't currently use gccgo to bootstrap the go command because we need a version newer than what gccgo supports. gccgo would also need math_big_pure_go for the same reason. Remove the setting. If gccgo starts supporting newer versions of go we can easily add these back but just for the case where the bootstrap toolchain is gccgo. The main reason to do this is to enable using the assembly sha256 implementation when building the go command using the bootstrap toolchain. The go command hashes things left and right so it's important it's fast. For #81386 Change-Id: I881448ca33fda78fe391ed014e915d9a6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/829084 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Matloob <matloob@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
…sure An interaction between b.Loop and rangefunc caused overly slow results to be reported; rangefunc introduces bookkeeping and error-checking variables, that are normally optimized out for loops small enough (and in theory cheap enough) for the usual inlining to occur. The transformation for b.Loop instead preserved those variables to prevent their optimization, which was the cause of the apparent slowdown. This then produced an absurdly good result, caused because the b.Loop instrumentation was not applied to closures occurring in the benchmark -- such as those created by rangefunc -- and thus results were not preserved, and optimization could remove the benchmarked work entirely. The fix for this is to instrument the closure. Several permutations of backwards looping were added to a benchmark to hopefully reveal any remaining glitches; TBD what is a "glitch" and what is "working as intended". Updates #80971. Change-Id: I49dbf2919908d045765ffd72d5c5be28cf153138 Reviewed-on: https://go-review.googlesource.com/c/go/+/825084 Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change splits the build action into two actions to prepare for early export. The first action will represent the first half of a compile, producing the export data, while the second action will represent the second half, producing the object for the linker. For now the full cmd/compile invocation is done in the first action, but we will later arrange for the first action to complete as soon as the export data is ready, unblocking the dependent builds. For the reviewer: we end up combining the export and object files and giving them a single build id (see CL 818461) but after looking at this CL I wonder if we should just cache them separately to simmplfy things. For #15734 Change-Id: I1bd4ea76ed9c1411ea4bf88e60fed6396a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/827844 Reviewed-by: Michael Matloob <matloob@google.com> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )