- 07 Jun, 2019 11 commits
-
-
Daniel Martí authored
The old code used ~/Library/Preferences, which is documented by Apple as: This directory contains app-specific preference files. You should not create files in this directory yourself. Instead, use the NSUserDefaults class or CFPreferences API to get and set preference values for your app. It looks like we missed everything after the first sentence; it's definitely not the right choice for files that Go programs and users should be touching directly. Instead, use ~/Library/Application Support, which is documented as: Use this directory to store all app data files except those associated with the user’s documents. For example, you might use this directory to store app-created data files, configuration files, templates, or other fixed or modifiable resources that are managed by the app. An app might use this directory to store a modifiable copy of resources contained initially in the app’s bundle. A game might use this directory to store new levels purchased by the user and downloaded from a server. This seems in line with what UserConfigDir is for, so use it. The documentation quotes above are obtained from the surprisingly long link below: https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html Fixes #32475. Change-Id: Ic27a6c92d76a5d7a4d4b8eac5cd8472f67a533a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/181177 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Keith Randall authored
The logic for detecting deferreturn calls is wrong. We used to look for a relocation whose symbol is runtime.deferreturn and has an offset of 0. But on some architectures, the relocation offset is not zero. These include arm (the offset is 0xebfffffe) and s390x (the offset is 6). This ends up setting the deferreturn offset at 0, so we end up using the entry point live map instead of the deferreturn live map in a frame which defers and then segfaults. Instead, use the IsDirectCall helper to find calls. Fixes #32477 Update #6980 Change-Id: Iecb530a7cf6eabd7233be7d0731ffa78873f3a54 Reviewed-on: https://go-review.googlesource.com/c/go/+/181258 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Brad Fitzpatrick authored
This is the net/http half of #32476. This supplies the method needed by the other half in x/net/http2 in the already-submitted CL 181259, which this CL also bundles in h2_bundle.go. Thanks to Tom Thorogood (@tmthrgd) for the bug report and test. Fixes #32476 Updates #30694 Change-Id: I79d2a280e486fbf75d116f6695fd3abb61278765 Reviewed-on: https://go-review.googlesource.com/c/go/+/181260 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
dist passes the -allabis flag to the compiler to avoid having to recreate the cross-package ABI logic from cmd/go. However, we removed that logic from cmd/go in CL 179863 and replaced it with a different mechanism that doesn't depend on the build system. Hence, passing -allabis in dist is no longer necessary. This CL removes -allabis from dist and, since that was the only use of it, removes support for it from the compiler as well. Updates #31230. Change-Id: Ib005db95755a7028f49c885785e72c3970aea4f9 Reviewed-on: https://go-review.googlesource.com/c/go/+/181079 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Matt Layher authored
The documentation comment was duplicated for each of these methods, and the LazyProc.Call documentation incorrectly mentioned that Call accepts only 15 arguments, but it actually accepts 18 now. To prevent further documentation drift, refer the reader to the documentation for Proc.Call instead of duplicating it for LazyProc.Call. In addition, note that LazyProc's Addr, Call, and Find methods each trigger a procedure lookup. Change-Id: I6756cf7601fba79d1414ff5a5d6eef900aa590e7 Reviewed-on: https://go-review.googlesource.com/c/go/+/181199 Run-TryBot: Matt Layher <mdlayher@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Constantin Konstantinidis authored
Checks if modules are enabled in GOPATH mode. Error message returned when no version is provided. Relevant tests updated. Test for GO111MODULE=off added. Fixes #27783 Change-Id: I12cdaced5fa38a9c49c0ecfed4c479eb86ed061f Reviewed-on: https://go-review.googlesource.com/c/go/+/179998 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Daniel Martí authored
In #32038, it was decided to remove get's -m, since one former use case is removed, and the other can be done via -d, as pointed by Russ. However, a user getting this short error might not realise that they can switch to -d to skip building packages. Add a short mention to point them in the right direction. It's important to note "packages", because -m was a flag that acted on modules, while -d acts on packages. Simply replacing -m with -d might not be enough in some cases because of that distinction. Change-Id: I0947b25c4223bdad3cd0e535848527da8db8a16d Reviewed-on: https://go-review.googlesource.com/c/go/+/179361Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
Fixes #32335 Change-Id: I1cf8645ecc5ba0866d9b3589a18bb500ea17f865 Reviewed-on: https://go-review.googlesource.com/c/go/+/181018 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Daniel Martí authored
In particular, the returned template isn't independent from the parent. For example, it can't be parsed concurrently with other children templates. Only methods which are explicitly safe for concurrent use, like Execute, may be used concurrently. Fixes #30281. Change-Id: Idc84bf4199c035316cdb83b950fd4a8f2a71cd0c Reviewed-on: https://go-review.googlesource.com/c/go/+/172297 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Ian Lance Taylor authored
This recognizes new features that the gofrontend has started emitting in the export data to support cross-package inlinable functions. This is a port of CL 180677 and 180758 from the gofrontend repo. Change-Id: I48af6e71f9d8b04ba874ea0c204d39d1d461f8ad Reviewed-on: https://go-review.googlesource.com/c/go/+/181118 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
-
Daniel Martí authored
To pick up the structtag vet fix for 1.13. Fixes #30846. Change-Id: I5e011a7db1ffb9435793d533097d768f209c18e0 Reviewed-on: https://go-review.googlesource.com/c/go/+/179999 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
- 06 Jun, 2019 18 commits
-
-
Austin Clements authored
CL 179862 introduced go:linkname directives to create ABI wrappers for Store and Store64 on s390x, but a concurrent change (CL 180439) replaced the Go definitions of these functions with assembly definitions. This resulted in conflicting definitions for the ABI0 symbols, which led to a bootstrap linking failure. Fix this by removing the now-incorrect go:linkname directives for Store and Store64. This should fix the linux-s390x builders. Updates #31230. Change-Id: I8de8c03c23412fc217d428c0018cc56eb2f9996f Reviewed-on: https://go-review.googlesource.com/c/go/+/181078Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Austin Clements authored
Somehow I missed these two functions in CL 179863. This should fix the linux-arm builders. Updates #31230. Change-Id: I3f8bef3fac331b505a55c0850b0fbc799b7c06c5 Reviewed-on: https://go-review.googlesource.com/c/go/+/181077 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
The built-in Go resolver works significantly better. In particular, the use of res_search does not support CNAME or PTR queries and may not even be thread-safe. This CL is essentially a revert of CL 166297 plus fixes, including CL 180842. See CL 180842 for additional notes about problems with this approach. Fixes #31705. Change-Id: I0a30a0de2fbd04f6c461520fd34378c84aadf66c Reviewed-on: https://go-review.googlesource.com/c/go/+/180843 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Russ Cox authored
This code was added in April in CL 166297, for #12524. This CL fixes the following problems in the code: - The test for failure in the assembly stubs checked for 64-bit -1 instead of 32-bit -1 to decide to fetch errno. - These C routines (res_init and res_search) don't set errno anyway, so the Go code using errno to decide success is incorrect. (The routines set h_errno, which is a racy global variable that can't safely be consulted, storing values in a different error space.) - The Go call passed res_search a non-NUL-terminated name. - The C res_search rejects calls asking for TypeALL as opposed to more specific answers like TypeA/TypeAAAA/TypeCNAME, breaking cgoLookupHost in all cases and cgoLookupIP except with IP-version-specific networks. - The DNS response packet was parsed twice, once with msg.Unpack (discarded), and once with the lower-level dnsmessage.Parser. The Parser loop was missing a call to p.SkipAllQuestions, with the result that no DNS response packet would ever parse successfully. - The parsing of the DNS response answers, if reached, behaved as if that the AResource and AAAAResource record contained textual IP addresses, while in fact they contain binary ones. The calls to parseIPv4 and parseIPv6 therefore would always returns nil, so that no useful result would be returned from the resolver. With these fixes, cgoLookupIP can correctly resolve google.com and return both the A and AAAA addresses. Even after fixing all these things, TestGoLookupIP still fails, because it is testing that in non-cgo builds the cgo stubs correctly report "I can't handle the lookup", and as written the code intentionally violates that expectation. This CL adds new direct tests of the pseudo-cgo routines. The direct IP address lookups succeed, but the CNAME query causes res_search to hang, and the PTR query fails unconditionally (a trivial C program confirms these behaviors are due to res_search itself). Traditionally, res_search is only intended for single-threaded use. It is unclear whether this one is safe for use from multiple goroutines. If you run net.test under lldb, that causes syslog messages to be printed to standard error suggesting double-free bugs: 2019-06-05 19:52:43.505246-0400 net.test[6256:6831076] dnssd_clientstub DNSServiceRefDeallocate called with invalid DNSServiceRef 0x5c000f0 FFFFFFFF DDDDDDDD 2019-06-05 19:52:43.505274-0400 net.test[6256:6831076] dnssd_clientstub DNSServiceRefDeallocate called with invalid DNSServiceRef 0x5c000f0 FFFFFFFF DDDDDDDD 2019-06-05 19:52:43.505303-0400 net.test[6256:6831076] dnssd_clientstub DNSServiceRefDeallocate called with invalid DNSServiceRef 0x5c000f0 FFFFFFFF DDDDDDDD 2019-06-05 19:52:43.505329-0400 net.test[6256:6831076] dnssd_clientstub DNSServiceRefDeallocate called with invalid DNSServiceRef 0x5c000f0 FFFFFFFF DDDDDDDD This res_search is from libsystem_info; a normal C program would get res_search (#defined to res_9_search) from libresolv instead. It is unclear what the relation between the two is. Issue #12524 was about supporting the /etc/resolver directory tree, but only libresolv contains code for that; libsystem_info does not. So this code probably does not enable use of /etc/resolver. In short: - Before this CL, the code clearly had never run successfully. - The code appears not to improve upon the usual non-cgo fallback. - The code carries with it no tests of improved behavior. - The code breaks existing tests. - Calling res_search does not work for PTR/CNAME queries, so the code breaks existing behavior, even after this CL. - It's unclear whether res_search is safe to call from multiple threads. - It's unclear whether res_search is used by any other macOS programs. Given this, it probably makes sense to delete this code rather than rejigger the test. This CL fixes the code first, so that there is a working copy to bring back later if we find out that it really is necessary. For #31705. Change-Id: Id2e11e8ade43098b0f90dd4d16a62ca86a7a244a Reviewed-on: https://go-review.googlesource.com/c/go/+/180842 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Russ Cox authored
It matters whether we are calling a function that would return a 32-bit or 64-bit -1 on error. A few sites were wrong and this key detail was omitted from syscall/syscallX docs. Change-Id: I48a421b6cc4d2d2b5e58f790cc947e3cb2f98940 Reviewed-on: https://go-review.googlesource.com/c/go/+/180841 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Austin Clements authored
This removes the special case for finding assembly references to Go symbols in runtime and runtime/internal/atomic. These are no longer necessary because we've now marked all symbols in these packages that must be accessible from assembly in other packages. Fixes #31230. Change-Id: I70c90b70e13b922a6669f3d46c53347f98d6fc3f Reviewed-on: https://go-review.googlesource.com/c/go/+/179863 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Austin Clements authored
This marks all Go symbols called from assembly in other packages with "go:linkname" directives to ensure they get ABI wrappers. Now that we have this go:linkname convention, this also removes the abi0Syms definition in the runtime, which was used to give morestackc an ABI0 wrapper. Instead, we now just mark morestackc with a go:linkname directive. This was tested with buildall.bash in the default configuration, with -race, and with -gcflags=all=-d=ssa/intrinsics/off. Since I couldn't test cgo on non-Linux configurations, I manually grepped for runtime symbols in runtime/cgo. Updates #31230. Change-Id: I6c8aa56be2ca6802dfa2bf159e49c411b9071bf1 Reviewed-on: https://go-review.googlesource.com/c/go/+/179862 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
-
Austin Clements authored
The //go:linkname directive can be used to make a symbol accessible to another package (when it wouldn't normally be). Sometimes you want to do this without actually changing the symbol's object file symbol name; for example, in gccgo this makes unexported symbols non-static, and in gc this provides ABI0 wrappers for Go symbols so they can be called from assembly in other packages. Currently, this results in stutter like //go:linkname entersyscall runtime.entersyscall This CL makes the second argument to go:linkname optional for the case where the intent is simply to expose the symbol rather than to rename it in the object file. Updates #31230. Change-Id: Id06d9c4b2ec3d8e27f9b8a0d65212ab8048d734f Reviewed-on: https://go-review.googlesource.com/c/go/+/179861 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Austin Clements authored
Calling a Go symbol from assembly in another package currently results in a link failure because the Go symbol is defined as ABIInternal, but the assembly call is from ABI0. In general this is okay because you shouldn't do this anyway, but there are special cases where this is necessary, especially between the runtime and packages closely tied to the runtime in std. Currently, we address this for runtime symbols with a hack in cmd/go that knows to scan related packages when building the symabis file for the runtime and runtime/internal/atomic. However, in addition to being a messy solution in the first place, this hack causes races in cmd/go that are difficult to work around. We considered creating dummy references from assembly in the runtime to these symbols, just to make sure they get ABI0 wrappers. However, there are a fairly large number of these symbols on some platforms, and it can vary significantly depending on build flags (e.g., race mode), so even this solution is fairly unpalatable. This CL addresses this by providing a way to mark symbols in Go code that should be made available to assembly in other packages. Rather than introduce a new pragma, we lightly expand the meaning of "//go:linkname", since that pragma already generally indicates that you're making the symbol available in a way it wasn't before. This also dovetails nicely with the behavior of go:linkname in gccgo, which makes unexported symbols available to other packages. Follow-up CLs will make use of this and then remove the hack from cmd/go. Updates #31230. Change-Id: I23060c97280626581f025c5c01fb8d24bb4c5159 Reviewed-on: https://go-review.googlesource.com/c/go/+/179860 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Michael Munday authored
The z/Architecture does not guarantee that a load following a store will not be reordered with that store, unless they access the same address. Therefore if we want to ensure the sequential consistency of atomic loads and stores we need to perform serialization operations after atomic stores. We do not need to serialize in the runtime when using StoreRel[ease] and LoadAcq[uire]. The z/Architecture already provides sufficient ordering guarantees for these operations. name old time/op new time/op delta AtomicLoad64-16 0.51ns ± 0% 0.51ns ± 0% ~ (all equal) AtomicStore64-16 0.51ns ± 0% 0.60ns ± 9% +16.47% (p=0.000 n=17+20) AtomicLoad-16 0.51ns ± 0% 0.51ns ± 0% ~ (all equal) AtomicStore-16 0.51ns ± 0% 0.60ns ± 9% +16.50% (p=0.000 n=18+20) Fixes #32428. Change-Id: I88d19a4010c46070e4fff4b41587efe4c628d4d9 Reviewed-on: https://go-review.googlesource.com/c/go/+/180439 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
David Chase authored
Tool refactoring smallStacks into smallFrames helpfully "corrected" the capitalization in a string, this undoes the help. This is necessary to ensure correct (re)building when the flag is used to research stack-marking GC latency bugs. Updates #27732. Change-Id: Ib7c8d4a36c9e4f9612559be68bd481f9d9cc69f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/180958 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Meng Zhuo authored
This is a follow up CL of CL 180877: It will skip test create user namespaces under 3 conditions: 1. sysctl file is missing 2. file reads nothing 3. user don't have permission to create namespaces Change-Id: I25f00a6b67213bf98d654972388637789978e1fe Reviewed-on: https://go-review.googlesource.com/c/go/+/180937 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
-
David Chase authored
Shrinks the size of things that can be stack allocated from 10M to 128k for declared variables and from 64k to 16k for implicit allocations (new(T), &T{}, etc). Usage: "go build -gcflags -smallframes hello.go" An earlier GOEXPERIMENT version of this caused only one problem, when a gc-should-detect-oversize-stack test no longer had an oversized stack to detect. The change was converted to a flag to make it easier to access (for diagnosing "long" GC-related single-thread pauses) and to remove interference with the test. Includes test to verify behavior. Updates #27732. Change-Id: I1255d484331e77185e07c78389a8b594041204c2 Reviewed-on: https://go-review.googlesource.com/c/go/+/180817 Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Meng Zhuo authored
The original test (CL 166460) didn't check the existence of /proc/sys/kernel/unprivileged_userns_clone and continue the test if the file doesn't exist. Fixes #32459 Change-Id: Iab4938252fcaded32b61e17edf68f966c2565582 Reviewed-on: https://go-review.googlesource.com/c/go/+/180877 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
-
Russ Cox authored
Change-Id: Ie00494f098bd2bce9bfd1b18dbf9543cf46faad6 Reviewed-on: https://go-review.googlesource.com/c/go/+/180840 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Change-Id: I6940a4c747f2da871263afa6a4e3386395d5cf54 Reviewed-on: https://go-review.googlesource.com/c/go/+/180839 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
If the test fails, conf.teardown wouldn't be. It doesn't look like it matters much, but clean up anyway. Change-Id: I45c18095abfd49422975d061be20cbd971a98f8f Reviewed-on: https://go-review.googlesource.com/c/go/+/180780 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
At least one libc call we make (res_search, which calls _mdns_query and then mdns_item_call) pushes a 64 kB stack frame onto the stack. Then it faults on the guard page. Use the default system stack size, under the assumption that the C code being called is compatible with that stack size. For #31705. Change-Id: I1b0bfc2e54043c49f0709255988ef920ce30ee82 Reviewed-on: https://go-review.googlesource.com/c/go/+/180779 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 05 Jun, 2019 10 commits
-
-
ng0 authored
Fixes #32167 Change-Id: If1277789ac96363430045e73e49d008bdae9be79 GitHub-Last-Rev: 71c9435c8417b19faaf66dc2e08740d7a9c22e3b GitHub-Pull-Request: golang/go#32171 Reviewed-on: https://go-review.googlesource.com/c/go/+/178397 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Alex Myasoedov authored
Fixes #32427 Change-Id: I4b863bd3836067dcc2eb3a9c3a7169656763d003 Reviewed-on: https://go-review.googlesource.com/c/go/+/180438Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Keith Randall authored
This reverts commit fff4f599. Reason for revert: Seems to still have issues around GC. Fixes #32452 Change-Id: Ibe7af629f9ad6a3d5312acd7b066123f484da7f0 Reviewed-on: https://go-review.googlesource.com/c/go/+/180761 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Austin Clements authored
Change-Id: Ibe514058770bd5342e1f344c5b8a9ab1427d5dfe Reviewed-on: https://go-review.googlesource.com/c/go/+/180297 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
It was rolled back. Change-Id: I8372bb7e11bab7be242f4af7093a73d2fa093067 Reviewed-on: https://go-review.googlesource.com/c/go/+/180760Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Andrew Bonventre authored
The additions were generated using golang.org/x/build/cmd/relnote. Change-Id: Ie7322f7d01a2dd4a7bca89b9ef9c1ce93bc2671a Reviewed-on: https://go-review.googlesource.com/c/go/+/180778Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Bryan C. Mills authored
Windows does not have atomic renames; instead, it produces one of a handful of errors in case a read races with a rename. CL 180219 added a utility function that retries those errors in most cases; this change updates the locations that use renameio for writes to also use the new renameio.ReadFile function for reads. It remains possible for a renameio.ReadFile to fail with a spurious ERROR_FILE_NOT_FOUND, but with retries in place for the other errors (and practical limits on write concurrency) such failures are unlikely in practice. Fixes #32188 Change-Id: I78c81051cc871325c1e3229e696b921b0fcd865a Reviewed-on: https://go-review.googlesource.com/c/go/+/180517 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Bryan C. Mills authored
ReadFile is a drop-in replacement for ioutil.ReadFile that works around Windows filesystem flakiness under load. A followup CL will replace uses of ioutil.ReadFile in cmd/go with this function. Updates #32188 Change-Id: I232ba893b132bdc84cd7b0edde436165a69e1aa8 Reviewed-on: https://go-review.googlesource.com/c/go/+/180219 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Ian Lance Taylor authored
Updates #31093 Change-Id: I7962aaca0b012de01768b7b42dc2283d5845eeea Reviewed-on: https://go-review.googlesource.com/c/go/+/180377 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
Ian Lance Taylor authored
Roll back CL 159258 and CL 168337. Those changes broke existing code. I can't see any way to keep existing code working while also producing good error messages for types like C.ulong (such as the ones already tested for in misc/cgo/errors). This is not an exact roll back because parts of the code have changed since those CLs. Updates #29878 Fixes #31093 Change-Id: I56fe76c167ff0ab381ed273b9ca4b952402e1434 Reviewed-on: https://go-review.googlesource.com/c/go/+/180357 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
- 04 Jun, 2019 1 commit
-
-
Dmitri Shuralyov authored
Roll back CL 161738. That fix changed StripPrefix behavior in the general case, not just in the situation where where stripping the prefix from path resulted in the empty string, causing issue #31622. That kind of change to StripPrefix behavior is not backwards compatible, and there can be a smaller, more targeted fix for the original issue. Fixes #31622 Updates #30165 Change-Id: Ie2fcfe6787a32e44f71d564d8f9c9d580fc6f704 Reviewed-on: https://go-review.googlesource.com/c/go/+/180498 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-