- 06 Nov, 2019 2 commits
-
-
Marcel van Lohuizen authored
Change-Id: Ide3b689dd6808fc82f6310e4608e6d3574fafa82 Reviewed-on: https://go-review.googlesource.com/c/go/+/205339 Run-TryBot: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
Previously we would always “upgrade” to the semantically-highest version, even if a newer compatible version exists. That made certain classes of mistakes irreversible: in general we expect users to address bad releases by releasing a new (higher) version, but if the bad release was an unintended +incompatible version, then no release that includes a go.mod file can ever have a higher version, and the bad release will be treated as “latest” forever. Instead, when considering a +incompatible version we now consult the latest compatible (v0 or v1) release first. If the compatible release contains a go.mod file, we ignore the +incompatible releases unless they are expicitly requested (by version, commit ID, or branch name). Fixes #34165 Updates #34189 Change-Id: I7301eb963bbb91b21d3b96a577644221ed988ab7 Reviewed-on: https://go-review.googlesource.com/c/go/+/204440 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
- 05 Nov, 2019 34 commits
-
-
Bryan C. Mills authored
Also revert an incidental 'gofmt' of a vendored file from CL 205240. Updates #34822 Change-Id: I82a015d865db4d865b4776a8013312f25dbb9181 Reviewed-on: https://go-review.googlesource.com/c/go/+/205539 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Bryan C. Mills authored
codeRepo.Versions previously checked every possible +incompatible version for a 'go.mod' file. That is wasteful and counterproductive. It is wasteful because typically, a project will adopt modules at some major version, after which they will (be required to) use semantic import paths for future major versions. It is counterproductive because it causes an accidental '+incompatible' tag to exist, and no compatible tag can have higher semantic precedence. This change prunes out some of the +incompatible versions in codeRepo.Versions, eliminating the “wasteful” part but not all of the “counterproductive” part: the extraneous versions can still be fetched explicitly, and proxies may include them in the @v/list endpoint. Updates #34165 Updates #34189 Updates #34533 Change-Id: Ifc52c725aa396f7fde2afc727d0d5950acd06946 Reviewed-on: https://go-review.googlesource.com/c/go/+/204439 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Filippo Valsorda authored
We had some issues with reports being marked as spam, so I added a filter to never mark as spam something that mentions the word "vulnerability". We get too much spam at that address to disable the filter entirely, so instead meantion the bypass in the docs. Change-Id: Idb4dabcf51a9dd8234a2d571cd020c970b0a582c Reviewed-on: https://go-review.googlesource.com/c/go/+/205538Reviewed-by: Katie Hockman <katie@golang.org>
-
Ian Lance Taylor authored
Fixes #35247 Change-Id: I4f2e243c89e9f745b82bcd181add87fad1443171 Reviewed-on: https://go-review.googlesource.com/c/go/+/205457 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
-
Katie Hockman authored
dsa.Verify might currently use a nil s inverse in a multiplication if the public key contains a non-prime Q, causing a panic. Change this to check that the mod inverse exists before using it. Fixes CVE-2019-17596 Fixes #34960 Change-Id: I94d5f3cc38f1b5d52d38dcb1d253c71b7fd1cae7 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/572809Reviewed-by: Filippo Valsorda <valsorda@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/205441 Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
-
Bryan C. Mills authored
Fixes #35317 Change-Id: Id858a25dc16a1bbff1802d25bcd4aca31c1133bc Reviewed-on: https://go-review.googlesource.com/c/go/+/205067 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Cherry Zhang authored
When using cgo, we save G to TLS, and when a signal happens, we load G from TLS in sigtramp. This should give us a valid G. Don't try to fetch from the signal stack. In particular, C code may change the signal stack or call our signal handler directly (e.g. TSAN), so we are not necessarily running on the original gsignal stack where we saved G. Also skip saving G on the signal stack when using cgo. Updates #35249. Change-Id: I40749ce6682709bd4ebfdfd9f23bd0f317fc197d Reviewed-on: https://go-review.googlesource.com/c/go/+/204519Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Cherry Zhang authored
In the normal case, sigFetchG just returns the G register. But in the case that sigFetchG fetches the G from somewhere else, the G register still holding an invalid value. Setg here to make sure they match. This is particularly useful because setGsignalStack, called by adjustSignalStack from sigtrampgo before setg to gsignal, accesses the G register. Should fix #35249. Change-Id: I64c85143cb05cdb2ecca7f9936dbd8bfec186c2d Reviewed-on: https://go-review.googlesource.com/c/go/+/204441Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
Before this CL adjustTimers left timers being moved in an inconsistent state: status timerWaiting but not on a P. Simplify the code by leaving the timers in timerMoving status until they are actually moved. Other functions (deltimer, modtimer) will wait until the move is complete before changing anything on the timer. This does leave timers in timerMoving state for longer, but still not all that long. Fixes #35367 Change-Id: I31851002fb4053bd6914139125b4c82a68bf6fb2 Reviewed-on: https://go-review.googlesource.com/c/go/+/205418 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
-
Bryan C. Mills authored
Updates #32027 Change-Id: Ifc9427f35188c3fd356917d8510f3e01866ebca8 Reviewed-on: https://go-review.googlesource.com/c/go/+/205065 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
TestFormats adds ~3s of running time to the test, which may be slightly annoying in an edit/compile/test cycle but is negligible in a TryBot run. The test keeps regressing in the longtest builders, requiring a manual fix. Instead, run it even in short mode on the builders, so that TryBot runs will detect regressions ahead of time. Updates #34907 Updates #33915 Updates #28621 Change-Id: I6f9bf0f2ca929a743438310b86d85d8673c720bf Reviewed-on: https://go-review.googlesource.com/c/go/+/205440 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Pantelis Sampaziotis authored
Adds missing tests for all the types: * OneByteReader * HalfReader * DataErrReader * TimeoutReader * TruncateWriter * writeLogger * readLogger Fixes #33650 Change-Id: I1c773f9f1625ff33a1d0b5a045c72a73a9eca9ce GitHub-Last-Rev: 2ab650677bb9cad43ea2ce620c9898123c7ec396 GitHub-Pull-Request: golang/go#33651 Reviewed-on: https://go-review.googlesource.com/c/go/+/190259Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Dan Scales authored
Once defined, a stack slot holding an open-coded defer arg should always be marked live, since it may be used at any time if there is a panic. These stack slots are typically kept live naturally by the open-defer code inlined at each return/exit point. However, we need to do extra work to make sure that they are kept live if a function has an infinite loop or a panic exit. For this fix, only in the case of a function that is using open-coded defers, we compute the set of blocks (most often empty) that cannot reach a return or a BlockExit (panic) because of an infinite loop. Then, for each block b which cannot reach a return or BlockExit or is a BlockExit block, we mark each defer arg slot as live, as long as the definition of the defer arg slot dominates block b. For this change, had to export (*Func).sdom (-> Sdom) and SparseTree.isAncestorEq (-> IsAncestorEq) Updates #35277 Change-Id: I7b53c9bd38ba384a3794386dd0eb94e4cbde4eb1 Reviewed-on: https://go-review.googlesource.com/c/go/+/204802 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Bryan C. Mills authored
TestExecutableGOROOT, unlike most other tests in go_test.go, was running subcommands in a process with an environment derived directly from os.Environ(), rather than using tg.env on its testgoData object. Since tg.env is what sets GO111MODULE=off for GOPATH-mode tests, that caused TestExecutableGOROOT to unexpectedly run in module mode instead of GOPATH mode. If the user's environment included 'GOFLAGS=-mod=mod', that would cause the test to spuriously fail due to the inability to download modules to $HOME (which in this test binary is hard-coded to "/test-go-home-does-not-exist"). Updates #33848 Change-Id: I2f343008dd9e38cd76b9919eafd5a3181d0cbd6f Reviewed-on: https://go-review.googlesource.com/c/go/+/205064 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Bryan C. Mills authored
The test for gopkg.in/yaml.v2@v2 assumes that there are no future upstream releases. That assumption empirically does not hold. Backporting fixes to this test is annoying, and other gopkg.in cases are already reasonably covered, so remove the problematic test. Updates #28856 Change-Id: I6455baa1816ac69e02d1ad5d03b82a93e1481a17 Reviewed-on: https://go-review.googlesource.com/c/go/+/205437 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Bryan C. Mills authored
Updates #34822 Change-Id: I189d93ebd3ce6cd1b8f1e29336876fd82a7cfff7 Reviewed-on: https://go-review.googlesource.com/c/go/+/204877 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Elias Naur authored
Recent Xcode versions started to complain about the current min version: ld: warning: OS version (6.0.0) too small, changing to 7.0.0 Change-Id: Ieb525dd3e57429fe226b9d30d584b073c5e4768c Reviewed-on: https://go-review.googlesource.com/c/go/+/204663Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com> Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Marcel van Lohuizen authored
This does not include an upgrade of golang.org/x/net. This is optional and best done as a separate CL. Change-Id: Ifecc3fb6e3b7fe026b4ddefbe637186a3445b0bc Reviewed-on: https://go-review.googlesource.com/c/go/+/204658 Run-TryBot: Marcel van Lohuizen <mpvl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
Fixes #35347 Change-Id: If7380f29e97a5abe86cdd5e2853323de7997ccfc Reviewed-on: https://go-review.googlesource.com/c/go/+/205378 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Ian Lance Taylor authored
CL 196959 uses %v to print *EscLocation values. This happens at least at Fatalf("path inconsistency: %v != %v", edge.src, src) in (*Escape).explainPath. Change-Id: I1c761406af6a1025403dfefa5ec40aee75e72944 Reviewed-on: https://go-review.googlesource.com/c/go/+/205377 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Lars Lehtonen authored
Pick up a dropped error in TestSendMailWithAuth() and simplify goroutine to use an error channel instead of a sync.WaitGroup and an empty struct doneCh. Change-Id: Ie70d0f7c4c85835eb682e81d086ce4d9900269e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/205247 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Cherry Zhang authored
The flag field will be used for marking unsafe points. This CL just adds the field, not doing anything with it. The next CL will make use of it. This is for making the diff simpler. Change-Id: I6ff5406ba2e53ae8a882184733d88482a2ca8e2a Reviewed-on: https://go-review.googlesource.com/c/go/+/203938 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Cherry Zhang authored
Frameless function is an interesting case for call injection espcially for LR architectures. Extend the test for this case. Change-Id: I074090d09eeaf642e71e3f44fea216f66d39b817 Reviewed-on: https://go-review.googlesource.com/c/go/+/202339 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Lars Lehtonen authored
Change-Id: I9cfaba4f1af23ab67627bf496739311e4d1984c3 Reviewed-on: https://go-review.googlesource.com/c/go/+/205245Reviewed-by: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Cherry Zhang authored
Introduce a mechanism for marking architecture-specific Ops unsafe. And mark ones that use REGTMP on ARM64, as for async preemption we will be using REGTMP as a temporary register in the injected call. Change-Id: I8ff22e87d8f9cb10d02a2f0af7c12ad6d7d58f54 Reviewed-on: https://go-review.googlesource.com/c/go/+/203459 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Austin Clements <austin@google.com>
-
Cherry Zhang authored
For async preemption, we will be using REGTMP as a temporary register in injected call on ARM64, which will clobber it. So any code that uses REGTMP is not safe for async preemption. For ZeroRange, which is inserted at the function entry where there is no register live, we could just use a different register and avoid REGTMP. Change-Id: I3db763828df6846908c9843a9912597efb9efcdf Reviewed-on: https://go-review.googlesource.com/c/go/+/203458 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Cherry Zhang authored
This CL adds support of call injection and async preemption on ARM. Injected call, like sigpanic, has special frame layout. Teach traceback to handle it. Change-Id: I887e90134fbf8a676b73c26321c50b3c4762dba4 Reviewed-on: https://go-review.googlesource.com/c/go/+/202338 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Austin Clements <austin@google.com>
-
Keith Randall authored
Actual fix will be submitted to x/tools and vendored. This is just an end-to-end test for vet after that is done. Update #35264 Change-Id: I1a63f607e7cfa7aafee23c2c081086c276d3c38c Reviewed-on: https://go-review.googlesource.com/c/go/+/204538 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
-
Matthew Dempsky authored
The logic for keeping arguments alive for calls to //go:uintptrescapes functions was only applying to direct function calls. This CL changes it to also apply to direct method calls, which should address most uses of Proc.Call and LazyProc.Call. It's still an open question (#34684) whether other call forms (e.g., method expressions, or indirect calls via function values, method values, or interfaces). Fixes #34474. Change-Id: I874f97145972b0e237a4c9e8926156298f4d6ce0 Reviewed-on: https://go-review.googlesource.com/c/go/+/198043 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Ian Lance Taylor authored
Programs should always check the error return of Close for a file opened for writing. Update the example code in the comment to mention this. Change-Id: I2ff6866ff1fe23b47c54268ac8e182210cc876c5 Reviewed-on: https://go-review.googlesource.com/c/go/+/202137Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
As a side-effect ensure that netpollinited only reports true when netpoll initialization is complete. Fixes #35282 Updates #35353 Change-Id: I21f08a04fcf229e0de5e6b5ad89c990426ae9b89 Reviewed-on: https://go-review.googlesource.com/c/go/+/204937 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
Fixes #35264 Change-Id: Id540a48f593d8ac1b414551255c5eff24666aa0b Reviewed-on: https://go-review.googlesource.com/c/go/+/205240 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
This CL extends cmd/compile's experimental libFuzzer support with calls to __sanitizer_cov_trace_{,const_}cmp{1,2,4,8}. This allows much more efficient fuzzing of comparisons. Only supports amd64 and arm64 for now. Updates #14565. Change-Id: Ibf82a8d9658f2bc50d955bdb1ae26723a3f0584d Reviewed-on: https://go-review.googlesource.com/c/go/+/203887 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Matthew Dempsky authored
This CL adds experimental coverage instrumentation similar to what github.com/dvyukov/go-fuzz produces in its -libfuzzer mode. The coverage can be enabled by compiling with -d=libfuzzer. It's intended to be used in conjunction with -buildmode=c-archive to produce an ELF archive (.a) file that can be linked with libFuzzer. See #14565 for example usage. The coverage generates a unique 8-bit counter for each basic block in the original source code, and emits an increment operation. These counters are then collected into the __libfuzzer_extra_counters ELF section for use by libFuzzer. Updates #14565. Change-Id: I239758cc0ceb9ca1220f2d9d3d23b9e761db9bf1 Reviewed-on: https://go-review.googlesource.com/c/go/+/202117 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
- 04 Nov, 2019 4 commits
-
-
Michael Anthony Knyszek authored
This change renames the "round" function to the more appropriately named "alignUp" which rounds an integer up to the next multiple of a power of two. This change also adds the alignDown function, which is almost like alignUp but rounds down to the previous multiple of a power of two. With these two functions, we also go and replace manual rounding code with it where we can. Change-Id: Ie1487366280484dcb2662972b01b4f7135f72fec Reviewed-on: https://go-review.googlesource.com/c/go/+/190618Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Keith Randall <khr@golang.org>
-
Brad Fitzpatrick authored
Fixes #35082 Updates #6853 Change-Id: I4eeb0e15f534cff57fefb6039cd33fadf15b946e Reviewed-on: https://go-review.googlesource.com/c/go/+/205139Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Michael Knyszek authored
This change makes it so that the GC pacer's trigger ratio can never fall below 0.6. Upcoming changes to the allocator make it significantly more scalable and thus much faster in certain cases, creating a large gap between the performance of allocation and scanning. The consequence of this is that the trigger ratio can drop very low (0.07 was observed) in order to drop GC utilization. A low trigger ratio like this results in a high amount of black allocations, which causes the live heap to appear larger, and thus the heap, and RSS, grows to a much higher stable point. This change alleviates the problem by placing a lower bound on the trigger ratio. The expected (and confirmed) effect of this is that utilization in certain scenarios will no longer converge to the expected 25%, and may go higher. As a result of this artificially high trigger ratio, more time will also be spent doing GC assists compared to dedicated mark workers, since the GC will be on for an artifically short fraction of time (artificial with respect to the pacer). The biggest concern of this change is that allocation latency will suffer as a result, since there will now be more assists. But, upcoming changes to the allocator reduce the latency enough to outweigh the expected increase in latency from this change, without the blowup in RSS observed from the changes to the allocator. Updates #35112. Change-Id: Idd7c94fa974d0de673304c4397e716e89bfbf09b Reviewed-on: https://go-review.googlesource.com/c/go/+/200439Reviewed-by: Austin Clements <austin@google.com>
-
Richard Musiol authored
The js.Value struct now contains a pointer, so a finalizer can determine if the value is not referenced by Go any more. Unfortunately this breaks Go's == operator with js.Value. This change adds a new Equal method to check for the equality of two Values. This is a breaking change. The == operator is now disallowed to not silently break code. Additionally the helper methods IsUndefined, IsNull and IsNaN got added. Fixes #35111 Change-Id: I58a50ca18f477bf51a259c668a8ba15bfa76c955 Reviewed-on: https://go-review.googlesource.com/c/go/+/203600 Run-TryBot: Richard Musiol <neelance@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-