Currently, when C calls into Go the first time, we grab an M
using needm, which sets m.g0's stack bounds using the SP. We don't
know how big the stack is, so we simply assume 32K. Previously,
when the Go function returns to C, we drop the M, and the next
time C calls into Go, we put a new stack bound on the g0 based on
the current SP. After CL 392854, we don't drop the M, and the next
time C calls into Go, we reuse the same g0, without recomputing
the stack bounds. If the C code uses quite a bit of stack space
before calling into Go, the SP may be well below the 32K stack
bound we assumed, so the runtime thinks the g0 stack overflows.
This CL makes needm get a more accurate stack bound from
pthread. (In some platforms this may still be a guess as we don't
know exactly where we are in the C stack), but it is probably
better than simply assuming 32K.
For #59294.
Change-Id: Ie52a8f931e0648d8753e4c1dbe45468b8748b527
Reviewed-on: https://go-review.googlesource.com/c/go/+/479915
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Mark the wasip1/wasm port as broken until it has been fully merged.
Change-Id: I58592b43c82513b079c561673de99b41c94b11c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/480655
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Introduce a new m.incgocallback field that is true while C code calls
into Go code. Use it in the tracer in order to fallback to the default
unwinder instead of frame pointer unwinding for this scenario. The
existing fields (incgo, ncgo) were not sufficient to detect the case
where a thread created in C calls into Go code.
Motivation:
1. Take advantage of a cgo symbolizer, if registered, to unwind through
C stacks without frame pointers.
2. Reduce the chance of crashes. It seems unsafe to follow frame
pointers when there could be C code that was compiled without frame
pointers.
Removing the curgp.m.incgocallback check in traceStackID shows the
following minor differences between frame pointer unwinding and the
default unwinder when there is no cgo symbolizer involved.
trace_test.go:60: "goCalledFromCThread": got stack:
main.goCalledFromCThread
/src/runtime/testdata/testprogcgo/trace.go:58
_cgoexp_45c15a3efb3a_goCalledFromCThread
_cgo_gotypes.go:694
runtime.cgocallbackg1
/src/runtime/cgocall.go:318
runtime.cgocallbackg
/src/runtime/cgocall.go:236
runtime.cgocallback
/src/runtime/asm_amd64.s:998
crosscall2
/src/runtime/cgo/asm_amd64.s:30
want stack:
main.goCalledFromCThread
/src/runtime/testdata/testprogcgo/trace.go:58
_cgoexp_45c15a3efb3a_goCalledFromCThread
_cgo_gotypes.go:694
runtime.cgocallbackg1
/src/runtime/cgocall.go:318
runtime.cgocallbackg
/src/runtime/cgocall.go:236
runtime.cgocallback
/src/runtime/asm_amd64.s:998
trace_test.go:60: "goCalledFromC": got stack:
main.goCalledFromC
/src/runtime/testdata/testprogcgo/trace.go:51
_cgoexp_45c15a3efb3a_goCalledFromC
_cgo_gotypes.go:687
runtime.cgocallbackg1
/src/runtime/cgocall.go:318
runtime.cgocallbackg
/src/runtime/cgocall.go:236
runtime.cgocallback
/src/runtime/asm_amd64.s:998
crosscall2
/src/runtime/cgo/asm_amd64.s:30
runtime.asmcgocall
/src/runtime/asm_amd64.s:848
main._Cfunc_cCalledFromGo
_cgo_gotypes.go:263
main.goCalledFromGo
/src/runtime/testdata/testprogcgo/trace.go:46
main.Trace
/src/runtime/testdata/testprogcgo/trace.go:37
main.main
/src/runtime/testdata/testprogcgo/main.go:34
want stack:
main.goCalledFromC
/src/runtime/testdata/testprogcgo/trace.go:51
_cgoexp_45c15a3efb3a_goCalledFromC
_cgo_gotypes.go:687
runtime.cgocallbackg1
/src/runtime/cgocall.go:318
runtime.cgocallbackg
/src/runtime/cgocall.go:236
runtime.cgocallback
/src/runtime/asm_amd64.s:998
runtime.systemstack_switch
/src/runtime/asm_amd64.s:463
runtime.cgocall
/src/runtime/cgocall.go:168
main._Cfunc_cCalledFromGo
_cgo_gotypes.go:263
main.goCalledFromGo
/src/runtime/testdata/testprogcgo/trace.go:46
main.Trace
/src/runtime/testdata/testprogcgo/trace.go:37
main.main
/src/runtime/testdata/testprogcgo/main.go:34
For #16638
Change-Id: I95fa27a3170c5abd923afc6eadab4eae777ced31
Reviewed-on: https://go-review.googlesource.com/c/go/+/474916
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Change tracer to use frame pointer unwinding by default on amd64. The
expansion of inline frames is delayed until the stack table is dumped at
the end of the trace. This requires storing the skip argument in the
stack table, which now resides in pcBuf[0]. For stacks that are not
produced by traceStackID (e.g. CPU samples), a logicalStackSentinel
value in pcBuf[0] indicates that no inline expansion is needed.
Add new GODEBUG=tracefpunwindoff=1 option to use the old unwinder if
needed.
Benchmarks show a considerable decrease in CPU overhead when using frame
pointer unwinding for trace events:
GODEBUG=tracefpunwindoff=1 ../bin/go test -run '^$' -bench '.+PingPong' -count 20 -v -trace /dev/null ./runtime | tee tracefpunwindoff1.txt
GODEBUG=tracefpunwindoff=0 ../bin/go test -run '^$' -bench '.+PingPong' -count 20 -v -trace /dev/null ./runtime | tee tracefpunwindoff0.txt
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz
│ tracefpunwindoff1.txt │ tracefpunwindoff0.txt │
│ sec/op │ sec/op vs base │
PingPongHog-32 3782.5n ± 0% 740.7n ± 2% -80.42% (p=0.000 n=20)
For #16638
Change-Id: I2928a2fcd8779a31c45ce0f2fbcc0179641190bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/463835
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This commit addresses a regression caused by commit
43f911b0b6 (CL 472195) which led to frame
pointer cycles, causing frame pointer unwinders (refer to CL 463835) to
encounter repetitive stack frames.
The issue occurs when mcall invokes fn on g0's stack. fn is expected not
to return but to continue g's execution through gogo(&g.sched). To
achieve this, g.sched must hold the sp, pc, and bp of mcall's caller. CL
472195 mistakenly altered g.sched.bp to store mcall's own bp, causing
gogo to resume execution with a bp value that points downwards into the
now non-existent mcall frame. This results in the next function call
executed by mcall's callee pushing a bp that points to itself on the
stack, creating a pointer loop.
Fix this by dereferencing bp before storing it in g.sched.bp to
reinstate the correct behavior. Although this problem could potentially
be resolved by reverting the mcall-related changes from CL 472195, doing
so would hide mcall's caller frame from async frame pointer unwinders
like Linux perf when unwinding during fn's execution.
Currently, there is no test coverage for frame pointers to validate
these changes. However, runtime/trace.TestTraceSymbolize at CL 463835
will add basic test coverage and can be used to validate this change.
Change-Id: Iad3c42908eeb1b0009fcb839d7fcfffe53d13326
Reviewed-on: https://go-review.googlesource.com/c/go/+/476235
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
The go:wasmimport compiler directive is used by the wasi port
to access host APIs, some of need to implemented in the syscall
package.
Co-authored-by: Richard Musiol <neelance@gmail.com>
Co-authored-by: Achille Roussel <achille.roussel@gmail.com>
Co-authored-by: Julien Fabre <ju.pryz@gmail.com>
Co-authored-by: Evan Phoenix <evan@phx.io>
Change-Id: I3851e154c6989094effcd25bba5864faa133564e
Reviewed-on: https://go-review.googlesource.com/c/go/+/479615
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
The comment justifies exporting GOROOT by saying the api test needs it,
which was relevant back when it was added in CL 99870043, but isn't true
by now.
As of Go 1.8, GOPATH can be unset (https://go.dev/doc/go1.8#gopath).
At some point it also became okay to leave GOROOT unset, at least
whenever one is looking to use the default GOROOT tree of the go command
being executed and not intentionally changing it to a custom directory.
It's also not there in the .bat and .rc variants of this script.
Drop it.
Change-Id: Ibcb386c560523fcfbfec8020f90692dcfa5aa686
Reviewed-on: https://go-review.googlesource.com/c/go/+/480376
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
This adds a simple test validating MPTCP Sock for Linux implementation:
- A Listener is created with MPTCP support, accepting new connections in
a new thread.
- A Dialer with MPTCP support connects to this new Listener
- On both sides, MPTCP should be used. Note that at this point, we
cannot check if a fallback to TCP has been done nor if the correct
protocol is being used.
Technically, a localServer from mockserver_test.go is used, similar to
TestIPv6LinkLocalUnicastTCP from tcpsock_test.go. Here with MPTCP, the
Listen step is done manually to force using MPTCP and a post step is
done to verify extra status after the Accept. More checks are going to
be done in the future.
Please note that the test is skipped if the kernel doesn't allow the
creation of an MPTCP socket at all when starting the test.
The test can be executed with this command:
$ ../bin/go test -v net -run "^TestMultiPathTCP$"
The "-race" option has also been checked.
This work has been co-developped by Benjamin Hesmans
<benjamin.hesmans@tessares.net> and Gregory Detal
<gregory.detal@tessares.net>.
Fixes#56539
Change-Id: I4b6b39e9175a20f98497b5ea56934e242da06194
Reviewed-on: https://go-review.googlesource.com/c/go/+/471141
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Specific MPTCP errors could happen but only one is detectable: if
ENOPROTOOPT errno is returned, it likely means MPTCP has been disable
via this sysctl knob: net.mptcp.enabled.
But because MPTCP could be blocked by the administrator using different
techniques (SELinux, etc.) making the socket creation returning other
errors, it looks better to always retry to create a "plain" TCP socket
when any errors are returned.
This work has been co-developed by Gregory Detal
<gregory.detal@tessares.net>.
Updates #56539
Change-Id: I94fb8448dae351e1d3135b4f182570979c6b36d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/471138
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
fieldType is a struct with only a string and an integer,
so its size will barely be three times that of a pointer.
The indirection doesn't save us any memory or append/grow cost,
but it does cause a significant amount of allocations at init time.
goos: linux
goarch: amd64
pkg: encoding/gob
cpu: AMD Ryzen 7 PRO 5850U with Radeon Graphics
│ old │ new │
│ sec/op │ sec/op vs base │
EndToEndPipe-16 730.9n ± 5% 741.6n ± 5% ~ (p=0.529 n=10)
EncodingGob 173.7µ ± 0% 171.1µ ± 0% -1.46% (p=0.000 n=10)
geomean 11.27µ 11.26µ -0.01%
│ old │ new │
│ B/op │ B/op vs base │
EndToEndPipe-16 1.766Ki ± 0% 1.766Ki ± 0% ~ (p=1.000 n=10) ¹
EncodingGob 38.27Ki ± 0% 34.30Ki ± 0% -10.38% (p=0.000 n=10)
geomean 8.221Ki 7.782Ki -5.33%
¹ all samples are equal
│ old │ new │
│ allocs/op │ allocs/op vs base │
EndToEndPipe-16 2.000 ± 0% 2.000 ± 0% ~ (p=1.000 n=10) ¹
EncodingGob 642.0 ± 0% 615.0 ± 0% -4.21% (p=0.000 n=10)
geomean 35.83 35.07 -2.13%
¹ all samples are equal
Change-Id: I852a799834d2e9b7b915da74e871a4052d13892e
Reviewed-on: https://go-review.googlesource.com/c/go/+/479400
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
After the previous commit, both calls use the non-pointer type,
so we can deduplicate. No noticeable difference in init cost.
Change-Id: I0f0fb91d42655787cb58b4442ad3da4194560af4
Reviewed-on: https://go-review.googlesource.com/c/go/+/479399
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
wireType itself is just a struct with seven pointer fields,
so an indirection doesn't feel necessary to noticeably reduce the amount
of memory that typeInfo takes for each Go type registered in gob.
The indirection does add a small amount of overhead though,
particularly one extra allocation when registering a type,
which is done a number of times as part of init.
For consistency, also update wireTypeUserInfo to not use a pointer.
Measuring via one of the end-to-end benchmarks and benchinit:
goos: linux
goarch: amd64
pkg: encoding/gob
cpu: AMD Ryzen 7 PRO 5850U with Radeon Graphics
│ old │ new │
│ sec/op │ sec/op vs base │
EndToEndPipe-16 736.8n ± 5% 733.9n ± 5% ~ (p=0.971 n=10)
EncodingGob 177.6µ ± 0% 173.6µ ± 0% -2.27% (p=0.000 n=10)
geomean 11.44µ 11.29µ -1.34%
│ old │ new │
│ B/op │ B/op vs base │
EndToEndPipe-16 1.766Ki ± 0% 1.766Ki ± 0% ~ (p=1.000 n=10) ¹
EncodingGob 38.47Ki ± 0% 38.27Ki ± 0% -0.50% (p=0.000 n=10)
geomean 8.241Ki 8.220Ki -0.25%
¹ all samples are equal
│ old │ new │
│ allocs/op │ allocs/op vs base │
EndToEndPipe-16 2.000 ± 0% 2.000 ± 0% ~ (p=1.000 n=10) ¹
EncodingGob 652.0 ± 0% 642.0 ± 0% -1.53% (p=0.000 n=10)
geomean 36.11 35.83 -0.77%
¹ all samples are equal
Change-Id: I528080b7d990ed595683f155a1ae25dcd26394b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/479398
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The reflect method was added in Go 1.13, in 2019.
gob's own version dates all the way back to 2011.
The behavior appears to be the same, and all tests still pass.
gob does have special cases like always encoding arrays even when they
are the zero value, but that is done via the sendZero boolean field.
Change-Id: I9057b7436963e231fdbf2f6c4b1edb58a2b13305
Reviewed-on: https://go-review.googlesource.com/c/go/+/479397
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Doing this work at init time does make the first encode or decode call
slightly faster, but the cost is still paid upfront.
However, not all programs which directly or indirectly import
encoding/gob end up encoding or decoding any values.
For example, a program might only be run with the -help flag,
or it might only use gob encoding when a specific mode is enabled.
Moreover, any work done at init time needs to happen sequentially and
before the main function can start, blocking the entire program.
Using benchinit, we see a moderate saving at init time:
goos: linux
goarch: amd64
cpu: AMD Ryzen 7 PRO 5850U with Radeon Graphics
│ old │ new │
│ sec/op │ sec/op vs base │
EncodingGob 188.9µ ± 0% 175.4µ ± 0% -7.15% (p=0.000 n=10)
│ old │ new │
│ B/op │ B/op vs base │
EncodingGob 39.78Ki ± 0% 38.46Ki ± 0% -3.32% (p=0.000 n=10)
│ old │ new │
│ allocs/op │ allocs/op vs base │
EncodingGob 668.0 ± 0% 652.0 ± 0% -2.40% (p=0.000 n=10)
Change-Id: I75a5df18c9b1d02566e5885a966360d8a525913a
Reviewed-on: https://go-review.googlesource.com/c/go/+/479396
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
If a directory already exists, then MkdirAll returns nil. Therefore the
check with IsExist is not necessary.
Change-Id: Idf83c056f64bb56f49eb2b649af7827b759bcd7c
GitHub-Last-Rev: 1f29873d0c
GitHub-Pull-Request: golang/go#53242
Reviewed-on: https://go-review.googlesource.com/c/go/+/410434
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Prior to this change, there was a possibility that the call of ForgetUnshared at line 134 could acquire the lock first.
Then, after ForgetUnshared released the lock, the doCall function could acquire it and complete its call.
This change prevents this situation by ensuring that ForgetUnshared at line 134 only executes after doCall has finished executing and released the lock.
Change-Id: I45cd4040e40ed52ca8e1b3863092886668dfd521
Reviewed-on: https://go-review.googlesource.com/c/go/+/479499
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Similar to dialMPTCP, this listenMPTCP function is called when the user
has requested MPTCP via SetMultipathTCP in the ListenConfig.
This function falls back to listenTCP on operating systems that do not
support MPTCP or if MPTCP is not supported.
On ListenConfig side, MultipathTCP function can be used to know if the
package will try to use MPTCP or not when Listen is called.
Note that this new listenMPTCP function returns a TCPListener object and
not a new MPTCP dedicated one. The reasons are similar as the ones
explained in the parent commit introducing dialTCP: if MPTCP is used by
default later, Listen will return a different object that could break
existing applications expecting TCPListener.
This work has been co-developped by Gregory Detal
<gregory.detal@tessares.net>.
Updates #56539
Change-Id: I010f1d87f921bbac9e157cef2212c51917852353
Reviewed-on: https://go-review.googlesource.com/c/go/+/471137
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This function is called when the user has requested MPTCP via
SetMultipathTCP in the Dialer.
This new function falls back to dialTCP on operating systems that do not
support MPTCP or if MPTCP is not supported.
On Dialer side, MultipathTCP function can be used to know if the package
will try to use MPTCP or not when Dial is called.
Note that this new dialMPTCP function returns a TCPConn object, like
dialTCP. A new MPTCPConn object using the following composition could
have been returned:
type MPTCPConn struct {
*TCPConn
}
But the drawback is that if MPTCP is used by default one day (see #56539
issue on GitHub), Dial will return a different object: this new
MPTCPConn type instead of the previously expected TCPConn. This can
cause issues for apps checking the returned object.
This work has been co-developped by Gregory Detal
<gregory.detal@tessares.net>.
Updates #56539
Change-Id: I0f9b5b81f630b39142bdd553d4f1b4c775f1dff0
Reviewed-on: https://go-review.googlesource.com/c/go/+/471136
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
'go list -export' lists the locations of compiled artifacts,
so it needs to load all of the metadata needed to compile each package.
Fixes#58885.
Change-Id: Ie78527e0fb423698fb4195fe50e0b6925b05aa8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/477197
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
The docs in .github & CONTRIBUTING.md have three different links to the same place. I have picked the one from "10-proposal.md" as the canonical url as it uses the normal go website shortener service (thus centralizing any future maintenance of this location), uses the new public domain (go.dev over golang.org), and also picks up the readme URI fragment from the shortener redirect which allows the doc links to be cleaner, but also the convenience for the reader starting directly at the human readable parsed README.md.
Should also cut down on confusion like I had reading documentation about why there were multiple proposal sites, which turned out all to be the same place.
Update all proposal-process links to the same URL.
Change-Id: I2f2ea3a6ca34a445268285520e1b19570946afb8
GitHub-Last-Rev: eb769089e6
GitHub-Pull-Request: golang/go#59238
Reviewed-on: https://go-review.googlesource.com/c/go/+/479415
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This changes a few references to `+build` into the modern `//go:build`.
It was compiled by editing `cmd/go/internal/list/context.go`, running
`go test cmd/go -v -run=TestDocsUpToDate -fixdocs`, and then editing
list.go and build.go by hand.
Change-Id: I00fec55e098bf5100f5a186dd975a6628e15beb8
GitHub-Last-Rev: e0eb9be77e
GitHub-Pull-Request: golang/go#59245
Reviewed-on: https://go-review.googlesource.com/c/go/+/479417
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@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>
The cast is proceeded by a bounds check. If the bounds check passes
then we know the pointer in the slice is non-nil.
... except casts to pointers of 0-sized arrays. They are strange, as
the bounds check can pass for a nil input.
Change-Id: Ic01cf4a82d59fbe3071d4b271c94efca9cafaec1
Reviewed-on: https://go-review.googlesource.com/c/go/+/479335
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Per feedback from prior CL.
Change-Id: Icbf6149c3b61e26085caf6f368d22ad4f02c75fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/480316
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Checker.use is called to check expressions and "use" variables
in case of an error. Use Checker.exprOrType instead of just
rawExpr.
Change-Id: I4da6fa51ef3b0c9b07c453494452836caced9b1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/479897
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
This CL implements type inference for generic functions used in
assignments: variable init expressions, regular assignments, and
return statements, but (not yet) function arguments passed to
functions. For instance, given a generic function
func f[P any](x P)
and a variable of function type
var v func(x int)
the assignment
v = f
is valid w/o explicit instantiation of f, and the missing type
argument for f is inferred from the type of v. More generally,
the function f may have multiple type arguments, and it may be
partially instantiated.
This new form of inference is not enabled by default (it needs
to go through the proposal process first). It can be enabled
by setting Config.EnableReverseTypeInference.
The mechanism is implemented as follows:
- The various expression evaluation functions take an additional
(first) argument T, which is the target type for the expression.
If not nil, it is the type of the LHS in an assignment.
- The method Checker.funcInst is changed such that it uses both,
provided type arguments (if any), and a target type (if any)
to augment type inference.
Change-Id: Idfde61078e1ee4f22abcca894a4c84d681734ff6
Reviewed-on: https://go-review.googlesource.com/c/go/+/476075
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
json.Marshal doesn't do what one might hope on many Go error values.
Errors created with errors.New marshal as "{}". So JSONHandler treats
errors specially, calling the Error method instead of json.Marshal.
However, if the error happens to implement json.Marshaler, then
JSONHandler should call json.Marshal after all. This CL makes
that change.
Change-Id: I2154246b2ca8fa13d4f6f1256f7a16aa98a8c24a
Reviewed-on: https://go-review.googlesource.com/c/go/+/480155
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
WithoutCancel returns a copy of parent that is not canceled when parent is canceled.
The returned context returns no Deadline or Err, and its Done channel is nil.
Calling Cause on the returned context returns nil.
API changes:
+pkg context, func WithoutCancel(Context) Context
Fixes#40221
Change-Id: Ide29631c08881176a2c2a58409fed9ca6072e65d
Reviewed-on: https://go-review.googlesource.com/c/go/+/479918
Run-TryBot: Sameer Ajmani <sameer@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Some test files imported "os" twice, once with a dot and once without.
Consolidate on importing with a dot.
Change-Id: I1db31053dff9dee19a6bdfc263c7e7ef0c15ee42
Reviewed-on: https://go-review.googlesource.com/c/go/+/479995
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This CL updates the linker to support
IMAGE_REL_[I386|AMD64|ARM|ARM64]_ADDR32NB relocations via the new
R_PEIMAGEOFF relocation type. This relocation type references symbols
using RVAs instead of VA, so it can use 4-byte offsets to reference
symbols that would normally require 8-byte offsets.
This new relocation is still not used, but will be useful when
generating Structured Exception Handling (SEH) metadata, which
needs to reference functions only using 4-byte addresses, thus
using RVAs instead of VA is of great help.
Updates #57302
Change-Id: I28d73e97d5cb78a3bc7194dc7d2fcb4a03f9f4d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/461737
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Davis Goodin <dagood@microsoft.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I617d6d788cb213c1405f81d9f689fd6846ee105a
Reviewed-on: https://go-review.googlesource.com/c/go/+/425300
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: WANG Xuerui <git@xen0n.name>
Loong64's R22-R31 and F24-F31 are callee saved registers, which
should be saved in the beginning of sigtramp, and restored at
the end.
In reviewing comments about sigtramp in sys_linux_arm64 it was
noted that a previous issue in arm64 due to missing callee save
registers could also be a problem on loong64, so code was added
to save and restore those.
Updates #31827
Change-Id: I3ae58fe8a64ddb052d0a89b63e82c01ad328dd15
Reviewed-on: https://go-review.googlesource.com/c/go/+/426356
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Auto-Submit: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: WANG Xuerui <git@xen0n.name>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Same as CL 292109, A g's sched.g is set in newproc1, After that, it never changes.
Yet lots of assembly code does "g.sched.g = g" unnecessarily. Remove it to avoid
confusion about whether it ever changes.
Change-Id: I3d3b18267a80bdd9ef5487c1d1d29de4c5a2d5cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/476375
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: WANG Xuerui <git@xen0n.name>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The symbols are all defined within the same file, no need
to reference through package names.
Change-Id: I81c27831e85666ebd26d346aeb8f023e52d98acc
Reviewed-on: https://go-review.googlesource.com/c/go/+/479497
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: WANG Xuerui <git@xen0n.name>
Change the Checker.use/useLHS functions to report if all "used"
expressions evaluated without error. Use that information to
control whether to report an assignment mismatch error or not.
This will reduce the number of errors reported per assignment,
where the assignment mismatch is only one of the errors.
Change-Id: Ia0fc3203253b002e4e1d5759d8d5644999af6884
Reviewed-on: https://go-review.googlesource.com/c/go/+/478756
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
For #55242
Change-Id: I092b1881623ea997b178d038c0afd10cd5bca937
Reviewed-on: https://go-review.googlesource.com/c/go/+/479898
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts commit https://go-review.git.corp.google.com/c/go/+/479775
Reason for revert: fails with ios-arm64-corellium builder
Change-Id: Iae61b994a39ff6c70af8a302f7a46de0097edf3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/479917
Auto-Submit: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
unsafe.SliceData can return pointers which are nil. That function gets
lowered to the SSA OpSlicePtr, which the compiler assumes is non-nil.
This used to be the case as OpSlicePtr was only used in situations
where the bounds check already passed. But with unsafe.SliceData that
is no longer the case.
There are situations where we know it is nil. Use Bounded() to
indicate that.
I looked through all the uses of OSPTR and added SetBounded where it
made sense. Most OSPTR results are passed directly to runtime calls
(e.g. memmove), so even if we know they are non-nil that info isn't
helpful.
Fixes#59293
Change-Id: I437a15330db48e0082acfb1f89caf8c56723fc51
Reviewed-on: https://go-review.googlesource.com/c/go/+/479896
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
As with changes in prior CLs, we don't suppress legitimate
"declared but not used" errors anymore simply because the
respective variables are used in incorrect assignments,
unrelated to the variables in question.
Adjust several (ancient) tests accordingly.
Change-Id: I5826393264d9d8085c64777a330d4efeb735dd2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/478716
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
When external linking with -buildmode=c-archive, the Go linker
eventually invokes the "ar" tool to create the final archive library.
Prior to this patch, if the '-extar' flag was not in use, we would
just run "ar". This works well in most cases but breaks down if we're
doing cross-compilation targeting Windows (macos system "ar"
apparently doesn't create the windows symdef section correctly). To
fix the problem, capture the output of "cc --print-prog-name ar" and
invoke "ar" using the path returned by that command.
Fixes#59221.
Change-Id: I9de66e98947c42633b16fde7208c2958d62fe7cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/479775
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Rather than using exprList and handle all cases together, split
apart the cases of n:n assignments and the cases of n:1 assignments.
For the former, the lhs types may (in a future CL) be used to infer
types on the rhs. This is a preparatory step.
Because the two cases are handled separately, the code is longer
(but also more explicit).
Some test cases were adjusted to avoifd (legitimate, but previously
supressed) "declared but not used" errors.
Change-Id: Ia43265f84e423b0ad5594612ba5a0ddce31a4a37
Reviewed-on: https://go-review.googlesource.com/c/go/+/478256
Reviewed-by: 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>
Auto-Submit: Robert Griesemer <gri@google.com>
We avoid allocating registers when we know they may have a fixed use
later (arg/return value, or the CX shift argument to SHRQ, etc.) But
it isn't worth avoiding that register if it requires moving another
register.
A move we may have to do later is not worth a move we definitely have
to do now.
Fixes#59288
Change-Id: Ibbdcbaea9caee0c5f3e0d6956a1a084ba89757a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/479895
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Windows is able to use the go resolver now, so let the forceCgoDNS and forceGoDns work.
Change-Id: Ice3d9fda9530ec88a2a22077c9a729dd940aba6d
GitHub-Last-Rev: e0b6e39870
GitHub-Pull-Request: golang/go#59250
Reviewed-on: https://go-review.googlesource.com/c/go/+/479455
Run-TryBot: Ian Lance Taylor <iant@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@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
A GeneralizedTime value may contain an optional fractional seconds
element (according to X.680 46.2, restricted by X.690 11.7.3). This
change adds support for this fractional part, up to nine digits, so that
Unmarshal won't fail when decoding a DER encoded GeneralizedTime value
with fractional digits. Also, test cases related to this change have
been added.
X.680 and X.690 can be found at:
https://www.itu.int/rec/T-REC-X.680https://www.itu.int/rec/T-REC-X.690Fixes#15842
Change-Id: If217c007e01b686db508a940e9e2ed3bfb901879
Reviewed-on: https://go-review.googlesource.com/c/go/+/108355
Run-TryBot: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the worst case (x.mode != invalid but x.typ == Typ[Invalid]) we
may get unexpected additional errors; but we don't seem to have
any such situations, at least in the existing tests.
Change-Id: I86ae607b4ac9b926264bb6a967627c40e5a86ade
Reviewed-on: https://go-review.googlesource.com/c/go/+/478715
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>
This CL re-introduces useLHS because we don't want to suppress
correct "declared but not used" errors for variables that only
appear on the LHS of an assignment (using Checker.use would mark
them as used).
This CL also adjusts a couple of places where types2 differed
from go/types (and suppressed valid "declared and not used"
errors). Now those errors are surfaced. Adjusted a handful of
tests accordingly.
Change-Id: Ia555139a05049887aeeec9e5221b1f41432c1a57
Reviewed-on: https://go-review.googlesource.com/c/go/+/478635
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
