- 24 Jul, 2018 1 commit
-
-
Brad Fitzpatrick authored
There's a 50ms threshold in net/http.Transport that this test sometimes hitting on slower devices. That was unrelated to what this test was trying to test. So instead just t.Skip on RoundTrip errors unless the failure was quick (under 25ms), in which case the error must've been about something else. Our fast machines should catch regressions there. Fixes #25366 Change-Id: Ibe8e2716a5b68558b57d0b8b5c46f38e46a2cba2 Reviewed-on: https://go-review.googlesource.com/125555 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 23 Jul, 2018 4 commits
-
-
Ian Lance Taylor authored
Fixes #26486 Updates #26555 Change-Id: I402137b796e574e9b085ab54290d1b4ef73d3fcc Reviewed-on: https://go-review.googlesource.com/125039Reviewed-by: Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
Contains portions and modified portions of CL 103815 Fixes #24607 Change-Id: Ic330850a0f098f183315f04ea4780eded46c5b77 Reviewed-on: https://go-review.googlesource.com/125515Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
marwan-at-work authored
Fixes #26536 Change-Id: I75d284bd39af0a06e31d18c7f7745c5a8ecbe6ac GitHub-Last-Rev: 88040a9edb0cb547a498cb8c8b662eb8729eb8bf GitHub-Pull-Request: golang/go#26537 Reviewed-on: https://go-review.googlesource.com/125436Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
For unknown reasons, linking against CoreFoundation on macOS 10.10 sometimes causes mmap to ignore the hint address, which makes the Go allocator incompatible with TSAN. Currently, the effect of this is to run the allocator out of arena hints on the very first allocation, causing a "too many address space collisions for -race mode" panic. This CL skips the cgo tests that link against CoreFoundation in race mode. Updates #26475. Updates #26513. Change-Id: I52ec638c99acf5d4966e68ff0054f7679680dac6 Reviewed-on: https://go-review.googlesource.com/125304 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
- 20 Jul, 2018 11 commits
-
-
Cherry Zhang authored
Gccgo produced incorrect order of evaluation for expressions involving &&, || subexpressions. The fix is CL 125299. Updates #26495. Change-Id: I18d873281709f3160b3e09f0b2e46f5c120e1cab Reviewed-on: https://go-review.googlesource.com/125301 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Daniel Martí authored
Add the tools section with a Gofmt sub-section, just like in go1.10.html. Instead of copying the two last paragraphs from 1.10, which warn users about the hidden complexity of enforcing gofmt, move that to go/format and link to it. While at it, remove a duplicate "Tools" header that was likely added by accident. Fixes #26228. Change-Id: Ic511c44b2b86f82a41f2b78dd7e7482d694b6c62 Reviewed-on: https://go-review.googlesource.com/122295Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
LE Manh Cuong authored
Fixes #26451 Change-Id: Icd8d6d55dc42adb5c8953787eec7eb29ba46b2aa Reviewed-on: https://go-review.googlesource.com/125215Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Jack authored
The doc for ResponseRecorder.Result guarantees that the body of the returned http.Response will be non-nil, but this only holds true if the caller's body is non-nil. With this change, if the caller's body is nil then the returned response's body will be an empty io.ReadCloser. Fixes #26442 Change-Id: I3b2fe4a2541caf9997dbb8978bbaf1f58cd1f471 GitHub-Last-Rev: d802967d89e89c50077fb2d0d455163dcea0eb43 GitHub-Pull-Request: golang/go#26453 Reviewed-on: https://go-review.googlesource.com/124875Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Than McIntosh authored
Rejigger the DWARF tests to ensure that they run in a reasonable amount of time in short mode, particularly the "abstract origin sanity" testpoints. Updates #26470 Change-Id: Idae9763ac20ea999fa394595aacfcd1e271293ae Reviewed-on: https://go-review.googlesource.com/125295Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Alberto Donizetti authored
Change-Id: I659bc5b61dade9438b122e6994da022946f5e1d3 Reviewed-on: https://go-review.googlesource.com/125255Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Alberto Donizetti authored
Change-Id: I3bcf8850ad3873f2627ba017cbfb8b7a8c9cf467 Reviewed-on: https://go-review.googlesource.com/125256Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
If we have go get -u x1@v1 x2@v2 and x1 depends on x2, use v2 as the "upgraded" x2 chosen by -u instead of letting -u pick something (say, v2.1) and then immediately overriding it. This avoids chasing down the deps from v2.1 and also avoids them polluting the overall module graph. This fix also lets us delete some code in the preparation step, reducing the overall latency of get -u. Suggested by Bryan Mills in https://go-review.googlesource.com/c/vgo/+/122396/6#371. Fixes #26342. Change-Id: I50fa842304820d3f16f66a8e65dea695e2b0f88b Reviewed-on: https://go-review.googlesource.com/124856Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
If x v1.0.0 requires y v1.2.0, then go get x@v1.0.0 y@v1.0.0 needs to fail gracefully. Fixes #25917. Change-Id: I9b426af23a30310fcb0c3545a8d97feb58b8ddbe Reviewed-on: https://go-review.googlesource.com/124800Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
While writing the GOPROXY docs it occurred to me that versions can contain upper-case letters as well. The docs therefore say that versions are case-encoded the same as paths in the proxy protocol (and therefore in the cache as well). Make it so. Change-Id: Ibc0c4af0192a4af251e5dd6f2d36cda7e529099a Reviewed-on: https://go-review.googlesource.com/124795Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Vlad Krasnov authored
Use the dedicated AES* and PMULL* instructions to accelerate AES-GCM name old time/op new time/op delta AESGCMSeal1K-46 12.1µs ± 0% 0.9µs ± 0% -92.66% (p=0.000 n=9+10) AESGCMOpen1K-46 12.1µs ± 0% 0.9µs ± 0% -92.43% (p=0.000 n=10+10) AESGCMSign8K-46 58.6µs ± 0% 2.1µs ± 0% -96.41% (p=0.000 n=9+8) AESGCMSeal8K-46 92.8µs ± 0% 5.7µs ± 0% -93.86% (p=0.000 n=9+9) AESGCMOpen8K-46 92.9µs ± 0% 5.7µs ± 0% -93.84% (p=0.000 n=8+9) name old speed new speed delta AESGCMSeal1K-46 84.7MB/s ± 0% 1153.4MB/s ± 0% +1262.21% (p=0.000 n=9+10) AESGCMOpen1K-46 84.4MB/s ± 0% 1115.2MB/s ± 0% +1220.53% (p=0.000 n=10+10) AESGCMSign8K-46 140MB/s ± 0% 3894MB/s ± 0% +2687.50% (p=0.000 n=9+10) AESGCMSeal8K-46 88.2MB/s ± 0% 1437.5MB/s ± 0% +1529.30% (p=0.000 n=9+9) AESGCMOpen8K-46 88.2MB/s ± 0% 1430.5MB/s ± 0% +1522.01% (p=0.000 n=8+9) This change mirrors the current amd64 implementation, and provides optimal performance on a range of arm64 processors including Centriq 2400 and Apple A12. By and large it is implicitly tested by the robustness of the already existing amd64 implementation. The implementation interleaves GHASH with CTR mode to achieve the highest possible throughput, it also aggregates GHASH with a factor of 8, to decrease the cost of the reduction step. Even thought there is a significant amount of assembly, the code reuses the go code for the amd64 implementation, so there is little additional go code. Since AES-GCM is critical for performance of all web servers, this change is required to level the playfield for arm64 CPUs, where amd64 currently enjoys an unfair advantage. Ideally both amd64 and arm64 codepaths could be replaced by hypothetical AES and CLMUL intrinsics, with a few additional vector instructions. Fixes #18498 Fixes #19840 Change-Id: Icc57b868cd1f67ac695c1ac163a8e215f74c7910 Reviewed-on: https://go-review.googlesource.com/107298 Run-TryBot: Vlad Krasnov <vlad@cloudflare.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 19 Jul, 2018 24 commits
-
-
Bryan C. Mills authored
I forgot to run trybots on CL 123758, and the test failed on Windows because I hard-coded a slash-delimited path. Use the tent-in-a-box operator ([/\\]) to make the path platform-agnostic. Change-Id: I9113ab60d21152c11e2ebdf822b58a44b1b38574 Reviewed-on: https://go-review.googlesource.com/125115 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Andrew Bonventre authored
Change-Id: Ie706c43c9a11cf30ca0f2139a4e9eabac8c75c75 Reviewed-on: https://go-review.googlesource.com/125096 Run-TryBot: Andrew Bonventre <andybons@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
Update #26469 Change-Id: Id8b8d1c0db48374d5d3dc663a77187a73f60c9a5 Reviewed-on: https://go-review.googlesource.com/125037 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
Fixes #25980. Change-Id: I33c8e72871ffbb1cd1babbcd5dabc8cac0bbcaed Reviewed-on: https://go-review.googlesource.com/123758Reviewed-by: Russ Cox <rsc@golang.org>
-
David Chase authored
The test runs far too long for -short mode (4 seconds). Also removed useless test of now-disconnected knob (GO_SSA_PHI_LOC_CUTOFF), which cuts 4 seconds to 2 seconds (which is still too long), and finished removing the disconnected knob. Updates #26469. Change-Id: I6c594227c4a5aaffee46832049bdbbf570d86e60 Reviewed-on: https://go-review.googlesource.com/125075 Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
-
Yury Smolsky authored
If the the package cannot be built, "go test" and "go vet" should not run the "vet" tool. In that case only errors from the compilers will be displayed. Fixes #26125 Change-Id: I5da6ba64bae5f44feaf5bd4e765eea85533cddd4 Reviewed-on: https://go-review.googlesource.com/123938 Run-TryBot: Yury Smolsky <yury@smolsky.by> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
David du Colombier authored
CL 123577 added TestScript. The install_rebuild_gopath test was failing on Plan 9 because it defines a GOPATH using the ':' separator, while Plan 9 expects the '\000' separator in environment variables. This change fixes the script engine by defining a new ":" environment variable set to OS-specific path list separator. The install_rebuild_gopath test has been updated to use "${:}" instead of ":". Fixes #26421. Change-Id: I58a97f882cdb48cc0836398b0d98a80ea58041ba Reviewed-on: https://go-review.googlesource.com/124435 Run-TryBot: David du Colombier <0intro@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Richard Musiol authored
When using callbacks, it is not necessarily a deadlock if there is no runnable goroutine, since a callback might still be pending. If there is no callback pending, Node.js simply exits with exit code zero, which is not desired if the Go program is still considered running. This is why an explicit check on exit is used to trigger the "deadlock" error. This CL makes it so this is Go's normal "deadlock" error, which includes the stack traces of all goroutines. Updates #26382 Change-Id: If88486684d0517a64f570009a5ea0ad082679a54 Reviewed-on: https://go-review.googlesource.com/123936 Run-TryBot: Richard Musiol <neelance@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
It's important for a smooth transition for non-module users not to change operation in GOPATH/src by default in Go 1.11, even if go.mod exists in a downloaded dependency. Even so, users create go.mod and then are confused about why 'go get' commands seem to behave oddly, when in fact they are getting the old 'go get'. Try to split the difference by printing a warning in 'go get' when run in a tree that would normally be considered a module if only it were outside GOPATH/src. Change-Id: I55a1cbef127f3f36de54a8d7b93e1fc64bf0a708 Reviewed-on: https://go-review.googlesource.com/124859Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
If there was a mod and non-mod meta tag for a given prefix, the meta tag extractor was already dropping the non-mod meta tag. But we might have mod and non-mod meta tags with different prefixes, in which case the mod tag should prevail when both match. Fixes #26200. Change-Id: I17ab361338e270b9fa03999ad1954f2bbe0f5017 Reviewed-on: https://go-review.googlesource.com/124714Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Vlad Krasnov authored
This patch ports the existing optimized P256 implementation to arm64. name old time/op new time/op delta pkg:crypto/ecdsa goos:linux goarch:arm64 SignP256 539µs ±13% 43µs ± 2% -91.95% (p=0.000 n=20+20) SignP384 13.2ms ± 1% 13.2ms ± 1% ~ (p=0.739 n=10+10) VerifyP256 1.57ms ± 0% 0.12ms ± 0% -92.40% (p=0.000 n=18+20) KeyGeneration 391µs ± 0% 25µs ± 0% -93.62% (p=0.000 n=9+9) pkg:crypto/elliptic goos:linux goarch:arm64 BaseMult 1.66ms ± 0% 1.65ms ± 1% ~ (p=0.079 n=9+10) BaseMultP256 389µs ± 0% 22µs ± 1% -94.28% (p=0.000 n=19+20) ScalarMultP256 1.03ms ± 0% 0.09ms ± 0% -91.25% (p=0.000 n=19+20) name old alloc/op new alloc/op delta pkg:crypto/ecdsa goos:linux goarch:arm64 SignP256 5.47kB ± 0% 3.20kB ± 0% -41.50% (p=0.000 n=20+20) SignP384 2.32MB ± 0% 2.32MB ± 0% ~ (p=0.739 n=10+10) VerifyP256 7.65kB ± 4% 0.98kB ± 0% -87.24% (p=0.000 n=20+20) KeyGeneration 1.41kB ± 0% 0.69kB ± 0% -51.05% (p=0.000 n=9+10) pkg:crypto/elliptic goos:linux goarch:arm64 BaseMult 224B ± 0% 224B ± 0% ~ (all equal) BaseMultP256 1.12kB ± 0% 0.29kB ± 0% -74.29% (p=0.000 n=20+20) ScalarMultP256 1.59kB ± 7% 0.26kB ± 0% -83.91% (p=0.000 n=20+20) name old allocs/op new allocs/op delta pkg:crypto/ecdsa goos:linux goarch:arm64 SignP256 67.0 ± 0% 35.0 ± 0% -47.76% (p=0.000 n=20+20) SignP384 17.5k ± 0% 17.5k ± 0% ~ (p=0.725 n=10+10) VerifyP256 97.2 ± 3% 17.0 ± 0% -82.52% (p=0.000 n=20+20) KeyGeneration 21.0 ± 0% 13.0 ± 0% -38.10% (p=0.000 n=10+10) pkg:crypto/elliptic goos:linux goarch:arm64 BaseMult 5.00 ± 0% 5.00 ± 0% ~ (all equal) BaseMultP256 16.0 ± 0% 6.0 ± 0% -62.50% (p=0.000 n=20+20) ScalarMultP256 19.9 ± 6% 5.0 ± 0% -74.87% (p=0.000 n=20+20) Fixes #22806 Change-Id: I12b343a27e6544189334f99c84242bb59db70a76 Reviewed-on: https://go-review.googlesource.com/121360 Run-TryBot: Vlad Krasnov <vlad@cloudflare.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Vlad Krasnov <vlad@cloudflare.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Updates http2 to x/net/http2 git rev a680a1efc54 for: http2: reject large SETTINGS frames or those with duplicates https://golang.org/cl/124735 Change-Id: I2168d1d1eef9c63b1a9c06b514b77fae16f920ed Reviewed-on: https://go-review.googlesource.com/125036 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Change-Id: I5a82aec66332f52e304f647758221b5f30b4e2b6 Reviewed-on: https://go-review.googlesource.com/124701Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
This was an unfortunate debugging print introduced while working on the unfortunately large CL 123576. At least now we're done with that awfulness. Change-Id: Ib83db59382a799f649832d22d3c6f039d2ef9d2c Reviewed-on: https://go-review.googlesource.com/125015Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
go.sum accumulates cruft as modules are added and removed as direct and indirect dependencies. Instead of exposing all that cruft, let "go mod -sync" clean it out. Fixes #26381. Change-Id: I7c9534cf7cc4579f7f82646d00ff691c87a13c4a Reviewed-on: https://go-review.googlesource.com/124713Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
People are (understandably) confused by creating go.mod files in GOPATH/src and then having the go command not use modules in those directories. We can't change that behavior (or we'll break non-module users of GOPATH) but we can force 'go mod' (including 'go mod -init') to fail loudly in that case. If this is not enough, the next step would be to print a warning every time the go command is run in a GOPATH/src directory with a go.mod but module mode hasn't triggered. But that will annoy all the non-module users. Hopefully anyone confused will eventually run a 'go mod' command of some kind, which will fail loudly. Fixes #26365. Change-Id: I8c5fe987fbc3f8d2eceb1138e6862a391ade150c Reviewed-on: https://go-review.googlesource.com/124708Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
Also document module use of GOPATH including GOPATH/src/mod and GOPATH/bin (unless GOBIN is set). Fixes #26399. Fixes #26406. Change-Id: I7be8eaf110f4fa6fc76ea4cd39aea3dd8addf0b0 Reviewed-on: https://go-review.googlesource.com/124707Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
Now pkg@none actually removes the pkg instead of dying. For #26342. Change-Id: I9df7281ed8fd24480109b36f33a563f92e279244 Reviewed-on: https://go-review.googlesource.com/124796Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
Change-Id: Iba68b3aaf4a132bd4ca44edf4912a46549d2ef8f Reviewed-on: https://go-review.googlesource.com/124700Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
The original pseudo-version design used versions of the form v0.0.0-yyyymmddhhmmss-abcdef123456 These were intentionally chosen to be valid semantic versions that sort below any explicitly-chosen semantic version (even v0.0.0), so that they could be used before anything was tagged but after that would essentially only be useful in replace statements (because the max operation during MVS would always prefer a tagged version). Then we changed the go command to accept hashes on the command line, so that you can say go get github.com/my/proj@abcdef and it will download and use v0.0.0-yyyymmddhhmmss-abcdef123456. If you were using v1.10.1 before and this commit is just little bit newer than that commit, calling it v0.0.0-xxx is confusing but also harmful: the go command sees the change from v1.10.1 to the v0.0.0 pseudoversion as a downgrade, and it downgrades other modules in the build. In particular if some other module has a requirement of github.com/my/proj v1.9.0 (or later), the pseudo-version appears to be before that, so go get would downgrade that module too. It might even remove it entirely, if every available version needs a post-v0.0.0 version of my/proj. This CL introduces new pseudo-version forms that can be used to slot in after the most recent explicit tag before the commit. If the most recent tagged commit before abcdef is v1.10.1, then now we will use v1.10.2-0.yyyymmddhhmmss-abcdef123456 This has the right properties for downgrades and the like, since it is after v1.10.1 but before almost any possible successor, such as v1.10.2, v1.10.2-1, or v1.10.2-pre. This CL also uses those pseudo-version forms as appropriate when mapping a hash to a pseudo-version. This fixes the downgrade problem. Overall, this CL reflects our growing recognition of pseudo-versions as being like "untagged prereleases". Issue #26150 was about documenting best practices for how to work around this kind of accidental downgrade problem with additional steps. Now there are no additional steps: the problem is avoided by default. Fixes #26150. Change-Id: I402feeccb93e8e937bafcaa26402d88572e9b14c Reviewed-on: https://go-review.googlesource.com/124515Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
Repos written before the introduction of semantic import versioning introduced tags like v2.0.0, v3.0.0, and so on, expecting that (1) the import path would remain unchanged, and perhaps also (2) there would be at most one copy of the package in a build. We've always accommodated these by mapping them into the v0/v1 version range, so that if you ran go get k8s.io/client-go@v8.0.0 it would not complain about v8.x.x being a non-v1 version and instead would map that version to a pseudo-version in go.mod: require k8s.io/client-go v0.0.0-20180628043050-7d04d0e2a0a1 The pseudo-version fails to capture two important facts: first, that this really is the v8.0.0 tag, and second, that it should be preferred over any earlier v1 tags. A related problem is that running "go get k8s.io/client-go" with no version will choose the latest v1 tag (v1.5.1), which is obsolete. This CL introduces a new version suffix +incompatible that indicates that the tag should be considered an (incompatible) extension of the v1 version sequence instead of part of its own major version with its own versioned module path. The requirement above can now be written: require k8s.io/client-go v8.0.0+incompatible (The +metadata suffix is a standard part of semantic versioning, and that suffix is ignored when comparing two versions for precedence or equality. As part of canonicalizing versions recorded in go.mod, the go command has always stripped all such suffixes. It still strips nearly all: only +incompatible is preserved now.) In addition to recognizing the +incompatible, the code that maps a commit hash to a version will use that form when appropriate, so that go get k8s.io/client-go@7d04d0 will choose k8s.io/client-go@v8.0.0+incompatible. Also, the code that computes the list of available versions from a given source code repository also maps old tags to +incompatible versions, for any tagged commit in which a go.mod file does not exist. Therefore go list -m -versions k8s.io/client-go@latest will show k8s.io/client-go v1.4.0 v1.5.0 v1.5.1 v2.0.0-alpha.0+incompatible ... v8.0.0+incompatible and similarly go get k8s.io/client-go will now choose v8.0.0+incompatible as the meaning of "latest tagged version". The extraction of +incompatible versions from source code repos depends on a codehost.Repo method ReadFileRevs, to do a bulk read of multiple revisions of a file. That method is only implemented for git in this CL. Future CLs will need to add support for that method to the other repository implementations. Documentation for this change is in CL 124515. Fixes #26238. Change-Id: I5bb1d7a46b5fffde34a3c0e6f8d19d9608188cea Reviewed-on: https://go-review.googlesource.com/124384 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
Windows networking doesn't work without this environment variable (#25210). Re-enable TestScript on Windows, and fix two minor failures. Fixes #26457. Change-Id: Id9bea49dfb58403195c29c3d831a532ef0f9a233 Reviewed-on: https://go-review.googlesource.com/124858 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
TSAN for Go only supports heap address in the range [0x00c000000000, 0x00e000000000). However, we currently create heap hints of the form 0xXXc000000000 for XX between 0x00 and 0x7f. Even for XX=0x01, this hint is outside TSAN's supported heap address range. Fix this by creating a slightly different set of hints in race mode, all of which fall inside TSAN's heap address range. This should fix TestArenaCollision flakes. That test forces the runtime to use later heap hints. Currently, this always results in TSAN "failed to allocate" failures on Windows (which happens to have a slightly more constrained TSAN layout than non-Windows). Most of the time we don't notice these failures, but sometimes it crashes TSAN, leading to a test failure. Fixes #25698. Change-Id: I8926cd61f0ee5ee00efa77b283f7b809c555be46 Reviewed-on: https://go-review.googlesource.com/123780 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Keith Randall authored
Code fix was in CL 122556. This is a corresponding test case. Fixes #26426 Change-Id: Ib8769f367aed8bead029da0a8d2ddccee1d1dccb Reviewed-on: https://go-review.googlesource.com/124535 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-