- 06 Dec, 2018 8 commits
-
-
Tobias Klauser authored
After CL 128056 the build fails on darwin/386 with src/crypto/x509/root_cgo_darwin.go:218:55: warning: values of type 'SInt32' should not be used as format arguments; add an explicit cast to 'int' instead [-Wformat] go build crypto/x509: C compiler warning promoted to error on Go builders Fix the warning by explicitly casting the argument to an int as suggested by the warning. Change-Id: Icb6bd622a543e9bc5f669fd3d7abd418b4a8e579 Reviewed-on: https://go-review.googlesource.com/c/152958 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Bryan C. Mills authored
If the replacements specify one or more versions, we choose the latest (for consistency with the QueryPackage path, with resolves the latest version from upstream). Otherwise, we synthesize a pseudo-version with a zero timestamp and an appropriate major version. Fixes #26241 RELNOTE=yes Change-Id: I14b4c63858c8714cc3e1b05ac52c33de5a16dea9 Reviewed-on: https://go-review.googlesource.com/c/152739Reviewed-by:
Russ Cox <rsc@golang.org> Reviewed-by:
Jay Conrod <jayconrod@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
In order to further diagnose #27993, I need to see exactly what pointers are being added to the gcWork buffer too late. Change-Id: I8d92113426ffbc6e55d819c39e7ab5eafa68668d Reviewed-on: https://go-review.googlesource.com/c/152957 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
Michael Knyszek <mknyszek@google.com>
-
Bryan C. Mills authored
Unlike "/v1", "/v" is not likely to be mistaken for a semantic import path. Change-Id: I024647d78c79c7761b98ddeccdc7e259ca94b568 Reviewed-on: https://go-review.googlesource.com/c/152738 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Julie Qiu authored
Change-Id: Ic435090bda64d1061f2c3aac0aa94ed7a4800b0b Reviewed-on: https://go-review.googlesource.com/c/152743Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Lynn Boger authored
This makes a change to disasm.go so it provides consistent output with the recent updates to arch/ppc64. Change-Id: I812e5da2423fd1a84406032fd91ddf9cc86b7c69 Reviewed-on: https://go-review.googlesource.com/c/152761Reviewed-by:
Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
Change-Id: I1a0bedc9fbd42e138eb68af8365115339e377856 Reviewed-on: https://go-review.googlesource.com/c/152742Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Robert Griesemer authored
- follow wording of cmd/compile more closely - only print base of a package path to avoid overly long error messages Fixes #26234. Change-Id: I47a8c64b3adcf73980cd296a24cf8ac721e5df06 Reviewed-on: https://go-review.googlesource.com/c/152764 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
Alan Donovan <adonovan@google.com>
-
- 05 Dec, 2018 20 commits
-
-
Robert Griesemer authored
The source.offs field was intended for computing line offsets which may allow a tiny optimization (see TODO in source.go). We haven't done the optimization, so for now just remove the field to avoid confusion. It's trivially added if needed. While at it, also: - Fix comment for ungetr2. - Make sure sentinel is present even if reading from the io.Reader failed. Change-Id: Ib056c6478030b3fe5fec29045362c8161ff3d19e Reviewed-on: https://go-review.googlesource.com/c/152763 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Andrew Bonventre authored
Change-Id: Ie11cf7d8204860f5a61ab650589d44072d6b131c Reviewed-on: https://go-review.googlesource.com/c/152740Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Filippo Valsorda authored
Now that the cgo and no-cgo paths should be correct and equivalent, re-enable the TestSystemRoots test without any margin of error (which was tripping anyway when users had too many of a certain edge-case). As a last quirk, the verify-cert invocation will validate certificates that aren't roots, but are signed by valid roots. Ignore them. Fixes #24652 Change-Id: I6a8ff3c2282136d7122a4e7e387eb8014da0d28a Reviewed-on: https://go-review.googlesource.com/c/128117 TryBot-Result: Gobot Gobot <gobot@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by:
Adam Langley <agl@golang.org>
-
Filippo Valsorda authored
Certificates without any trust settings might still be in the keychain (for example if they used to have some, or if they are intermediates for offline verification), but they are not to be trusted. The only ones we can trust unconditionally are the ones in the system roots store. Moreover, the verify-cert invocation was not specifying the ssl policy, defaulting instead to the basic one. We have no way of communicating different usages in a CertPool, so stick to the WebPKI use-case as the primary one for crypto/x509. Updates #24652 Change-Id: Ife8b3d2f4026daa1223aa81fac44aeeb4f96528a Reviewed-on: https://go-review.googlesource.com/c/128116Reviewed-by:
Adam Langley <agl@google.com> Reviewed-by:
Adam Langley <agl@golang.org>
-
Filippo Valsorda authored
The cgo path was not taking policies into account, using the last security setting in the array whatever it was. Also, it was not aware of the defaults for empty security settings, and for security settings without a result type. Finally, certificates restricted to a hostname were considered roots. The API docs for this code are partial and not very clear, so this is a best effort, really. Updates #24652 Change-Id: I8fa2fe4706f44f3d963b32e0615d149e997b537d Reviewed-on: https://go-review.googlesource.com/c/128056 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Adam Langley <agl@google.com> Reviewed-by:
Adam Langley <agl@golang.org>
-
Katie Hockman authored
Change-Id: I5f0ceeca2025cf19bcf610e150f7b7067fdd7397 Reviewed-on: https://go-review.googlesource.com/c/152637Reviewed-by:
Andrew Bonventre <andybons@golang.org>
-
komuW authored
Fixes golang/go#27047 Change-Id: I0dd40201fc03e87fbc674b47bdf9315f1783d6c2 GitHub-Last-Rev: f28ab6234ade814c4bc09e26417c424c843ad57b GitHub-Pull-Request: golang/go#27048 Reviewed-on: https://go-review.googlesource.com/c/129696Reviewed-by:
komu wairagu <komuw05@gmail.com> Reviewed-by:
Andrew Bonventre <andybons@golang.org>
-
Austin Clements authored
Currently, for i := range a { a[i] = nil } will compile to have write barriers even if a is a slice of pointers to go:notinheap types. This happens because the optimization that transforms this into a memclr only asks it a's element type has pointers, and not if it specifically has heap pointers. Fix this by changing arrayClear to use HasHeapPointer instead of types.Haspointers. We probably shouldn't have both of these functions, since a pointer to a notinheap type is effectively a uintptr, but that's not going to change in this CL. Change-Id: I284b85bdec6ae1e641f894e8f577989facdb0cf1 Reviewed-on: https://go-review.googlesource.com/c/152723 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Austin Clements authored
There are two places where the compiler generates memclrHasPointers calls. These are effectively write barriers, but the compiler doesn't currently record them as such in the function. As a result code like for i := range a { a[i] = nil } inserts a write barrier for the assignment to a[i], but the compiler doesn't report this. Hence, it's not reported in the -d=wb output, and it's not checked against //go:nowritebarrier annotations. Change-Id: I40299ebc9824f05cf516cba494d4c086b80ffb53 Reviewed-on: https://go-review.googlesource.com/c/152722 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Lynn Boger authored
This updates master to fix the ppc64 objdump. There were many cases where the Go objdump was generating opcodes that didn't exist in the Go assembler, or generated operands in the wrong order. The goal is to generate a Go objdump that is acceptable to the Go assembler, or as close as possible. An additional change will be needed for the Go objdump tool to make use of this. Change-Id: Ie8d2d534e13b9a64852c99b4b864a9c08ed7e036 Reviewed-on: https://go-review.googlesource.com/c/152517Reviewed-by:
Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by:
Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Follow-up on #28450 (golang.org/cl/152417). Updates #28450. Fixes #29107. Change-Id: Ib4b4fe582c35315a4f71cf6dbc7f7f2f24b37ec1 Reviewed-on: https://go-review.googlesource.com/c/152758Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
David du Colombier authored
This test is regularly failing on the plan9/386 builder running on GCE, but we haven't figured out the issue yet. Updates #26945. Change-Id: I8cbe0df43c0757e7bc68e370311f4a28cd7b049b Reviewed-on: https://go-review.googlesource.com/c/152721 Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Baokun Lee authored
Fixes golang/go#28820. Change-Id: Id931617efcf161ec934eb6d44062ad95e8a6ab8d Reviewed-on: https://go-review.googlesource.com/c/150277 Run-TryBot: Baokun Lee <nototon@gmail.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Bryan C. Mills <bcmills@google.com>
-
Ian Lance Taylor authored
Fixes #29110 Change-Id: I077d1a9caa7f4545de1418cec718c4a37ac36ef8 Reviewed-on: https://go-review.googlesource.com/c/152757 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Andrew Bonventre authored
Change-Id: I845eab3c98a3d472c71310de4e0475045eb59d4e Reviewed-on: https://go-review.googlesource.com/c/152619Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Clément Chigot authored
filelock.Unlock() was called twice for fcntl implementation if an error occurs during file.{,R}Lock(): once in the error handler, once in filelock.lock(). Change-Id: I5ad84e8ef6b5e51d79e0a7a0c51f465276cd0c57 Reviewed-on: https://go-review.googlesource.com/c/152717 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Bryan C. Mills <bcmills@google.com>
-
Hiroshi Ioka authored
Fixes #28721 Change-Id: I00356f3a9b0c2fb21dc9c2237dd5296fcb3b319b Reviewed-on: https://go-review.googlesource.com/c/152657 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
bill_ofarrell authored
In the s390x assembly implementation of NIST P-256 curve, utilize faster multiply/square instructions introduced in the z14. These new instructions are designed for crypto and are constant time. The algorithm is unchanged except for faster multiplication when run on a z14 or later. On z13, the original mutiplication (also constant time) is used. P-256 performance is critical in many applications, such as Blockchain. name old time new time delta BaseMultP256 24396 ns/op 21564 ns/op 1.13x ScalarMultP256 87546 ns/op 72813 ns/op. 1.20x Change-Id: I7e6d8b420fac56d5f9cc13c9423e2080df854bac Reviewed-on: https://go-review.googlesource.com/c/146022Reviewed-by:
Michael Munday <mike.munday@ibm.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Michael Munday <mike.munday@ibm.com>
-
Alex Brainman authored
The expression passed into isAbortPC call was written specifically for windows/amd64 and windows/386 runtime.abort implementation. Adjust the code, so it also works for windows/arm. Fixes #29050 Change-Id: I3dc8ddd08031f34115396429eff512827264826f Reviewed-on: https://go-review.googlesource.com/c/152357Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
smasher164 authored
Previously, when a function signature had defined a non-final variadic parameter, the error message always referred to the type associated with that parameter. However, if the offending parameter's name was part of an identifier list with a variadic type, one could misinterpret the message, thinking the problem had been with one of the other names in the identifer list. func bar(a, b ...int) {} clear ~~~~~~~^ ^~~~~~~~ confusing This change updates the error message and sets the column position to that of the offending parameter's name, if it exists. Fixes #28450. Change-Id: I076f560925598ed90e218c25d70f9449ffd9b3ea Reviewed-on: https://go-review.googlesource.com/c/152417 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
- 04 Dec, 2018 12 commits
-
-
Cherry Zhang authored
For recursive functions, the parameters were iterated using fn.Name.Defn.Func.Dcl, which does not include unnamed/blank parameters. This results in a mismatch in formal-actual assignments, for example, func f(_ T, x T) f(a, b) should result in { _=a, x=b }, but the escape analysis currently sees only { x=a } and drops b on the floor. This may cause b to not escape when it should (or a escape when it should not). Fix this by using fntype.Params().FieldSlice() instead, which does include unnamed parameters. Also add a sanity check that ensures all the actual parameters are consumed. Fixes #29000 Change-Id: Icd86f2b5d71e7ebbab76e375b7702f62efcf59ae Reviewed-on: https://go-review.googlesource.com/c/152617Reviewed-by:
Keith Randall <khr@golang.org>
-
Daniel Martí authored
This partially reverts https://golang.org/cl/135035. Reason for revert: multiple -ldflags=-foo flags simply override each other, since that's the logic for per-package flags. The suggested 'GOFLAGS=-ldflags=-s -ldflags=-w' has never worked for 'go build', and even breaks 'go test' and 'go vet'. There should be a way to specify -ldflags='-w -s' via GOFLAGS, which is being tracked in #29096. For now, just remove the incorrect suggestion. Fixes #29053. Change-Id: I9203056f7e5191e894bcd16595a92df2fb704ea7 Reviewed-on: https://go-review.googlesource.com/c/152479Reviewed-by:
Bryan C. Mills <bcmills@google.com> Reviewed-by:
Alan Donovan <adonovan@google.com> Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
-
Brad Fitzpatrick authored
Change-Id: I081400286544d88eec83a8b332b9f7934fd76ae2 Reviewed-on: https://go-review.googlesource.com/c/152539Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Andrew Bonventre authored
Change-Id: Iac0e6671902404a149dd382af37a2be002b1e50f Reviewed-on: https://go-review.googlesource.com/c/152518Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
This will produce better error messages (position information) for errors referring to imported objects. Change-Id: I24646ae803e6b8f78e9240310a858d4095e9463d Reviewed-on: https://go-review.googlesource.com/c/152538Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Alan Donovan authored
The importer.For function logically requires a FileSet, but did not when it was first created because export data did not then record position information. This change adds a new function, ForCompiler, that has an additional FileSet parameter, and deprecates the For function. Before this change, cmd/vet would report confusing spurious positions for token.Pos values produced by the importer. The bug is essentially unfixable in cmd/vet. This CL includes a test that the FileSet is correctly populated. The changes to cmd/vendor will be applied upstream in a follow-up. Fixes #28995 Change-Id: I9271bcb1f28e96845c913e15f0304bac93d4d4c4 Reviewed-on: https://go-review.googlesource.com/c/152258 Run-TryBot: Alan Donovan <adonovan@google.com> Reviewed-by:
Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Agniva De Sarker authored
Ignore predeclared types (such as error) in result parameter lists when determining with which result type a method should be associated with. This change will again associate common factory functions with the first result type even if there are more than one result, as long as the others are predeclared types. Fixes #27928 Change-Id: Ia2aeaed15fc4c8debdeeaf729cc7fbba1612cafb Reviewed-on: https://go-review.googlesource.com/c/141617 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Ian Lance Taylor authored
Support for methods marked with "//go:nointerface" was broken by CL 151557, based on CL 150061, which changed the scanner to stop skipping comments. Change-Id: I43d5e2cf51bed2dc4ed9d6136ca21aa1223e8df1 Reviewed-on: https://go-review.googlesource.com/c/152378 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Than McIntosh <thanm@google.com>
-
Clément Chigot authored
AIX doesn't provide flock() syscall, it was previously emulated by fcntl calls. However, there are some differences between a flock() syscall and a flock() using fcntl. Therefore, it's safer to remove it and just provide FcntlFlock. Thus, lockedfile implementation must be moved to use FcntlFlock on aix/ppc64. Updates #29065. Fixes #29084. Change-Id: Ic48fd9f315f24c2acdf09b91d917da131a1f2dd5 Reviewed-on: https://go-review.googlesource.com/c/152397Reviewed-by:
Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by:
Bryan C. Mills <bcmills@google.com>
-
Lynn Boger authored
Some recent failures in gccgo on linux/ppc64 identified an error in buildmodeInit when buildmode=c-archive. A fix went into gofrontend, and this is the corresponding change for master. This change also includes two other updates related to gccgo in this function that were in the file from gofrontend but missing from master. Updates #29046 Change-Id: I9a894e7d728e31fb9e9344cd61d50408df7faf4a Reviewed-on: https://go-review.googlesource.com/c/152160 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Bobby DeSimone authored
These changes add tests for the unexported function singleJoiningSlash. Change-Id: I107905aac4a3c2544be309098b67e970ea5b542c GitHub-Last-Rev: ed6f86f619549f46ef53316b7febaac781b64e4b GitHub-Pull-Request: golang/go#29088 Reviewed-on: https://go-review.googlesource.com/c/152337Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
Updates #28869 Change-Id: Ie152bf959af2e9cd32b1ccc031e8208e64fbe3ce Reviewed-on: https://go-review.googlesource.com/c/152161Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Alan Donovan <adonovan@google.com>
-