- 14 Oct, 2019 3 commits
-
-
Than McIntosh authored
Add to the testcase originally created for issue 34577 so as to also trigger the error condition for issue 34852 (the two bugs are closely related). Updates #34577. Updates #34852. Change-Id: I2347369652ce500184347606b2bb3e76d802b204 Reviewed-on: https://go-review.googlesource.com/c/go/+/201017 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Agniva De Sarker authored
For GOROOT packages, we were adding -unsafeptr=false to prevent unsafe.Pointer checks. But the flag also got passed to invocations of go vet with a custom vet tool. To prevent this from happening, we add this flag only when no tools are passed. Fixes #34053 Change-Id: I8bcd637fd8ec423d597fcdab2a0ceedd20786019 Reviewed-on: https://go-review.googlesource.com/c/go/+/200957 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Jay Conrod <jayconrod@google.com>
-
Tobias Klauser authored
These are unused since the darwin port switched to libc calls in CL 148457. Change-Id: I309bb5b0a52c9069484e7a649d4a652efcb8e160 Reviewed-on: https://go-review.googlesource.com/c/go/+/200866 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 13 Oct, 2019 2 commits
-
-
Matthew Dempsky authored
This flag is supposed to indicate whether the expression is "addressable"; but in practice, we infer this from other attributes about the expression (e.g., n.Op and n.Class()). Passes toolstash-check. Change-Id: I19352ca07ab5646e232d98e8a7c1c9aec822ddd0 Reviewed-on: https://go-review.googlesource.com/c/go/+/200897 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
This pseudo-Class was previously used by the importer code to optimize processing duplicate inline bodies, since we didn't actually care about the declarations in those contexts. This functionality is no longer needed with indexed exports, since we now only process function bodies as needed (and never more than once). Passes toolstash-check. Change-Id: I7eab0cb16925ab777079c2a20731dbcfd63cf195 Reviewed-on: https://go-review.googlesource.com/c/go/+/200899Reviewed-by:
-
- 12 Oct, 2019 5 commits
-
-
Giovanni Bajo authored
Make it a bit more relaxed on the expected fairness, as fastrand() isn't a truly perfect random number generator. Fixes #34808 Change-Id: Ib55b2bbe3c1bf63fb4f446fd1291eb1236efc33b Reviewed-on: https://go-review.googlesource.com/c/go/+/200857 Run-TryBot: Giovanni Bajo <rasky@develer.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Meng Zhuo authored
Some nameservers alter the case of records as they return, e.g .google.COM or .Google.com. However according to RFC4343, DNS name should be treated in case insensitive fashion. This CL will fix case sensitive testcases. Fixes #34781 Change-Id: I5f9f6a41ddc1c61993e8d1f934ef0febddc3adc1 Reviewed-on: https://go-review.googlesource.com/c/go/+/200277Reviewed-by:
Andrei Tudor Călin <mail@acln.ro> Reviewed-by:
-
zdjones authored
When assessing whether A <= B, the poset's OrderedOrEqual has a passing condition which permits A <= B, but is not sufficient to infer that A <= B. This CL removes that incorrect passing condition. Having identified that A and B are in the poset, the method will report that A <= B if any of these three conditions are true: (1) A and B are the same node in the poset. - This means we know that A == B. (2) There is a directed path, strict or not, from A -> B - This means we know that, at least, A <= B, but A < B is possible. (3) There is a directed path from B -> A, AND that path has no strict edges. - This means we know that B <= A, but do not know that B < A. In condition (3), we do not have enough information to say that A <= B, rather we only know that B == A (which satisfies A <= B) is possible. The way I understand it, a strict edge shows a known, strictly-ordered relation (<) but the lack of a strict edge does not show the lack of a strictly-ordered relation. The difference is highlighted by the example in #34802, where a bounds check is incorrectly removed by prove, such that negative indexes into a slice succeed: n := make([]int, 1) for i := -1; i <= 0; i++ { fmt.Printf("i is %d\n", i) n[i] = 1 // No Bounds check, program runs, assignment to n[-1] succeeds!! } When prove is checking the negative/failed branch from the bounds check at n[i], in the signed domain we learn (0 > i || i >= len(n)). Because prove can't learn the OR condition, we check whether we know that i is non-negative so we can learn something, namely that i >= len(n). Prove uses the poset to check whether we know that i is non-negative. At this point the poset holds the following relations as a directed graph: -1 <= i <= 0 -1 < 0 In poset.OrderedOrEqual, we are testing for 0 <= i. In this case, condition (3) above is true because there is a non-strict path from i -> 0, and that path does NOT have any strict edges. Because this condition is true, the poset reports to prove that i is known to be >= 0. Knowing, incorrectly, that i >= 0, prove learns from the failed bounds check that i >= len(n) in the signed domain. When the slice, n, was created, prove learned that len(n) == 1. Because i is also the induction variable for the loop, upon entering the loop, prove previously learned that i is in [-1,0]. So when prove attempts to learn from the failed bounds check, it finds the new fact, i > len(n), unsatisfiable given that it previously learned that i <= 0 and len(n) = 1. Fixes #34802 Change-Id: I235f4224bef97700c3aa5c01edcc595eb9f13afc Reviewed-on: https://go-review.googlesource.com/c/go/+/200759 Run-TryBot: Zach Jones <zachj1@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Giovanni Bajo <rasky@develer.com> Reviewed-by:
-
Cuong Manh Le authored
Change-Id: Id0f4955588ae8027a24465b456c90d0543d60db2 Reviewed-on: https://go-review.googlesource.com/c/go/+/200581 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Cuong Manh Le authored
Passes toolstash-check. Updates #23017 Change-Id: I0ae82e28a6e9e732ba2a6aa98f9b35551efcea10 Reviewed-on: https://go-review.googlesource.com/c/go/+/200580 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 11 Oct, 2019 18 commits
-
-
Ian Lance Taylor authored
Fixes #34854 Change-Id: I7d6819c439e2fdfb19e181b202797fd5851eb002 Reviewed-on: https://go-review.googlesource.com/c/go/+/200839 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jerrin Shaji George authored
nanotime() currently uses the REALTIME clock to get the elapsed time in Solaris. This commit changes it to use the MONOTONIC clock instead, similar to how it's done in Linux and other OSs. Also changed nanotime() and walltime() to call clock_gettime() library function directly from Go code rather than from assembly. Fixes #33674 Change-Id: Ie4a687b17d2140998ecd97af6ce048c86cf5fc02 Reviewed-on: https://go-review.googlesource.com/c/go/+/199502 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
Aram Hăvărneanu <aram@mgk.ro>
-
Ian Lance Taylor authored
This timeout will never be reached if the test passes, so it doesn't much matter how long it is. The test is t.Parallel so on a slow system 1 second may occasionally not be enough, although on my laptop the test takes about 0.02 seconds. Fixes #34431 Change-Id: Ia2184e6be3747933bfe83aa6c8e1f77e6b1e0bba Reviewed-on: https://go-review.googlesource.com/c/go/+/200764 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Bryan C. Mills <bcmills@google.com>
-
Ian Lance Taylor authored
If the runtime disables the SIGPROF handler, because this is Go code that is linked into a non-Go program, then don't go back to the default handling of SIGPROF; just start ignoring SIGPROF. Otherwise the program can get killed by a stray SIGPROF that is delivered, presumably to a different thread, after profiling is disabled. Fixes #19320 Change-Id: Ifebae477d726699c8c82c867604b73110c1cf262 Reviewed-on: https://go-review.googlesource.com/c/go/+/200740 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ariel Mashraki authored
The slice capacity is known for all these cases. Therefore, we can initialize them with the desired capacity. Change-Id: I1835b49108d157203d62e4aa119c2d7ab5e5e46f Reviewed-on: https://go-review.googlesource.com/c/go/+/200119 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Bryan C. Mills authored
Fixes #26123 Change-Id: If0dad65a3885d2146624f2aac42099e9eca9670e Reviewed-on: https://go-review.googlesource.com/c/go/+/200758 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jay Conrod authored
This change integrates changes made to x/mod packages into our internal copies of those packages. This is the first step of a bidirectional synchronization. A follow-up change will copy changes made to the internal packages after x/mod was forked. After that, we can vendor x/mod, update imports, and delete the internal copies. The following packages are affected: * internal/module * internal/semver (no change) * internal/sumweb (renamed to internal/sumdb) * internal/dirhash * internal/note * internal/tlog Several integrated changes affect other packages: * cmd/go/internal/module.MatchPathMajor now wraps a new function, CheckPathMajor, which returns error. MatchPathMajor returns bool. This will avoid an incompatible change in the next step. * module.EncodePath renamed to EscapePath, EncodeVersion to EscapeVersion, DecodePath to UnescapePath, DecodeVersion to UnescapeVersion. * cmd/go/internal/sumweb moved to cmd/go/internal/sumdb and package renamed to sumdb. * sumdb.Client renamed to ClientOps, Conn to Client, Server to ServerOps, Paths to ServerPaths. * sumdb/encode.go and encode_test.go are not present in x/mod since they are redundant with functionality in module. Both files are deleted. * sumdb.TestServer doesn't implement sumdb.ServerOps after changes were were made to golang.org/x/mod/sumdb.ServerOps during the fork. Local changes made so tests will pass. These will be copied to x/mod in the next step. Updates #34801 Change-Id: I7e820f10ae0cdbec238e59d039e978fd1cdc7201 Reviewed-on: https://go-review.googlesource.com/c/go/+/200138 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Richard Musiol authored
An extra goroutine is necessary to handle asynchronous events on wasm. However, we do not want this goroutine to exist all the time. This change makes it short-lived, so it ends after the asynchronous event was handled. Fixes #34768 Change-Id: I24626ff0af9d803a01ebe33fbb584d04d2059a44 Reviewed-on: https://go-review.googlesource.com/c/go/+/200497 Run-TryBot: Richard Musiol <neelance@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
We couldn't do this before because sighandler was compiled for nacl. Updates #30439 Change-Id: Ieec9938b6a1796c48d251cd8b1db1a42c25f3943 Reviewed-on: https://go-review.googlesource.com/c/go/+/200739 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
Alex Buchanan authored
NextPart has automatic handling of quoted-printable encoding, which is sometimes undesirable. NextRawPart adds a method for reading a part while bypassing such automatic handling. Fixes #29090 Change-Id: I6a042a4077c64091efa3f5dbecce0d9a34ac7065 Reviewed-on: https://go-review.googlesource.com/c/go/+/152877 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Constantin Konstantinidis authored
RFC 5322 date format allows CFWS after the timezone. If CFWS is valid, it is discarded and parsing is done as before using time.Parse(). Existing test is extended with limit cases and invalid strings. Fixes #22661 Change-Id: I54b96d7bc384b751962a76690e7e4786217a7941 Reviewed-on: https://go-review.googlesource.com/c/go/+/117596 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Francesco Renzi authored
This makes Decoder.offset public while renaming it to Decoder.InputOffset to match encoding/xml Decoder API Code changes made by Adam Stankiewicz [sheerun@sher.pl] Fixes #29688 Change-Id: I86dbfd2b2da80160846e92bfa580c53d8d45e2db Reviewed-on: https://go-review.googlesource.com/c/go/+/200677 Run-TryBot: Johan Brandhorst <johan.brandhorst@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Michael Munday authored
Avoid an out-of-range error when calling LongString on a generic block. Change-Id: I33ca88940d899bc71e3155bc63d2aa925cf83230 Reviewed-on: https://go-review.googlesource.com/c/go/+/200737 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Daniel Martí <mvdan@mvdan.cc>
-
Emmanuel T Odeke authored
Increases the exec timeout from 5sec to 1min, but also print out the error value on any test failure. Fixes #34836 Change-Id: Ida2b8bd460243491ef0f90dfe0f978dfe02a0703 Reviewed-on: https://go-review.googlesource.com/c/go/+/200519 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
fenos authored
We should keep a consistent way of formatting errors in this file. Fixes #34848 Change-Id: Ibb75908504f381fccab0281a42e788ef8c716b6f Reviewed-on: https://go-review.googlesource.com/c/go/+/200679 Run-TryBot: Johan Brandhorst <johan.brandhorst@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
davidsbond authored
Fixes #34846 Change-Id: I24b3e65fc96ec85b2821480e9396c9d1663611c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/200678 Run-TryBot: Johan Brandhorst <johan.brandhorst@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Johan Brandhorst <johan.brandhorst@gmail.com>
-
Bryan C. Mills authored
Fixes #34847 Change-Id: Ibb58c8820cdab8b9f3755fcfba754ad0c9ca982f Reviewed-on: https://go-review.googlesource.com/c/go/+/200657 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Elias Naur <mail@eliasnaur.com>
-
Agniva De Sarker authored
Coalesce set/get pairs into a tee. Change-Id: I88ccdcb148465615437bebf24145e941a037e0a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/200357 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Richard Musiol <neelance@gmail.com> Reviewed-by:
-
- 10 Oct, 2019 7 commits
-
-
Brad Fitzpatrick authored
Part 1: CL 199499 (GOOS nacl) Part 2: CL 200077 (amd64p32 files, toolchain) Part 3: stuff that arguably should've been part of Part 2, but I forgot one of my grep patterns when splitting the original CL up into two parts. This one might also have interesting stuff to resurrect for any future x32 ABI support. Updates #30439 Change-Id: I2b4143374a253a003666f3c69e776b7e456bdb9c Reviewed-on: https://go-review.googlesource.com/c/go/+/200318 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Brad Fitzpatrick authored
Fixes #34768 Change-Id: Ic73591f620cdee5bc7203483902e6ba98d2c442b Reviewed-on: https://go-review.googlesource.com/c/go/+/200438Reviewed-by:
-
alan authored
Change-Id: If5a272f331fe9da09467efedd0231a4ce34db0f8 GitHub-Last-Rev: 4b81a79a92db4b51001ce6660b24c760fd3b630b GitHub-Pull-Request: golang/go#28420 Reviewed-on: https://go-review.googlesource.com/c/go/+/144999 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Jay Conrod authored
Also, in cmd/doc, avoid calling 'go list -m all' when in module mode outside a module since it's now an error. Fixes #32027 Change-Id: I7224c7fdf7e950bce6c058ab2a5837c27ba3b899 Reviewed-on: https://go-review.googlesource.com/c/go/+/200297 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jeremy Faller authored
Walking the progs is simpler than using the is_stmt symbol shenanigans. This is a reinstatement of CL 196661, which was rolled back due to tests failing. Unlike that original CL, this change should output the same debug_lines data the original approach wrote. The stats for JUST this CLC, note teh small speedup in compilation, and the lack of difference in binary size. name old time/op new time/op delta Template 229ms ± 4% 218ms ± 1% -4.95% (p=0.000 n=10+8) Unicode 92.6ms ± 9% 88.6ms ±13% ~ (p=0.089 n=10+10) GoTypes 850ms ± 2% 831ms ± 4% -2.23% (p=0.009 n=10+10) Compiler 3.99s ± 1% 3.93s ± 1% -1.29% (p=0.000 n=10+9) SSA 13.7s ± 1% 13.7s ± 1% ~ (p=0.912 n=10+10) Flate 140ms ± 3% 138ms ± 3% -1.90% (p=0.009 n=10+10) GoParser 172ms ± 2% 169ms ± 4% ~ (p=0.095 n=9+10) Reflect 530ms ± 3% 516ms ± 5% ~ (p=0.052 n=10+10) Tar 202ms ± 1% 196ms ± 3% -2.83% (p=0.002 n=9+10) XML 280ms ± 3% 270ms ± 4% -3.48% (p=0.009 n=10+10) LinkCompiler 927ms ± 2% 907ms ± 4% ~ (p=0.052 n=10+10) ExternalLinkCompiler 1.97s ± 2% 1.97s ± 3% ~ (p=0.853 n=10+10) LinkWithoutDebugCompiler 549ms ± 3% 543ms ± 5% ~ (p=0.481 n=10+10) StdCmd 12.0s ± 1% 12.0s ± 1% ~ (p=0.905 n=9+10) name old user-time/op new user-time/op delta Template 372ms ±18% 344ms ±11% ~ (p=0.190 n=10+10) Unicode 264ms ±23% 241ms ±43% ~ (p=0.315 n=8+10) GoTypes 1.56s ±22% 1.68s ± 5% ~ (p=0.237 n=10+8) Compiler 7.41s ± 2% 7.31s ± 3% ~ (p=0.123 n=10+10) SSA 24.5s ± 2% 24.7s ± 1% ~ (p=0.133 n=10+9) Flate 199ms ± 6% 188ms ±28% ~ (p=0.353 n=10+10) GoParser 243ms ±11% 240ms ± 6% ~ (p=0.968 n=10+9) Reflect 929ms ±21% 862ms ±35% ~ (p=0.190 n=10+10) Tar 284ms ± 9% 296ms ±17% ~ (p=0.497 n=9+10) XML 386ms ±21% 398ms ±28% ~ (p=1.000 n=9+10) LinkCompiler 1.13s ± 9% 1.12s ± 8% ~ (p=0.546 n=9+9) ExternalLinkCompiler 2.37s ±15% 2.30s ± 9% ~ (p=0.549 n=10+9) LinkWithoutDebugCompiler 646ms ±10% 642ms ±13% ~ (p=0.853 n=10+10) name old alloc/op new alloc/op delta Template 36.5MB ± 0% 36.5MB ± 0% -0.11% (p=0.000 n=10+9) Unicode 28.5MB ± 0% 28.5MB ± 0% ~ (p=0.190 n=10+10) GoTypes 121MB ± 0% 121MB ± 0% -0.10% (p=0.000 n=9+10) Compiler 549MB ± 0% 549MB ± 0% -0.10% (p=0.000 n=9+10) SSA 1.92GB ± 0% 1.92GB ± 0% -0.13% (p=0.000 n=10+10) Flate 23.0MB ± 0% 23.0MB ± 0% -0.07% (p=0.000 n=10+10) GoParser 27.9MB ± 0% 27.9MB ± 0% -0.09% (p=0.000 n=10+10) Reflect 77.9MB ± 0% 77.8MB ± 0% -0.13% (p=0.000 n=9+10) Tar 34.5MB ± 0% 34.4MB ± 0% -0.09% (p=0.000 n=10+10) XML 44.3MB ± 0% 44.3MB ± 0% -0.08% (p=0.000 n=10+10) LinkCompiler 229MB ± 0% 225MB ± 0% -1.74% (p=0.000 n=10+10) ExternalLinkCompiler 233MB ± 0% 242MB ± 0% +3.81% (p=0.000 n=10+10) LinkWithoutDebugCompiler 156MB ± 0% 152MB ± 0% -2.29% (p=0.000 n=10+9) name old allocs/op new allocs/op delta Template 373k ± 0% 373k ± 0% -0.21% (p=0.000 n=10+10) Unicode 340k ± 0% 340k ± 0% -0.04% (p=0.000 n=10+10) GoTypes 1.33M ± 0% 1.33M ± 0% -0.20% (p=0.000 n=10+9) Compiler 5.39M ± 0% 5.38M ± 0% -0.16% (p=0.000 n=10+10) SSA 18.3M ± 0% 18.2M ± 0% -0.15% (p=0.000 n=10+10) Flate 235k ± 0% 234k ± 0% -0.23% (p=0.000 n=10+7) GoParser 309k ± 0% 308k ± 0% -0.20% (p=0.000 n=10+10) Reflect 970k ± 0% 968k ± 0% -0.30% (p=0.000 n=10+10) Tar 347k ± 0% 347k ± 0% -0.22% (p=0.000 n=10+10) XML 425k ± 0% 424k ± 0% -0.16% (p=0.000 n=10+10) LinkCompiler 602k ± 0% 601k ± 0% -0.03% (p=0.000 n=9+10) ExternalLinkCompiler 1.65M ± 0% 1.65M ± 0% -0.02% (p=0.000 n=10+10) LinkWithoutDebugCompiler 220k ± 0% 220k ± 0% -0.03% (p=0.016 n=10+9) name old object-bytes new object-bytes delta Template 553kB ± 0% 553kB ± 0% -0.01% (p=0.000 n=10+10) Unicode 215kB ± 0% 215kB ± 0% ~ (all equal) GoTypes 2.02MB ± 0% 2.02MB ± 0% -0.00% (p=0.000 n=10+10) Compiler 7.98MB ± 0% 7.98MB ± 0% -0.01% (p=0.000 n=10+10) SSA 27.1MB ± 0% 27.1MB ± 0% -0.00% (p=0.000 n=10+10) Flate 340kB ± 0% 340kB ± 0% -0.01% (p=0.000 n=10+10) GoParser 434kB ± 0% 434kB ± 0% -0.00% (p=0.000 n=10+10) Reflect 1.34MB ± 0% 1.34MB ± 0% -0.01% (p=0.000 n=10+10) Tar 479kB ± 0% 479kB ± 0% -0.00% (p=0.000 n=10+10) XML 618kB ± 0% 618kB ± 0% -0.01% (p=0.000 n=10+10) name old export-bytes new export-bytes delta Template 20.4kB ± 0% 20.4kB ± 0% ~ (all equal) Unicode 8.21kB ± 0% 8.21kB ± 0% ~ (all equal) GoTypes 36.6kB ± 0% 36.6kB ± 0% ~ (all equal) Compiler 116kB ± 0% 116kB ± 0% +0.00% (p=0.000 n=10+10) SSA 141kB ± 0% 141kB ± 0% +0.00% (p=0.000 n=10+10) Flate 5.10kB ± 0% 5.10kB ± 0% ~ (all equal) GoParser 8.92kB ± 0% 8.92kB ± 0% ~ (all equal) Reflect 11.8kB ± 0% 11.8kB ± 0% ~ (all equal) Tar 10.9kB ± 0% 10.9kB ± 0% ~ (all equal) XML 17.4kB ± 0% 17.4kB ± 0% ~ (all equal) name old text-bytes new text-bytes delta HelloSize 742kB ± 0% 742kB ± 0% ~ (all equal) CmdGoSize 10.6MB ± 0% 10.6MB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 10.7kB ± 0% 10.7kB ± 0% ~ (all equal) CmdGoSize 312kB ± 0% 312kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 122kB ± 0% 122kB ± 0% ~ (all equal) CmdGoSize 146kB ± 0% 146kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.10MB ± 0% 1.10MB ± 0% ~ (all equal) CmdGoSize 14.9MB ± 0% 14.9MB ± 0% -0.03% (p=0.000 n=10+10) Change-Id: Ie078a42b29353b96654fa1f0f47d600b5a53762d Reviewed-on: https://go-review.googlesource.com/c/go/+/200017Reviewed-by:
Jeremy Faller <jeremy@golang.org> Reviewed-by:
David Chase <drchase@google.com> Run-TryBot: Jeremy Faller <jeremy@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Cuong Manh Le authored
When unmarshaling to a map, the map's key type must either be a string, an integer, or implement encoding.TextUnmarshaler. But for a user defined type, reflect.Kind will not distinguish between the static type and the underlying type. In: var x MyString = "x" t := reflect.TypeOf(x) println(t.Kind() == reflect.String) the Kind of x is still reflect.String, even though the static type of x is MyString. Moreover, checking for the map's key type is a string occurs first, so even if the map key type MyString implements encoding.TextUnmarshaler, it will be ignored. To fix the bug, check for encoding.TextUnmarshaler first. Fixes #34437 Change-Id: I780e0b084575e1dddfbb433fe03857adf71d05fb Reviewed-on: https://go-review.googlesource.com/c/go/+/200237 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Tom Thorogood authored
Compact has been inconsistently escaping only some problematic characters (U+2028 and U+2029), but not others (<, > and &). This change addresses this inconsistency by removing the escaping of U+2028 and U+2029. Callers who need to escape the output of Compact should use HTMLEscape which escapes <, >, &, U+2028 and U+2029. Fixes #34070 Fixes #30357 Updates #5836 Change-Id: Icfce7691d2b8b1d9b05ba7b64d2d1e4f3b67871b GitHub-Last-Rev: 38859fe3e2fd586bbd45175c2742f7b123836bf3 GitHub-Pull-Request: golang/go#34804 Reviewed-on: https://go-review.googlesource.com/c/go/+/200217Reviewed-by:
-
- 09 Oct, 2019 5 commits
-
-
Jay Conrod authored
When in module mode outside of any module, 'go build' and most other commands will now report an error instead of resolving a package path to a module. Previously, most commands would attempt to find the latest version of a module providing the package. This could be very slow if many packages needed to be resolved this way. Since there is no go.mod file where module requirements can be saved, it's a repeatedly slow and confusing experience. After this change, 'go build' and other commands may still be used outside of a module on packages in std and source files (.go arguments) that only import packages in std. Listing any other package on the command line or importing a package outside std will cause an error. 'go get' is exempted from the new behavior, since it's expected that 'go get' resolves paths to modules at new versions. Updates #32027 Change-Id: Ia9d3a3b4ad738ca5423472e17818d62b96a2c959 Reviewed-on: https://go-review.googlesource.com/c/go/+/198778 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jay Conrod authored
Updates #34669 Change-Id: I8d0ee68885e804e131f42a512080486f9b25e9dd Reviewed-on: https://go-review.googlesource.com/c/go/+/199819 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jay Conrod authored
go/build.Import locates package dirctories using 'go list' when in module mode (finding, downloading, and extracting modules is complicated, so go/build does not handle it). Previously, Import used 'go list' if GO111MODULE was not explicitly off and a go.mod file was present (plus some other conditions). With this change, if GO111MODULE is "on", a go.mod file does not need to be present. Fixes #34669 Change-Id: I9e56871054d4b07c3fc04b6f14a5c8c8e9f3c333 Reviewed-on: https://go-review.googlesource.com/c/go/+/199818 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
This is part two if the nacl removal. Part 1 was CL 199499. This CL removes amd64p32 support, which might be useful in the future if we implement the x32 ABI. It also removes the nacl bits in the toolchain, and some remaining nacl bits. Updates #30439 Change-Id: I2475d5bb066d1b474e00e40d95b520e7c2e286e1 Reviewed-on: https://go-review.googlesource.com/c/go/+/200077Reviewed-by:
-
Ainar Garipov authored
Some code tags in the HTML were not properly closed. Close them so that the text is rendered correctly. Change-Id: I5c2170ffced313417f65004d53518128c34f7979 Reviewed-on: https://go-review.googlesource.com/c/go/+/200117Reviewed-by:
-
