- 02 Apr, 2019 2 commits
-
-
Cherry Zhang authored
It is possible that a "volatile" value (one that can be clobbered by preparing args of a call) to be used in multiple write barrier calls. We used to copy the volatile value right before each call. But this doesn't work if the value is used the second time, after the first call where it is already clobbered. Copy it before emitting any call. Updates #30977. Fixes #30996. Change-Id: Iedcc91ad848d5ded547bf37a8359c125d32e994c Reviewed-on: https://go-review.googlesource.com/c/go/+/168677 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> (cherry picked from commit f23c601b) Reviewed-on: https://go-review.googlesource.com/c/go/+/168817 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Jordan Liggitt authored
A regression was introduced in CL 137335 (5440bfc2) that caused FlushInterval to not be honored until the first Write() call was encountered. This change starts the flush timer as part of setting up the maxLatencyWriter. Fixes #31144 Change-Id: I75325bd926652922219bd1457b2b00ac6d0d41b0 Reviewed-on: https://go-review.googlesource.com/c/go/+/170066Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> (cherry picked from commit 2cc34738) Reviewed-on: https://go-review.googlesource.com/c/go/+/170137
-
- 27 Mar, 2019 3 commits
-
-
Dmitri Shuralyov authored
This change is a re-apply of the reverted CL 140863 with changes to address issue #30821. Specifically, path.Split continues to be used to split the '/'-separated import path, rather than filepath.Split. Document the algorithm for how the default executable name is determined in DefaultExecName. Rename a variable returned from os.Stat from bs to fi for consistency. CL 140863 factored out the logic to determine the default executable name from the Package.load method into a DefaultExecName function, and started using it in more places to avoid having to re-implement the logic everywhere it's needed. Most previous callers already computed the default executable name based on the import path. The load.Package method, before CL 140863, was the exception, in that it used the p.Dir value in GOPATH mode instead. There was a NOTE(rsc) comment that it should be equivalent to use import path, but it was too late in Go 1.11 cycle to risk implementing that change. This is part 1, a more conservative change for backporting to Go 1.12.2, and it keeps the original behavior of splitting on p.Dir in GOPATH mode. Part 2 will address the NOTE(rsc) comment and modify behavior in Package.load to always use DefaultExecName which splits the import path rather than directory. It is intended to be included in Go 1.13. Updates #27283 Updates #26869 Updates #30821 Fixes #30266 Change-Id: Ib1ebb95acba7c85c24e3a55c40cdf48405af34f3 Reviewed-on: https://go-review.googlesource.com/c/go/+/167503Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com> (cherry picked from commit 94563de8) Reviewed-on: https://go-review.googlesource.com/c/go/+/168958 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Google's 8.8.8.8 DNS server used to reports its reverse DNS name as ending in ".google.com". Now it's "dns.google.". Change-Id: I7dd15f03239e5c3f202e471618ab867690cb4f9d Reviewed-on: https://go-review.googlesource.com/c/go/+/169679 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> (cherry picked from commit 3089d189) Reviewed-on: https://go-review.googlesource.com/c/go/+/169717
-
Than McIntosh authored
When generating DWARF inline info records, the post-SSA code looks through the original "pre-inline" dcl list for the function so as to handle situations where formal params are promoted or optimized away. This code was not properly handling the case where an output parameter was promoted to the heap -- in this case the param node is converted in place from class PPARAMOUT to class PAUTOHEAP. This caused inconsistencies later on, since the variable entry in the abstract subprogram DIE wound up as a local and not an output parameter. Updates #30908. Fixes #31028. Change-Id: Ia70b89f0cf7f9b16246d95df17ad6e307228b8c7 Reviewed-on: https://go-review.googlesource.com/c/go/+/168818Reviewed-by: Cherry Zhang <cherryyz@google.com> (cherry picked from commit 68a98d52) Reviewed-on: https://go-review.googlesource.com/c/go/+/169417 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 24 Mar, 2019 1 commit
-
-
Jason A. Donenfeld authored
While many other call sites have been moved to using the proper higher-level system loading, these areas were left out. This prevents DLL directory injection attacks. This includes both the runtime load calls (using LoadLibrary prior) and the implicitly linked ones via cgo_import_dynamic, which we move to our LoadLibraryEx. The goal is to only loosely load kernel32.dll and strictly load all others. Meanwhile we make sure that we never fallback to insecure loading on older or unpatched systems. This is CVE-2019-9634. Fixes #30666 Updates #14959 Updates #28978 Updates #30642 Change-Id: I401a13ed8db248ab1bb5039bf2d31915cac72b93 Reviewed-on: https://go-review.googlesource.com/c/go/+/165798 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> (cherry picked from commit 9b6e9f0c) Reviewed-on: https://go-review.googlesource.com/c/go/+/168339Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
- 15 Mar, 2019 1 commit
-
-
Baokun Lee authored
Fixes #30859 Updates #30491 Change-Id: If4070e5d39d8649643d7e90f6f3eb499642e25ab Reviewed-on: https://go-review.googlesource.com/c/go/+/164720 Run-TryBot: Baokun Lee <nototon@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> (cherry picked from commit d039e12b) Reviewed-on: https://go-review.googlesource.com/c/go/+/167739 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Baokun Lee <nototon@gmail.com>
-
- 14 Mar, 2019 5 commits
-
-
Andrew Bonventre authored
Change-Id: I0d4a55af0bee754ab1ee817780027e9f72475afb Reviewed-on: https://go-review.googlesource.com/c/go/+/167712Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Andrew Bonventre authored
Change-Id: Id5f76204b8cd3fe67c21c5adfd3a4e456a8cad14 Reviewed-on: https://go-review.googlesource.com/c/go/+/167704 Run-TryBot: Andrew Bonventre <andybons@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
Andrew Bonventre authored
Change-Id: I6d3a615c5f72e9aa29d23e127af98d6e836da173 Reviewed-on: https://go-review.googlesource.com/c/go/+/167699Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit f832a97e) Reviewed-on: https://go-review.googlesource.com/c/go/+/167702Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Andrew Bonventre authored
Change-Id: I99832fa4f2c3ec28e2dad46cf7607f3766948031 Reviewed-on: https://go-review.googlesource.com/c/go/+/167698Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit d3bb45d9) Reviewed-on: https://go-review.googlesource.com/c/go/+/167701
-
Bryan C. Mills authored
This reverts commit 746edd45 (CL 167384). Reason for revert: Dmitri identified a potential problem in https://go-review.googlesource.com/c/go/+/140863/11#message-db0ff6bb2c7b06161ca47de771c4465afa8b1102, and we'd like more time to investigate without holding up the 1.12 release branch. Updates #27283 Updates #30266 Updates #30821 Change-Id: I49d7bbbe200e80b81899c3bcbf7844717af010aa Reviewed-on: https://go-review.googlesource.com/c/go/+/167617Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
- 13 Mar, 2019 9 commits
-
-
Ian Lance Taylor authored
Fixes #30816 Updates #30646 Change-Id: I5b7e986b0588e87b9781cce01445e3c55c06b6fc Reviewed-on: https://go-review.googlesource.com/c/go/+/165897 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> (cherry picked from commit a6436a56) Reviewed-on: https://go-review.googlesource.com/c/go/+/167497 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Hana Kim authored
`go build` has chosen the last element of the package import path as the default output name when -o option is given. That caused the output of a package build when the module root is the major version component such as 'v2'. A similar issue involving `go install` was fixed in https://golang.org/cl/128900. This CL refactors the logic added with the change and makes it available as internal/load.DefaultExecName. This CL makes 'go test' to choose the right default test binary name when the tested package is in the module root. (E.g., instead of v2.test, choose pkg.test for the test of 'path/pkg/v2') Fixes #27283 Fixes #30266 Change-Id: I6905754f0906db46e3ce069552715f45356913ae Reviewed-on: https://go-review.googlesource.com/c/go/+/140863Reviewed-by: Bryan C. Mills <bcmills@google.com> (cherry picked from commit bf94fc3a) Reviewed-on: https://go-review.googlesource.com/c/go/+/167384 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Daniel Martí authored
Trying to call a method on a nil interface is a panic in Go. For example: var stringer fmt.Stringer println(stringer.String()) // nil pointer dereference In https://golang.org/cl/143097 we started recovering panics encountered during function and method calls. However, we didn't handle this case, as text/template panics before evalCall is ever run. In particular, reflect's MethodByName will panic if the receiver is of interface kind and nil: panic: reflect: Method on nil interface value Simply add a check for that edge case, and have Template.Execute return a helpful error. Note that Execute shouldn't just error if the interface contains a typed nil, since we're able to find a method to call in that case. Finally, add regression tests for both the nil and typed nil interface cases. Fixes #30464. Change-Id: Iffb21b40e14ba5fea0fcdd179cd80d1f23cabbab Reviewed-on: https://go-review.googlesource.com/c/161761 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> (cherry picked from commit 15b4c71a) Reviewed-on: https://go-review.googlesource.com/c/go/+/164457Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Cherry Zhang authored
Currently, runtime.KeepAlive applied on a stack object doesn't actually keeps the stack object alive, and the heap object referenced from it could be collected. This is because the address of the stack object is rematerializeable, and we just ignored KeepAlive on rematerializeable values. This CL fixes it. Updates #30476. Fixes #30478. Change-Id: Ic1f75ee54ed94ea79bd46a8ddcd9e81d01556d1d Reviewed-on: https://go-review.googlesource.com/c/164537 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> (cherry picked from commit 40df9cc6) Reviewed-on: https://go-review.googlesource.com/c/go/+/164627
-
Rémy Oudompheng authored
Instead of trying to guess type of constants in the AST, which is hard, use the "var cgo%d Type = Constant" so that typechecking is left to the Go compiler. The previous code could still fail in some cases for constants imported from other modules or defined in other, non-cgo files. Fixes #30527 Change-Id: I2120cd90e90a74b9d765eeec53f6a3d2cfc1b642 Reviewed-on: https://go-review.googlesource.com/c/go/+/164897 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> (cherry picked from commit 711ea1e7) Reviewed-on: https://go-review.googlesource.com/c/go/+/165748 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
lukechampine authored
Previously, the result of sorting a map[interface{}] containing multiple concrete types was non-deterministic. To ensure consistent results, sort first by type name, then by concrete value. Fixes #30484 Change-Id: I10fd4b6a74eefbc87136853af6b2e689bc76ae9d GitHub-Last-Rev: 1b07f0c275716e1b2834f74f9c67f897bae82882 GitHub-Pull-Request: golang/go#30406 Reviewed-on: https://go-review.googlesource.com/c/163745Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> (cherry picked from commit 9d40fadb) Reviewed-on: https://go-review.googlesource.com/c/go/+/164617 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
Make sure the side effects inside short-circuited operations (&& and ||) happen correctly. Before this CL, we attached the side effects to the node itself using exprInPlace. That caused other side effects in sibling expressions to get reordered with respect to the short circuit side effect. Instead, rewrite a && b like: r := a if r { r = b } That code we can keep correctly ordered with respect to other side-effects extracted from part of a big expression. exprInPlace seems generally unsafe. But this was the only case where exprInPlace is called not at the top level of an expression, so I don't think the other uses can actually trigger an issue (there can't be a sibling expression). TODO: maybe those cases don't need "in place", and we can retire that function generally. This CL needed a small tweak to the SSA generation of OIF so that the short circuit optimization still triggers. The short circuit optimization looks for triangle but not diamonds, so don't bother allocating a block if it will be empty. Go 1 benchmarks are in the noise. Fixes #30567 Change-Id: I19c04296bea63cbd6ad05f87a63b005029123610 Reviewed-on: https://go-review.googlesource.com/c/go/+/165617 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> (cherry picked from commit 4a9064ef) Reviewed-on: https://go-review.googlesource.com/c/go/+/165858Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Jay Conrod authored
The -coverpkg lets users specify a list of packages that should have coverage instrumentation. This may include packages not transitively imported by tests. For each tested package, the synthetic main package imports all covered packages so they can be registered with testing.RegisterCover. This makes it possible for a main package to import another main package. When we compile a package with p.Internal.BuildInfo set (set on main packages by Package.load in module mode), we set runtime/debug.modinfo. Multiple main packages may be passed to the linker because of the above scenario, so this causes duplicate symbol errors. This change copies p.Internal.BuildInfo to the synthetic main package instead of the internal test package. Additionally, it forces main packages imported by the synthetic test main package to be recompiled for testing. Recompiled packages won't have p.Internal.BuildInfo set. Fixes #30684 Change-Id: I06f028d55905039907940ec89d2835f5a1040203 Reviewed-on: https://go-review.googlesource.com/c/go/+/164877 Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> (cherry picked from commit 10156b67) Reviewed-on: https://go-review.googlesource.com/c/go/+/166318 TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
Updates #30446 Change-Id: If069f72fa9735f839df92f3ede3bf7b6d7a695a5 Reviewed-on: https://go-review.googlesource.com/c/164317Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> (cherry picked from commit e32203f6) Reviewed-on: https://go-review.googlesource.com/c/go/+/164318
-
- 08 Mar, 2019 1 commit
-
-
Bryan C. Mills authored
[release-branch.go1.12] cmd/go/internal/modfetch: handle codeRoot == path for paths with major-version suffixes Fixes #30665 Change-Id: Icbcfdb3907bc003ac17a8c7df17ecb41daf82eb4 Reviewed-on: https://go-review.googlesource.com/c/go/+/166117 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> (cherry picked from commit 1ab9f683) Reviewed-on: https://go-review.googlesource.com/c/go/+/166317
-
- 05 Mar, 2019 2 commits
-
-
Ian Lance Taylor authored
EvalSymlinks was mishandling cases like "/x/../../y" or "../../../x" where there is an extra ".." that goes past the start of the path. Updates #30520 Fixes #30586 Change-Id: I07525575f83009032fa1a99aa270c8d42007d276 Reviewed-on: https://go-review.googlesource.com/c/go/+/164762Reviewed-by: Bryan C. Mills <bcmills@google.com> (cherry picked from commit 294edb27) Reviewed-on: https://go-review.googlesource.com/c/go/+/165197Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Baokun Lee authored
Updates #30555 Fixes #30579 Change-Id: Ib894b4f3cdba23a18a69c9470cf69ceb83591a4d Reviewed-on: https://go-review.googlesource.com/c/go/+/165057 Run-TryBot: Baokun Lee <nototon@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> (cherry picked from commit c7465929) Reviewed-on: https://go-review.googlesource.com/c/go/+/165058 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 03 Mar, 2019 1 commit
-
-
Alberto Donizetti authored
There's a "lib/time" sub-section in the Go 1.12 relase notes that points to a non-existent golang.org/pkg/lib/time page. The note is about a change in the tz database in the src/lib/time directory, but the section's title (and the link) should probably just refer to the time package. Change-Id: Ibf9dacd710e72886f14ad0b7415fea1e8d25b83a Reviewed-on: https://go-review.googlesource.com/c/164977Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit 0dc62565) Reviewed-on: https://go-review.googlesource.com/c/164964Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
- 01 Mar, 2019 2 commits
-
-
Cherry Zhang authored
With stack objects, when we scan the stack, it scans defers with tracebackdefers, but it seems to me that tracebackdefers doesn't include the func value itself, which could be a stack allocated closure. Scan it explicitly. Alternatively, we can change tracebackdefers to include the func value, which in turn needs to change the type of stkframe. Updates #30453. Fixes #30470. Change-Id: I55a6e43264d6952ab2fa5c638bebb89fdc410e2b Reviewed-on: https://go-review.googlesource.com/c/164118Reviewed-by: Keith Randall <khr@golang.org> (cherry picked from commit 4f4c2a79) Reviewed-on: https://go-review.googlesource.com/c/164629 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Baokun Lee authored
If GOCACHE is set but is not an absolute path, we cannot build. And GOCACHE=off also returns the error message "build cache is disabled by GOCACHE=off". Fixes #30493 Change-Id: I24f64bc886599ca0acd757acada4714aebe4d3ae Reviewed-on: https://go-review.googlesource.com/c/164200 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> (cherry picked from commit 13d24b68) Reviewed-on: https://go-review.googlesource.com/c/164717 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 27 Feb, 2019 1 commit
-
-
Alberto Donizetti authored
Fixes #30431 Change-Id: I379e78a1c385942a19e1a10b91d732f9a73899e6 Reviewed-on: https://go-review.googlesource.com/c/164041Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit d7518ac5) Reviewed-on: https://go-review.googlesource.com/c/164077Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
- 26 Feb, 2019 3 commits
-
-
Ian Lance Taylor authored
Revert CL 137055, which changed Clean("\\somepath\dir\") to return "\\somepath\dir" on Windows. It's not entirely clear this is correct, as this path is really "\\server\share\", and as such the trailing slash may be the path on that share, much like "C:\". In any case, the change broke existing code, so roll it back for now and rethink for 1.13. Updates #27791 Updates #30307 Change-Id: I69200b1efe38bdb6d452b744582a2bfbb3acbcec Reviewed-on: https://go-review.googlesource.com/c/163077Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> (cherry picked from commit 153c0da8) Reviewed-on: https://go-review.googlesource.com/c/163078 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alberto Donizetti authored
Go 1.12 is released, but it's currently not listed in the https://golang.org/project page. Change-Id: Ib5820f74245e4c986014c64eb40fa2911473e64b Reviewed-on: https://go-review.googlesource.com/c/163837Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit 467456b0) Reviewed-on: https://go-review.googlesource.com/c/163727Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
fanzha02 authored
Current assembler reports error when it assembles "TSTW $1689262177517664, R3", but go1.11 was building fine. Fixes #30334 Change-Id: I9c16d36717cd05df2134e8eb5b17edc385aff0a9 Reviewed-on: https://go-review.googlesource.com/c/163259 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ben Shi <powerman1st@163.com> (cherry picked from commit 2ef8abb4) Reviewed-on: https://go-review.googlesource.com/c/163419 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 25 Feb, 2019 6 commits
-
-
Andrew Bonventre authored
Change-Id: I2fa947f75c0ace671ad8b99c4fab3ad7b178cedf Reviewed-on: https://go-review.googlesource.com/c/163725 Run-TryBot: Andrew Bonventre <andybons@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Andrew authored
Change-Id: I845375d2b3824211b80885228ba5b45503cba1a6 Reviewed-on: https://go-review.googlesource.com/c/163722Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit 8bffb854) Reviewed-on: https://go-review.googlesource.com/c/163723Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Andrew authored
Change-Id: Ib6a0f5c35b1efc3f3c8e7ca2a5c4f35bf8bf5e5d Reviewed-on: https://go-review.googlesource.com/c/163720Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit 9d26ec85) Reviewed-on: https://go-review.googlesource.com/c/163721Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Andrew authored
Using go get prevents the failure case of when the user doesn't have the repo on their machine. Change-Id: I9c1174087728b5b06b578b0d52df6eeb7e8c7a3c Reviewed-on: https://go-review.googlesource.com/c/163718Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit 2f9728aa) Reviewed-on: https://go-review.googlesource.com/c/163719Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
Lynn Boger authored
[release-branch.go1.12] cmd/compile: call ginsnop, not ginsnop2 on ppc64le for mid-stack inlining tracebacks A recent change to fix stacktraces for inlined functions introduced a regression on ppc64le when compiling position independent code. That happened because ginsnop2 was called for the purpose of inserting a NOP to identify the location of the inlined function, when ginsnop should have been used. ginsnop2 is intended to be used before deferreturn to ensure r2 is properly restored when compiling position independent code. In some cases the location where r2 is loaded from might not be initialized. If that happens and r2 is used to generate an address, the result is likely a SEGV. This fixes that problem. Fixes #30283 Change-Id: If70ef27fc65ef31969712422306ac3a57adbd5b6 Reviewed-on: https://go-review.googlesource.com/c/163337Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Andrew Bonventre <andybons@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> (cherry picked from commit 2d347404) Reviewed-on: https://go-review.googlesource.com/c/163717 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Cherry Zhang authored
[release-branch.go1.12] cmd/compile: guard against loads with negative offset from readonly constants CL 154057 adds guards agaist out-of-bound reads from readonly constants. It turns out that in dead code, the offset can also be negative. Guard against negative offset as well. Fixes #30257. Change-Id: I47c2a2e434dd466c08ae6f50f213999a358c796e Reviewed-on: https://go-review.googlesource.com/c/162819Reviewed-by: Keith Randall <khr@golang.org> (cherry picked from commit dca707b2) Reviewed-on: https://go-review.googlesource.com/c/162827 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 22 Feb, 2019 2 commits
-
-
Filippo Valsorda authored
Nothing in Go can truly guarantee a key will be gone from memory (see #21865), so remove that claim. That makes Reset useless, because unlike most Reset methods it doesn't restore the original value state, so deprecate it. Change-Id: I6bb0f7f94c7e6dd4c5ac19761bc8e5df1f9ec618 Reviewed-on: https://go-review.googlesource.com/c/162297Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit b35dacaa) Reviewed-on: https://go-review.googlesource.com/c/163438
-
Cherry Zhang authored
[release-branch.go1.12] cmd/compile: flow interface data to heap if CONVIFACE of a non-direct interface escapes Consider the following code: func f(x []*T) interface{} { return x } It returns an interface that holds a heap copy of x (by calling convT2I or friend), therefore x escape to heap. The current escape analysis only recognizes that x flows to the result. This is not sufficient, since if the result does not escape, x's content may be stack allocated and this will result a heap-to-stack pointer, which is bad. Fix this by realizing that if a CONVIFACE escapes and we're converting from a non-direct interface type, the data needs to escape to heap. Running "toolstash -cmp" on std & cmd, the generated machine code are identical for all packages. However, the export data (escape tags) differ in the following packages. It looks to me that all are similar to the "f" above, where the parameter should escape to heap. io/ioutil/ioutil.go:118 old: leaking param: r to result ~r1 level=0 new: leaking param: r image/image.go:943 old: leaking param: p to result ~r0 level=1 new: leaking param content: p net/url/url.go:200 old: leaking param: s to result ~r2 level=0 new: leaking param: s (as a consequence) net/url/url.go:183 old: leaking param: s to result ~r1 level=0 new: leaking param: s net/url/url.go:194 old: leaking param: s to result ~r1 level=0 new: leaking param: s net/url/url.go:699 old: leaking param: u to result ~r0 level=1 new: leaking param: u net/url/url.go:775 old: (*URL).String u does not escape new: leaking param content: u net/url/url.go:1038 old: leaking param: u to result ~r0 level=1 new: leaking param: u net/url/url.go:1099 old: (*URL).MarshalBinary u does not escape new: leaking param content: u flag/flag.go:235 old: leaking param: s to result ~r0 level=1 new: leaking param content: s go/scanner/errors.go:105 old: leaking param: p to result ~r0 level=0 new: leaking param: p database/sql/sql.go:204 old: leaking param: ns to result ~r0 level=0 new: leaking param: ns go/constant/value.go:303 old: leaking param: re to result ~r2 level=0, leaking param: im to result ~r2 level=0 new: leaking param: re, leaking param: im go/constant/value.go:846 old: leaking param: x to result ~r1 level=0 new: leaking param: x encoding/xml/xml.go:518 old: leaking param: d to result ~r1 level=2 new: leaking param content: d encoding/xml/xml.go:122 old: leaking param: leaking param: t to result ~r1 level=0 new: leaking param: t crypto/x509/verify.go:506 old: leaking param: c to result ~r8 level=0 new: leaking param: c crypto/x509/verify.go:563 old: leaking param: c to result ~r3 level=0, leaking param content: c new: leaking param: c crypto/x509/verify.go:615 old: (nothing) new: leaking closure reference c crypto/x509/verify.go:996 old: leaking param: c to result ~r1 level=0, leaking param content: c new: leaking param: c net/http/filetransport.go:30 old: leaking param: fs to result ~r1 level=0 new: leaking param: fs net/http/h2_bundle.go:2684 old: leaking param: mh to result ~r0 level=2 new: leaking param content: mh net/http/h2_bundle.go:7352 old: http2checkConnHeaders req does not escape new: leaking param content: req net/http/pprof/pprof.go:221 old: leaking param: name to result ~r1 level=0 new: leaking param: name cmd/internal/bio/must.go:21 old: leaking param: w to result ~r1 level=0 new: leaking param: w Fixes #29353. Change-Id: I7e7798ae773728028b0dcae5bccb3ada51189c68 Reviewed-on: https://go-review.googlesource.com/c/162829 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: David Chase <drchase@google.com> (cherry picked from commit 0349f29a) Reviewed-on: https://go-review.googlesource.com/c/163203Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 21 Feb, 2019 1 commit
-
-
Filippo Valsorda authored
In https://golang.org/cl/160998, RSA-PSS was disabled for (most of) TLS 1.2. One place where we can't disable it is in a Client Hello which offers both TLS 1.2 and 1.3: RSA-PSS is required by TLS 1.3, so to offer TLS 1.3 we need to offer RSA-PSS, even if the server might select TLS 1.2. The good news is that we want to disable RSA-PSS mostly when we are the signing side, as that's where broken crypto.Signer implementations will bite us. So we can announce RSA-PSS in the Client Hello, tolerate the server picking TLS 1.2 and RSA-PSS for their signatures, but still not do RSA-PSS on our side if asked to provide a client certificate. Client-TLSv12-ClientCert-RSA-PSS-Disabled changed because it was indeed actually using RSA-PSS. Updates #30055 Change-Id: I5ecade744b666433b37847abf55e1f08089b21d4 Reviewed-on: https://go-review.googlesource.com/c/163039Reviewed-by: Andrew Bonventre <andybons@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
-