- 19 Jul, 2018 15 commits
-
-
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>
-
Daniel Martí authored
The backwards incompatible changes were undone in CL 120355, while still preserving the additions needed for assignments in templates to work. Change-Id: Ie76a798916ef36509c88e171a04bb2cf2a3d7e8e Reviewed-on: https://go-review.googlesource.com/124917Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
David Chase authored
Until we figure out how to deal with gdb on Darwin (doesn't read compressed DWARF from binaries), avoid compressing DWARF in that case so that the test will still yield meaningful results. This is also reported to be a problem for Windows. Problem also exists for lldb, but this test doesn't check lldb. Updates #25925 Change-Id: I85c0e5db75f3329957290500626a3ac7f078f608 Reviewed-on: https://go-review.googlesource.com/124712 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
-
Russ Cox authored
I don't know why it's failing. Filed #26457. Change-Id: I84833293a572c5a1a25135bd01cb88518fc7441e Reviewed-on: https://go-review.googlesource.com/124857 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Pointed out in CL 122396. An empty prefix has already been handled above. Change-Id: Ib94df0a9c8c0517f932b90126232111caa9ad289 Reviewed-on: https://go-review.googlesource.com/124797Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
Change-Id: I249bb848c9911948dbd84cd88ad043a61ed6ea6b Reviewed-on: https://go-review.googlesource.com/124699Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
Change-Id: Iba185e00e9df2462e9089566053f6c64e24a6a92 Reviewed-on: https://go-review.googlesource.com/124698Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
Change-Id: I8a36fad061bdf9a19f40531511f3f5717db13b60 Reviewed-on: https://go-review.googlesource.com/124697 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Russ Cox authored
Change-Id: If0976d15027db795f1383ef709c49c838cbb6953 Reviewed-on: https://go-review.googlesource.com/124696 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Brad Fitzpatrick authored
It was flaky on slower machines. Per report at https://github.com/golang/go/issues/23399#issuecomment-405792381 Change-Id: I7cab02821f78b5ce02ea51089d7eb51723f9705f Reviewed-on: https://go-review.googlesource.com/124835 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Rob Pike authored
Completely replace the opener, which had become not only stale but bad, expand the discussion of the gopher, and generally provide prose more connected to the present than to the programming world of 2007. Fixes #26107 Change-Id: I5e72f0c81e71d1237fe142dc26114991329a6996 Reviewed-on: https://go-review.googlesource.com/124616Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 18 Jul, 2018 25 commits
-
-
Ian Lance Taylor authored
Change-Id: Ic1ff580573711a6c91c1d5e3eb019a298a2fec49 Reviewed-on: https://go-review.googlesource.com/124837Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Change-Id: I9008afdc8c38c440ea083a4f2bed0d2253e112f0 Reviewed-on: https://go-review.googlesource.com/124836Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Andrew Bonventre authored
Change-Id: I3e2a19fe90334f0c1ed1593c7a9a3a458f15d8e8 Reviewed-on: https://go-review.googlesource.com/124799Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Andrew Bonventre authored
Change-Id: Ib488a78802ad730e7c6b3618eab24c259f4bebd1 Reviewed-on: https://go-review.googlesource.com/124798Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Brad Fitzpatrick authored
Change-Id: I30d2b4b94f26300f2cf7b4ecd328a4875d69db51 Reviewed-on: https://go-review.googlesource.com/124777Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Hana (Hyang-Ah) Kim authored
The final API uses 'region' instead of 'span' from the proposal. Change-Id: I305da891a360596fff89b10bc6de3090289b5396 Reviewed-on: https://go-review.googlesource.com/124815Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
Change-Id: Ie4e81b88cc8035fddf9c074363a1b35bcae3d470 Reviewed-on: https://go-review.googlesource.com/124778Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Daniel Martí authored
If one tries to use promoted fields in a struct literal, the compiler errors correctly. However, if the embedded fields are of struct pointer type, the field.Type.Sym.Name expression below panics. This is because field.Type.Sym is nil in that case. We can simply use field.Sym.Name in this piece of code though, as it only concerns embedded fields, in which case what we are after is the field name. Added a test mirroring fixedbugs/issue23609.go, but with pointer types. Fixes #26416. Change-Id: Ia46ce62995c9e1653f315accb99d592aff2f285e Reviewed-on: https://go-review.googlesource.com/124395 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Ian Lance Taylor authored
Change-Id: I806d411c075cdc66322112b6ee5e50f58462bc6b Reviewed-on: https://go-review.googlesource.com/124776Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
Text based on CL 124655. Change-Id: I7c4866ce829cb28a4c60cd8ced3ef99047a38c54 Reviewed-on: https://go-review.googlesource.com/124711Reviewed-by: Austin Clements <austin@google.com>
-
Jack authored
If a filepath.WalkFunc is called with an non-nil err argument, it's possible that the info argument will be nil. The comment above filepath.WalkFunc now reflects this. Fixes #26425 Change-Id: Ib9963b3344587d2993f1698c5a801f2d1286856b GitHub-Last-Rev: 553fc266b570d0c47efe12b3b670f88112e3b334 GitHub-Pull-Request: golang/go#26435 Reviewed-on: https://go-review.googlesource.com/124635Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
Change-Id: I25b93a84996ab1c17d64089b4c2ffabdff3365ec Reviewed-on: https://go-review.googlesource.com/124710Reviewed-by: Austin Clements <austin@google.com>
-
Andrew Bonventre authored
Change-Id: Id06e5139f16cd7a85c59a3dcf2020cf647fcdea0 Reviewed-on: https://go-review.googlesource.com/124709Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Andrew Bonventre authored
Change-Id: I357eea0efb04392e1a4671d20190a2052bf548de Reviewed-on: https://go-review.googlesource.com/124706Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Andrew Bonventre authored
Update text/scanner and text/template sections. Change-Id: I1a273e99ff400870053cca63cea68fb7a9b56764 Reviewed-on: https://go-review.googlesource.com/124705Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Brad Fitzpatrick authored
This doesn't auto-deploy to golang.org, only tip.golang.org. Change-Id: I112743ada2c1393e21edcc9075127f40da9e6270 Reviewed-on: https://go-review.googlesource.com/124755Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Change-Id: Id381ee73e678ff4b025c1c35512a755ba49d6f81 Reviewed-on: https://go-review.googlesource.com/124702 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Brad Fitzpatrick authored
Change-Id: Ic5b9ccb2772534cee77ffcaeee617c7d5edfb6fd Reviewed-on: https://go-review.googlesource.com/124715Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Hana (Hyang-Ah) Kim authored
Mention the change in the behavior of go test -memprofile. Change-Id: I0384f058298bd8fcfd2d97996464d46b4e419938 Reviewed-on: https://go-review.googlesource.com/124656Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Alberto Donizetti authored
Missed in CL 124516. Change-Id: I6488196c8392987d69eca832ab4969aaafe1a26c Reviewed-on: https://go-review.googlesource.com/124658Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Elias Naur authored
The change to make the runtime use libSystem.so macOS instead of direct kernel calls applies to iOS as well. Change-Id: I97ea86452ac5f7433aea58bbd3ff53a2eb2835e0 Reviewed-on: https://go-review.googlesource.com/124657Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ben Shi authored
The arm64 backend generates "TST" for "if uint32(a)&uint32(b) == 0", which should be "TSTW". fixes #26438 Change-Id: I7d64c30e3a840b43486bcd10eea2e3e75aaa4857 Reviewed-on: https://go-review.googlesource.com/124637 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Alberto Donizetti authored
Change-Id: I6f8d9cc8997128d0076a3a3e82fe5155d53db40d Reviewed-on: https://go-review.googlesource.com/124659Reviewed-by: Rob Pike <r@golang.org>
-
Ian Lance Taylor authored
In CLs 122575 and 123177 the cgo tool started explicitly looking up typedefs. When there are two Go files using import "C", and the first one has an incomplete typedef and the second one has a complete version of the same typedef, then we will now record a version of the first typedef which will not match the recorded version of the second typedef, producing an "inconsistent definitions" error. Fix this by silently merging incomplete typedefs with complete ones. Fixes #26430 Change-Id: I9e629228783b866dd29b5c3a31acd48f6e410a2d Reviewed-on: https://go-review.googlesource.com/124575 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Rob Pike authored
This should have been added to the repo after Renee's Gophercon keynote. I will link to it from the FAQ. Change-Id: I0e5b88690e288827591d27b99420d3a449f7f662 Reviewed-on: https://go-review.googlesource.com/124615Reviewed-by: Andrew Gerrand <adg@golang.org>
-