aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-02-06cmd/compile: ensure first instruction in a function is not inlinedKeith Randall
People are using this to get the name of the function from a function type: runtime.FuncForPC(reflect.ValueOf(fn).Pointer()).Name() Unfortunately, this technique falls down when the first instruction of the function is from an inlined callee. Then the expression above gets you the name of the inlined function instead of the function itself. To fix this, ensure that the first instruction is never from an inlinee. Normally functions have prologs so those are already fine. In just the cases where a function is a leaf with no local variables, and an instruction from an inlinee appears first in the prog list, add a nop at the start of the function to hold a non-inlined position. Consider the nop a "mini-prolog" for leaf functions. Fixes #58300 Change-Id: Ie37092f4ac3167fe8e5ef4a2207b14abc1786897 Reviewed-on: https://go-review.googlesource.com/c/go/+/465076 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-06cmd/internal/obj: flag init functions in object fileThan McIntosh
Introduce a flag in the object file indicating whether a given function corresponds to a compiler-generated (not user-written) init function, such as "os.init" or "syscall.init". Add code to the compiler to fill in the correct value for the flag, and add support to the loader package in the linker for testing the flag. The new loader API is currently unused, but will be needed in the next CL in this stack. Updates #2559. Updates #36021. Updates #14840. Change-Id: Iea7ad2adda487e4af7a44f062f9817977c53b394 Reviewed-on: https://go-review.googlesource.com/c/go/+/463855 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-06go/types, types2: eliminate need to sort arguments for type inferenceRobert Griesemer
When unifying types, we always consider underlying types if inference would fail otherwise. If a type parameter has a (non-defined) type inferred and later matches against a defined type, make sure to keep that defined type instead. For #43056. Change-Id: I24e4cd2939df7c8069e505be10914017c1c1c288 Reviewed-on: https://go-review.googlesource.com/c/go/+/464348 Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com>
2023-02-06log: fix and cleanup trailing newline logicJoe Tsai
The intent was to always append a newline if a newline was missing. The older logic accidentally only checked the payload for newlines and forgot to check the prefix as well. Fix it to check both together. This changes the output of Logger.Output in the situation where the prefix contains a trailing newline and the output is empty. This is a very rare combination and unlikely to occur in practice. Change-Id: Ic04ded6c29a90383e29bf7f59223a808ee1cbdc0 Reviewed-on: https://go-review.googlesource.com/c/go/+/465316 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
2023-02-06crypto/sha1: use math/bits.RotateLeft32Alexander Yastrebov
Updates #31456 Change-Id: I68e0abfb6771c9b1d1bfcbb642db9eb5540f9cab GitHub-Last-Rev: 17ea697c5c0bbfdfb1ad91c2c60e22f6efc78b43 GitHub-Pull-Request: golang/go#49051 Reviewed-on: https://go-review.googlesource.com/c/go/+/356516 Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2023-02-06cmd/compile: replace os.MkdirTemp with T.TempDirOleksandr Redko
Updates #45402 Change-Id: Ieffd1c8b0b5e4e63024b5be2e1f910fb4411eb94 GitHub-Last-Rev: fa7418c8eb977b7214311e774f9df7a1220a3dfd GitHub-Pull-Request: golang/go#57940 Reviewed-on: https://go-review.googlesource.com/c/go/+/462896 Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org>
2023-02-06math/big: add warning about using Int for cryptographyFilippo Valsorda
Change-Id: I31bec5d2b4a79a085942c7d380678379d99cf07b Reviewed-on: https://go-review.googlesource.com/c/go/+/455135 Auto-Submit: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
2023-02-06crypto/rand: replace shift with constantJohan Brandhorst-Satzkorn
It was mentioned after CL 463993 was merged that it is uncommon to use shifts for numbers other than powers of ten. Replace the shift with a base 10 constant. Change-Id: I11c90128740109a59add40ed7b680f7bcc9715ad Reviewed-on: https://go-review.googlesource.com/c/go/+/465275 Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Auto-Submit: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-06cmd/asm: add RDTIME{L,H}.W, RDTIME.D support for loong64Guoqi Chen
Instruction formats: rdtime rd, rj The RDTIME family of instructions are used to read constant frequency timer information, the stable counter value is written into the general register rd, and the counter id information is written into the general register rj. (Note: both of its register operands are outputs). Ref: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html Change-Id: Ida5bbb28316ef70b5f616dac3e6fa6f2e77875b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/421655 Reviewed-by: xiaodong liu <teaofmoli@gmail.com> Reviewed-by: WANG Xuerui <git@xen0n.name> Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Meidan Li <limeidan@loongson.cn>
2023-02-06cmd/compile: add rules to emit SETBC/R instructions on power10Archana R
This CL adds rules that replaces instances of ISEL that produce a boolean result based on a condition register by SETBC/SETBCR operations. On Power10 these are convereted to SETBC/SETBCR instructions that use one register instead of 3 registers conventionally used by ISEL and hence reduces register pressure. On loops written specifically to exercise such instances of ISEL extensively, a performance improvement of 2.5% is seen on Power10. Also added verification tests to verify correct generation of SETBC/SETBCR instructions on Power10. Change-Id: Ib719897f09d893de40324440a43052dca026e8fa Reviewed-on: https://go-review.googlesource.com/c/go/+/449795 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Archana Ravindar <aravind5@in.ibm.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-06all: upgrade Unicode from 13.0.0 to 15.0.0weebney
Update unicode/tables.go to reflect changes in the Unicode Standard up to Unicode 15.0.0, released 13 Sept 2022. In order to accommodate this update, strconv/isPrint has been updated to reflect changes in printable characters. Also changed is template/exec_test.go for both text and html packages- in the test "TestJSEscaping", rune U+FDFF was used as a placeholder for an unprintable character. This codepoint was assigned and made printable in Unicode 14.0.0, breaking this test. It has been replaced with the assigned and never-printable U+FFFE to fix the test and provide resiliency in the future. This upgrade bypasses Unicode 14.0.0, but is compatible. Updates https://github.com/golang/go/issues/48621 Fixes https://github.com/golang/go/issues/55079 Change-Id: I40efd097eb746db0727ebf7437280916d1242e47 GitHub-Last-Rev: c8885cab7a0c23632e1e5a433b1e8d5634a45a30 GitHub-Pull-Request: golang/go#57265 Reviewed-on: https://go-review.googlesource.com/c/go/+/456837 Reviewed-by: Robert Griesemer <gri@google.com> Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Rob Pike <r@golang.org>
2023-02-04log: make use of fmt.Append functionalityJoe Tsai
Since log is already responsible for managing its own buffers it is unfortunate that it calls fmt.Sprintf, which allocates, only to append that intermediate string to another buffer. Instead, use the new fmt.Append variants and avoid the allocation. We modify Logger.Output to wrap an internal Logger.output, which can be configured to use a particular append function. Logger.output is called from all the other functionality instead. This has the further advantage of simplifying the isDiscard check, which occurs to avoid the costly fmt.Print call. We coalesce all 6 checks as just 1 check in Logger.output. Also, swap the declaration order of Logger.Print and Logger.Printf to match the ordering elsewhere in the file. Performance: name old time/op new time/op delta Println 188ns ± 2% 172ns ± 4% -8.39% (p=0.000 n=10+10) PrintlnNoFlags 139ns ± 1% 116ns ± 1% -16.71% (p=0.000 n=9+9) name old allocs/op new allocs/op delta Println 1.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10) PrintlnNoFlags 1.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10) Change-Id: I79d0ee404df848beb3626fe863ccc73a3e2eb325 Reviewed-on: https://go-review.googlesource.com/c/go/+/464345 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Joseph Tsai <joetsai@digital-static.net> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-04cmd/compile: use ONAME node directly from generated hash funcCuong Manh Le
Same as CL 436436, but for hashfor. However, this passes toolstash-check, because the order of compiling functions do not change. Change-Id: Icc7d042e9c28b0fe4bb40a2b98b7f60cf3549bd1 Reviewed-on: https://go-review.googlesource.com/c/go/+/436961 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-02-04cmd/compile: factor out code to generate hash funcCuong Manh Le
Passes toolstash-check. Change-Id: I86a078ffc5948cbcbec84ce8012f3dfb1c2269b2 Reviewed-on: https://go-review.googlesource.com/c/go/+/436960 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2023-02-04cmd/compile: use runtime hash func for known typesCuong Manh Le
Those functions are defined in package runtime already, so just use them instead of creating ONAME nodes with nil Func. Change-Id: If29814a5254793c578c15b70f9c194b7414911d4 Reviewed-on: https://go-review.googlesource.com/c/go/+/436959 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2023-02-04cmd/compile: use memhash from package runtimeCuong Manh Le
Simplify the code, and prevent creating ONAME node with nil Func. Passes toolstash-check. Change-Id: I5e5be660510dc0ef5521d278c6b9214a80b994eb Reviewed-on: https://go-review.googlesource.com/c/go/+/436958 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2023-02-04cmd/compile: generate type equal func during walkCuong Manh Le
So we don't generate ONAME node with nil Func. Do not pass toolstash-check because the CL changes the order of compiling functions. Change-Id: Ib967328f36b8c59a5525445667103c0c80ccdc82 Reviewed-on: https://go-review.googlesource.com/c/go/+/436436 Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-02-04cmd/compile: factor out code to generate equal funcCuong Manh Le
So next CL can use it for generating equal func during walk compare. Passes toolstash-check. Change-Id: I76545c1d471eb496be352908db1b05feae83fc33 Reviewed-on: https://go-review.googlesource.com/c/go/+/436435 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2023-02-04net/http/httputil: fix syntax in ReverseProxy example commentEthan Lowman
Change-Id: I7e71626246af94047fbd1abb9bb77f2cd9b281fb Reviewed-on: https://go-review.googlesource.com/c/go/+/465195 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com>
2023-02-04time: add /etc/zoneinfo as valid path for tzdata for NixOSDavid Anderson
NixOS has no /usr/share, but does have tzdata at /etc/zoneinfo. Change-Id: Ic7d7f42a215e06c2e4f5c54ee11db82240f27167 GitHub-Last-Rev: 9969dd3e2cc49b30c3cd6b0858cb60b00bcbdf60 GitHub-Pull-Request: golang/go#58267 Reviewed-on: https://go-review.googlesource.com/c/go/+/464995 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2023-02-03context: remove one allocation in timerCtxCarlo Alberto Ferraris
Embed the cancelCtx into timerCtx, instead of allocating both separately. name old time/op new time/op delta WithTimeout/concurrency=40-16 2.21µs ±11% 2.08µs ± 5% -5.76% (p=0.011 n=10+10) WithTimeout/concurrency=4000-16 1.94µs ± 6% 1.86µs ±10% ~ (p=0.099 n=9+10) WithTimeout/concurrency=400000-16 1.86µs ± 7% 1.83µs ±10% ~ (p=0.353 n=10+10) name old alloc/op new alloc/op delta WithTimeout/concurrency=40-16 2.56kB ± 0% 2.40kB ± 0% -6.25% (p=0.001 n=8+9) WithTimeout/concurrency=4000-16 2.56kB ± 0% 2.40kB ± 0% -6.25% (p=0.000 n=9+10) WithTimeout/concurrency=400000-16 2.56kB ± 0% 2.40kB ± 0% -6.26% (p=0.000 n=9+9) name old allocs/op new allocs/op delta WithTimeout/concurrency=40-16 50.0 ± 0% 40.0 ± 0% -20.00% (p=0.000 n=10+10) WithTimeout/concurrency=4000-16 50.0 ± 0% 40.0 ± 0% -20.00% (p=0.000 n=10+10) WithTimeout/concurrency=400000-16 50.0 ± 0% 40.0 ± 0% -20.00% (p=0.000 n=10+10) Change-Id: Ia0460db3b8412fbaa6f1539fd6b4fb1b873896c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/463999 Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
2023-02-03log: reduce lock contentionJoe Tsai
Logger.Log methods are called in a highly concurrent manner in many servers. Acquiring a lock in each method call results in high lock contention, especially since each lock covers a non-trivial amount of work (e.g., formatting the header and outputting to the writer). Changes made: * Modify the Logger to use atomics so that the header formatting can be moved out of the critical lock section. Acquiring the flags does not occur in the same critical section as outputting to the underlying writer, so this introduces a very slight consistency instability where concurrently calling multiple Logger.Output along with Logger.SetFlags may cause the older flags to be used by some ongoing Logger.Output calls even after Logger.SetFlags has returned. * Use a sync.Pool to buffer the intermediate buffer. This approach is identical to how fmt does it, with the same max cap mitigation for #23199. * Only protect outputting to the underlying writer with a lock to ensure serialized ordering of output. Performance: name old time/op new time/op delta Concurrent-24 19.9µs ± 2% 8.3µs ± 1% -58.37% (p=0.000 n=10+10) Updates #19438 Change-Id: I091beb7431d8661976a6c01cdb0d145e37fe3d22 Reviewed-on: https://go-review.googlesource.com/c/go/+/464344 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
2023-02-03cmd/compile: intrinsify math/bits/ReverseBytes{16|32|64} for ppc64/power10Archana R
This change intrinsifies ReverseBytes{16|32|64} by generating the corresponding new instructions in Power10: brh, brd and brw and adds a verification test for the same. On Power 9 and 8, the .go code performs optimally as it is. Performance improvement seen on Power10: ReverseBytes32 1.38ns ± 0% 1.18ns ± 0% -14.2 ReverseBytes64 1.52ns ± 0% 1.11ns ± 0% -26.87 ReverseBytes16 1.41ns ± 1% 1.18ns ± 0% -16.47 Change-Id: I88f127f3ab9ba24a772becc21ad90acfba324b37 Reviewed-on: https://go-review.googlesource.com/c/go/+/446675 Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2023-02-03maps: new packageIan Lance Taylor
This copies x/exp/maps into the standard library (except for the Clear function which is now available as the clear builtin.) Fixes #57436 Change-Id: I30dd470c2f7ae34c7c82b4c1025a7582d61fabaa Reviewed-on: https://go-review.googlesource.com/c/go/+/464343 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Eli Bendersky <eliben@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
2023-02-03cmd/dist: do not include runtime/internal/sys in cmd staleness checksBryan C. Mills
Since CL 454836, cmd/dist has built the packages in 'cmd' with different settings than those in 'std': namely, for' cmd' we disable the use of cgo, and (since CL 463740) if GO_BUILDER_NAME is non-empty or the VERSION file indicates a release version we also set GOFLAGS=-trimpath. However, since at least CL 73212 the staleness checks performed by cmd/dist for the “toolchain” targets (a subset of 'cmd') have included the package "runtime/internal/sys" (which is in 'std', not 'cmd'). At that time, cmd/go did not have a separate build cache, so it would not have been possible to check staleness for a 'cmd' build differently from 'std'. However, now that is possible, and most of the time "runtime/internal/sys" lives *only* in the build cache (and so is essentially never stale after building anything that imports it). But there is one more wrinkle: if GODEBUG=installgoroot=all is set, the packages in 'std' are still installed to GOROOT/pkg, and can once again become stale. Since the install with the 'std' configuration does not match the configuration used to build 'cmd', the staleness check fails for "runtime/internal/sys" under the 'cmd' configuration. Since we intentionally build the toolchain with a different "runtime/internal/sys" stored only in the build cache, there is no longer a point in checking that package for staleness: if it is stale, then the toolchain itself will be reported as stale anyway. So we can simply remove the package from that staleness check, and unbreak bootstrapping with GODEBUG=installgoroot=all. I tested this manually using the sequence: export GODEBUG=installgoroot=all export GO_BUILDER_NAME=linux-amd64-bcmills ./make.bash It fails the staleness check before this change, and successfully builds after. For #24904. Change-Id: I376e93e35129694a093c6675e20905a097a8b64b Reviewed-on: https://go-review.googlesource.com/c/go/+/465155 Reviewed-by: Russ Cox <rsc@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com>
2023-02-03cmd/go/internal/par: use generic CacheRoger Peppe
Using generics here makes the code easier to understand, as the contract is clearly specified. It also makes the code a little more concise, as it's easy to write a wrapper for the cache that adds an error value, meaning that a bunch of auxilliary types no longer need to be defined for this common case. The load.cachingRepo code has been changed to use a separate cache for each key-value type combination, which seems a bit less sleazy, but might have some knock-on effect on memory usage, and could easily be changed back if desired. Because there's no longer an unambiguous way to find out whether there's an entry in the cache, the Cache.Get method now returns a bool as well as the value itself. Change-Id: I28443125bab0b3720cc95d750e72d28e9b96257d Reviewed-on: https://go-review.googlesource.com/c/go/+/463843 Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: roger peppe <rogpeppe@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2023-02-03debug/elf: add DT_FLAGS_1 constantsFlorin Papa
Add constants for all ELF dynamic flags (pertaining to DT_FLAGS_1). This will help, for example, determining whether an object is a position-independent executable (PIE). The constants are defined according to Table 15-10 in https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/linkers-libraries/dynamic-section.html. Fixes #56887 Change-Id: I6cd501af50d9dbcc2aa8a9a002e12c6fb6726761 Reviewed-on: https://go-review.googlesource.com/c/go/+/452496 Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-02go/types, types2: enable new type inferenceRobert Griesemer
Enable new type inference and compare result with old inference implementation - the result must be identical in a correct program. Change-Id: Ic802d29fcee744f6f826d5e433a3d0c0e73b68e3 Reviewed-on: https://go-review.googlesource.com/c/go/+/464341 Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
2023-02-02go/types, types2: implement simpler type inference (infer2)Robert Griesemer
This change implements infer2 which is a drop-in replacement for infer; it can be enabled by setting the useNewTypeInference flag in infer2.go. It is currently disabled (but tested manually). infer2 uses the same machinery like infer but in a simpler approach that is more amenable to precise description and future extensions. The goal of type inference is to determine a set of (missing) type arguments from a set of other given facts. Currently, these other facts are function arguments and type constraints. In the following, when we refer to "type parameters", we mean the type parameters defined by the generic function to which we apply type inference. More precisely, in the algorithm, these are the type parameters recorded with the unifier. The approach is as follows: - A single unifier is set up which tracks all type parameters and corresponding inferred types. - The unifier is then fed all the facts we have. The order is not relevant (*) except that we use default types of untyped constant arguments only as a last resort, at the end. - We start with all function arguments: for each generic function parameter with a typed function argument, we unify the parameter and function type. - We then unify each type parameter with its type constraint. This step is iterated until nothing changes anymore, because each unification may enable further unification. - If there are any type parameters left without inferred types, and which are used as function parameters with untyped constant arguments, unify them with the default types of those arguments. Because of unification with constraints which themselves may contain type parameters, inferred types may contain type parameters. Thus, in a final step we substitute type parameters for their inferred types until there are no type parameters left in the inferred types. All these individual steps are the same as in infer, but there is no need to do constraint type inference twice (all the facts have already been used for inference). Also, we only need a single unifier which serves as the holder for the inferred type parameter types. Type inference fails if any unification step fails or if not all type arguments could be inferred. By always using all available facts (**) we ensure that order doesn't matter. By using more facts, type inference can now be extended to become more powerful. The code can be split up into smaller components that are more easily digestable. Because we forsee more simplifications, we defer such cleanups to later CLs. (*) We currently have a sorting phase in the beginning such that function argument types that are named types are used before any other type. We believe this step can be eliminated by modifying the unifier slightly. (**) When unifying constraints, in some cases we don't report an error if unification fails. We believe we can modify the unifier and then consistently report an inference failure in this case as well. Change-Id: If1640a5461bc102fa7fd31dc6e741be667c97e7f Reviewed-on: https://go-review.googlesource.com/c/go/+/463746 Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-02go/types, types2: simplify symmetric codeRobert Griesemer
Because unification is symmetric, in cases where we have symmetric code for x and y depending on some property we can swap x and y as needed and simplify the code. Also, change u.depth increment/decrement position for slightly nicer tracing ooutput. Change-Id: I2e84570d463d1c32f6556108f3cb54062b57c718 Reviewed-on: https://go-review.googlesource.com/c/go/+/464896 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
2023-02-02go/types, types2: use a comparer struct to control the identical predicateRobert Griesemer
This makes it easier to configure the behavior of identical: we can simply add fields to the comparer instead of adding more parameters to identical. Change-Id: I9a6f5451b3ee5c37e71486060653c5a6e8f24304 Reviewed-on: https://go-review.googlesource.com/c/go/+/464937 Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
2023-02-02cmd/go/internal/test: scale the WaitDelay for test subprocessesBryan C. Mills
Prior to CL 456116 we had an arbitrary 5-second delay after a test times out before we kill the test. In CL 456116, I reused that arbitrary 5-second delay as the WaitDelay as well, but on slower builders it does not seem to be generous enough. Instead of hard-coding the delay, for tests with a finite timout we now use a hard-coded fraction of the overall timeout. That will probably give delays that are longer than strictly necessary for very long timeouts, but if the user is willing to wait for a very long timeout they can probably wait a little longer for I/O too. Fixes #58230. Updates #24050. Change-Id: Ifbf3e576c034c721aa00cd17bf88563474b09955 Reviewed-on: https://go-review.googlesource.com/c/go/+/464555 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com>
2023-02-02runtime: eliminate arbitrary timeout in TestCgoLockOSThreadExitBryan C. Mills
This test previously failed if running a new pthread took longer than a hard-coded 100ms. On some slow or heavily-loaded builders, that scheduling latency is too short. Since the point of this test is to verify that the background thread is not reused after it terminates (see #20395), the arbitrary time limit does not seem helpful: if the background thread fails to terminate the test will time out on its own, and if the main goroutine is scheduled on the background thread the test will fail regardless of how long it takes. Fixes #58247. Change-Id: I626af52aac55af7a4c0e7829798573c479750c20 Reviewed-on: https://go-review.googlesource.com/c/go/+/464735 Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-02math/big: add Int.Float64 conversionAlan Donovan
This operation converts a big.Int to float64, reporting the accuracy of the result, with a fast path in hardware. Fixes #56984 Change-Id: I86d0fb0e105a06a4009986f2f5fd87a4d446f6f9 Reviewed-on: https://go-review.googlesource.com/c/go/+/453115 Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Alan Donovan <adonovan@google.com>
2023-02-02internal/testenv: avoid rebuilding all of std in WriteImportcfgBryan C. Mills
Instead, have the caller pass in an explicit list of the packages (if any) they need. After #47257, a builder running a test does not necessarily have the entire standard library already cached, especially when running tests in sharded mode. testenv.WriteImportcfg used to write an importcfg for the entire standard library — which required rebuilding the entire standard library — even though most tests need only a tiny subset. This reduces the time to test internal/abi with a cold build cache on my workstation from ~16s to ~0.05s. It somewhat increases the time for 'go test go/internal/gcimporter' with a cold cache, from ~43s to ~54s, presumably due to decreased parallelism in rebuilding the standard library and increased overhead in re-resolving the import map. However, 'go test -short' running time remains stable (~5.5s before and after). Fixes #58248. Change-Id: I9be6b61ae6e28b75b53af85207c281bb93b9346f Reviewed-on: https://go-review.googlesource.com/c/go/+/464736 Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com>
2023-02-02go/token: add (*File).Lines methodAlan Donovan
This method returns the array updated by SetLines, for use in exporter packages. Fixes #57708 Change-Id: I12ed5e7e1bae7517f40cb25e76e51997c25d84f4 Reviewed-on: https://go-review.googlesource.com/c/go/+/464515 Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Alan Donovan <adonovan@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Alan Donovan <adonovan@google.com>
2023-02-02src/cmd/compile: clarify //go:linkname documentationAlan Donovan
Change-Id: I0407950bfc84082683012944b2051e46dc682ba0 Reviewed-on: https://go-review.googlesource.com/c/go/+/463136 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Alan Donovan <adonovan@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-02-02net/netip: fix invalid representation of PrefixJoe Tsai
For a given Addr, ensure there is exactly one invalid representation. This allows invalid representations to be safely comparable. To ensure that the zero value of Prefix is invalid, we modify the encoding of bits to simply be the bit count plus one. Since Addr is immutable, we check in the PrefixFrom constructor that the provided Addr is valid and only store a non-zero bits length if so. IsValid is simplified to just checking whether bitsPlusOne is non-zero. Fixes #54525 Change-Id: I9244cae2fd160cc9c81d007866992df2e422d3b9 Reviewed-on: https://go-review.googlesource.com/c/go/+/425035 Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
2023-02-02misc: increase node stack sizeJohan Brandhorst-Satzkorn
The default NodeJS V8 stack size is 984K, which is not enough to run the regexp or go/parser tests. This commit increases the stack size to 8192K, which removes the stack size limit error. Fixes #56498 Fixes #57614 Change-Id: I357885d420daf259187403deab25ff587defa0fc Reviewed-on: https://go-review.googlesource.com/c/go/+/463994 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Julien Fabre <ju.pryz@gmail.com> Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-02internal/poll: use atomic.Bool in DupCloseOnExecTobias Klauser
Invert the meaning of the var to make use of the zero value. Change-Id: If18db09896a67cb37cb3fe7dc0fb3493c6050a87 Reviewed-on: https://go-review.googlesource.com/c/go/+/463847 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2023-02-02cmd/link: remove special cases for relocations in .go.buildinfoRuss Cox
.go.buildinfo has no relocations anymore, as of Go 1.18. Change-Id: I98369c6a0ef07ada770eaa12f6f56c210e812abc Reviewed-on: https://go-review.googlesource.com/c/go/+/464436 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-02-02cmd/link: keep go.buildinfo even with --gc-sectionsRuss Cox
If you use an external linker with --gc-sections, nothing refers to .go.buildinfo, so the section is deleted, which in turns makes 'go version' fail on the binary. It is important for vulnerability scanning and the like to be able to run 'go version' on any binary. Fix this by inserting a reference to .go.buildinfo from the rodata section, which will not be GC'ed. Fixes #58222. Change-Id: I1e13e9464acaf2f5cc5e0b70476fa52b43651123 Reviewed-on: https://go-review.googlesource.com/c/go/+/464435 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Auto-Submit: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-02go/types, types2: avoid recursive invocation when unifying underlying typesRobert Griesemer
There's no need to invoke unifier.nify recursively when we decide to unify underlying types. Just update the respective type variable and continue. Change-Id: I3abe335464786dc509d18651dff14b20022c7d63 Reviewed-on: https://go-review.googlesource.com/c/go/+/464347 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Robert Griesemer <gri@google.com>
2023-02-02go/types, types2: remove (internal) exactUnification flagRobert Griesemer
Neither infer nor infer2 will correctly work if we require exact unification. Remove the flag and simplify the respective code. Change-Id: I329f207f72b6d97fa076f27275481b754e55fecf Reviewed-on: https://go-review.googlesource.com/c/go/+/464346 Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-01cmd/compile/internal/types: remove misleading commentMatthew Dempsky
The runtime's knowledge of these constants was removed in CL 261364. Change-Id: I65e5a5ab084c6301eee1c9791bc76df9b824e466 Reviewed-on: https://go-review.googlesource.com/c/go/+/463754 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-01go/types, types2: use go.dev/issue/nnnnn when referring to an issue (cleanup)Robert Griesemer
Follow-up on CL 462856 which missed a few places. Fixed manually. Change-Id: I924560ecae8923d9228027016805a3cc892f8ac2 Reviewed-on: https://go-review.googlesource.com/c/go/+/463749 Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com>
2023-02-01go/types, types2: better error when trying to use ~ as bitwise operationRobert Griesemer
When coming from C, the bitwise integer complement (bitwise negation) operator is ~, but in Go it is ^. Report an error mentioning ^ when ~ is used with an integer operand. Background: Some articles on the web claim that Go doesn't have a bitwise complement operator. Change-Id: I41185cae4a70d528754e44f42c13c013ed91bf27 Reviewed-on: https://go-review.googlesource.com/c/go/+/463747 Auto-Submit: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-01go/types, types2: unifier constructor to accept type parameters and argumentsRobert Griesemer
Change-Id: I2f20cb8f1dd95ba97de7630d0bbe6dee4e019f94 Reviewed-on: https://go-review.googlesource.com/c/go/+/463990 Reviewed-by: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2023-02-01go/types, types2: further simplify unificationRobert Griesemer
Allocate all handles up-front: in a correct program, all type parameters must be resolved and thus eventually will get a handle. Also, sharing of handles caused by unified type parameters is rare and so it's ok to not optimize for that case (and delay handle allocation). This removes a (premature) optimization whis further simplifies unification. Change-Id: Ie1259b86ea5e966538667ab9557676e9be9f6364 Reviewed-on: https://go-review.googlesource.com/c/go/+/463989 Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-01go/types, types2: replace unifier type parameter list with a mapRobert Griesemer
Further simplify the unifier by using a mapping from type parameter to type (argument) handle, where a handle is just an indirection to the actual type associated with the type parameter. If multiple type parameters are "joined", i.e., share the same type (argument), then they use the same handle. Thus, if one of the type parameters gets a type, all type parameters sharing the same handle get the same type. The handles mapping replaces the indices list (mapping from type parameter index to types index). Because each handle holds any associated type directly, we also don't need a types list anymore. We still keep the incoming type parameter list to maintain the same order for printing and reporting inferred types. We may be able to eliminate this list as well in future CLs. Change-Id: I389527dbb325b828c91050e59902ae546c3d0347 Reviewed-on: https://go-review.googlesource.com/c/go/+/463228 Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>