Currently, for data moving, we generate an msanread of the source,
followed by an msanwrite of the destination. msanread checks
the source is initialized.
This has a problem: if the source is an aggregate type containing
alignment paddings, the padding bytes may not be thought as
initialized by MSAN. If we copy the aggregate type by value, if
it counts as a read, MSAN reports using uninitialized data. This
CL changes it to use __msan_memmove for data copying, which tells
MSAN to propagate initialized-ness but not check for it.
Caveat: technically __msan_memmove is not a public API of MSAN,
although the C compiler does generate direct calls to it.
Also, when instrumenting a load of a struct, split the
instrumentation to fields, instead of generating an msanread for
the whole struct. This skips padding bytes, which may not be
considered initialized in MSAN.
Fixes#42820.
Change-Id: Id861c8bbfd94cfcccefcc58eaf9e4eb43b4d85c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/270859
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
It turned out that "go get" was using the network to look up
https://github.com?go-get=1 while resolving github.com/google/go-cmp,
and that is not the fastest page to load.
Stop that lookup by adjusting the path prefixes in the vcs table.
It also turned out that "go get" was using the network to look up
https://rsc.io?go-get=1 while resolving https://rsc.io/nonexist.svn.
That's a bit more defensible maybe, since rsc.io is not a known VCS host.
But for tests we really want to avoid the network entirely, so this CL
adds a special case in repoRootFromVCSPaths that returns a hard error
for plain "rsc.io" instead of doing the web fetch.
To keep us honest in the future, I added two automatically-set env
variables TESTGONETWORK=panic and TESTGOVCS=panic.
These cause the go command to panic rather than make a network request
or invoke a VCS command.
go test -short cmd/go now passes with these checks.
This reduced the time spent in go test -short cmd/go on my
Google workstation from 154s to 30s. (Yay network firewalls.)
Change-Id: I49207fca7f901fa011765fb984dc9cec8b691f11
Reviewed-on: https://go-review.googlesource.com/c/go/+/274441
Trust: Russ Cox <rsc@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
io/ioutil was a poorly defined collection of helpers.
Proposal #40025 moved out the generic I/O helpers to io.
This CL for proposal #42026 moves the OS-specific helpers to os,
making the entire io/ioutil package deprecated.
For #42026.
Change-Id: I018bcb2115ef2ff1bc7ca36a9247eda429af21ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/266364
Trust: Russ Cox <rsc@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
This if follow up of CL 274332.
Updates #9399.
Change-Id: Ic6dd534dc18227a799cbb9577979f2285596b825
Reviewed-on: https://go-review.googlesource.com/c/go/+/274393
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Unbuffered channels passed into signal.Notify can be lost
as the docs for signal.Notify caution with:
Package signal will not block sending to c: the caller must ensure
that c has sufficient buffer space to keep up with the expected signal
rate. For a channel used for notification of just one signal value,
a buffer of size 1 is sufficient.
Found by a static analyzer from Orijtech, Inc. called "sigchanyzer", but
it'll be donated to the Go project soon.
Updates #9399.
Change-Id: Ia0690e447582da028694ed65ace7b97961997b84
Reviewed-on: https://go-review.googlesource.com/c/go/+/274332
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Now that filepath.WalkDir is available, it is more efficient
and should be used in place of filepath.Walk.
Update the tree to reflect best practices.
As usual, the code compiled with Go 1.4 during bootstrap is excluded.
(In this CL, that's only cmd/dist.)
For #42027.
Change-Id: Ib0f7b1e43e50b789052f9835a63ced701d8c411c
Reviewed-on: https://go-review.googlesource.com/c/go/+/267719
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Pseudo branch instructions BGT, BGTU, BLE, and BLEU implemented In
CL 226397 were translated inconsistently compared to other ones due
to the inversion of registers. For instance, while "BLT a, b" generates
"jump if a < b", "BLE a, b" generates "jump if b <= a."
This CL fixes the translation in the assembler and the tests.
Change-Id: Ia757be73e848734ca5b3a790e081f7c4f98c30f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/271911
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
The gofrontend code doesn't distinguish semicolon and newline,
and it doesn't have special treatment for EOF.
syntax/semi6.go:9:47: error: unexpected semicolon or newline in type declaration
syntax/semi6.go:11:62: error: unexpected semicolon or newline in type declaration
Change-Id: I9996b59a4fc78ad1935e779f354ddf75c0fb44e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/274692
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Apparently, the darwin kernel may cache the code signature at
mmap. When we mmap the output buffer, it doesn't have a code
signature (as we haven't generated one). Invalidate the kernel
cache after writing the file.
See https://github.com/golang/go/issues/42684#issuecomment-731704900
for more information.
Updates #38485.
Fixes#42684.
Change-Id: Iac2ef756ca1454c856944423e5040b8e17a6b420
Reviewed-on: https://go-review.googlesource.com/c/go/+/272258
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
As the code signature contains hashes of the entire file (except
the signature itself), rewriting buildid will invalidate the
signature. This CL makes it regenerate the signature when
rewriting the buildid. It only does it when the file already has
a code signature, with proper size (darwin/arm64 binaries
generated by the Go linker should have).
Updates #38485, #42684.
Change-Id: I082d9e5808b0ee6a35f9c362d7262aadd9113c81
Reviewed-on: https://go-review.googlesource.com/c/go/+/272257
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL lets the linker code-sign output binaries on
darwin/arm64, as the kernel requires binaries must be signed in
order to run.
This signature will likely be invalidated when we stamp the
buildid after linking. We still do it in the linker, for
- plain "go tool link" works.
- the linker generates the LC_CODE_SIGNATURE load command with
the right size and offset, so we don't need to update it when
stamping the buildid.
Updates #38485, #42684.
Change-Id: Ia306328906d73217221ba31093fe61a935a46122
Reviewed-on: https://go-review.googlesource.com/c/go/+/272256
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
These replacement rules assume that TST and TEQ set V. But TST and
TEQ do not set V. This is a problem because instructions like LT are
actually checking for N!=V. But with TST and TEQ not setting V, LT
doesn't do anything meaningful. It's possible to construct trivial
miscompilations from this, such as:
package main
var x = [4]int32{-0x7fffffff, 0x7fffffff, 2, 4}
func main() {
if x[0] > x[1] {
panic("fail 1")
}
if x[2]&x[3] < 0 {
panic("fail 2") // Fails here
}
}
That first comparison sets V, via the CMP that subtracts the values
causing the overflow. Then the second comparison operation thinks that
it uses the result of TST, when it actually uses the V from CMP.
Before this fix:
TST R0, R1
BLT loc_6C164
After this fix:
TST R0, R1
BMI loc_6C164
The BMI instruction checks the N flag, which TST sets. This commit
fixes the issue by using [LG][TE]noov instead of vanilla [LG][TE], and
also adds a test case for the direct issue.
Fixes#42876.
Change-Id: I13c62c88d18574247ad002b671b38d2d0b0fc6fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/274026
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
This reverts commit 6af088bfc6.
Reason for revert: Broke many tests inside Google which implies many
tests were broken outside of Google as well. The tests may be brittle
but still would require work to change and it's not clear it's worth
the benefit.
Updates #36221Fixes#42675
Change-Id: Id3a14eb37e7119f5abe50e80dfbf120fdc44db72
Reviewed-on: https://go-review.googlesource.com/c/go/+/273747
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Trust: Joe Tsai <thebrokentoaster@gmail.com>
The code signature contains hashes of the entire file (except the
signature itself), including the buildid. Therefore, the buildid
cannot depend on the signature. Otherwise updating buildid will
invalidate the signature, and vice versa. As we cannot change the
code-signing algorithm, we can only change buildid calculation.
This CL changes the buildid calculation to exclude the Mach-O
code signature. So updating code signature after stamping the
buildid will not invalidate the buildid.
Updates #38485, #42684.
Change-Id: I8a9e2e25ca9dc00d9556d13b81652f43bbf6a084
Reviewed-on: https://go-review.googlesource.com/c/go/+/272255
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
On macOS/ARM64, the kernel requires that binaries must have a
valid code signature to run. The C toolchain code-signs the
binary at link time. We do the same.
It is more subtle for Go because we stamp the buildid after
linking. As the signature contains hashes of the entire file
(except the signature itself), we must (re)generate the signature
after stamping the buildid.
This CL adds a new codesign package, which provides
functionality to generate the code signature. It is a separate
internal package so it can be used both in the linker and by the
go command. The next CLs will add code-signing to the linker and
the go command.
Updates #38485, #42684.
Change-Id: Id46801a6665beebaab0eb413ff2e64c5b9467059
Reviewed-on: https://go-review.googlesource.com/c/go/+/272254
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
CL 269357 is the only difference between the pseudo-version we were
using and v0.4.0.
Change-Id: If15326bda51e04b47130429b818bfe2facaee03d
Reviewed-on: https://go-review.googlesource.com/c/go/+/274593
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
It's difficult for module authors to provide installation instructions
that work in both Go 1.15 and 1.16. We'll wait until 1.17 to print a
deprecation warning for installing executables with 'go get'.
Fixes#42885
Change-Id: I835b447e83e760f48fd664e8a117749e0cb59f83
Reviewed-on: https://go-review.googlesource.com/c/go/+/274552
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
If one was using http.Transport with DisableKeepAlives and trying
to upgrade a connection against net/http's Server, the Server
would not allow a "Connection: Upgrade" header to be written
and instead override it to "Connection: Close" which would
break the handshake.
This change ensures net/http's Server does not override the
connection header for successful protocol switch responses.
Fixes#36381.
Change-Id: I882aad8539e6c87ff5f37c20e20b3a7fa1a30357
GitHub-Last-Rev: dc0de83201
GitHub-Pull-Request: golang/go#36382
Reviewed-on: https://go-review.googlesource.com/c/go/+/213277
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Once the connection is put back into the idle pool, the request should
not take any action if the connection is closed.
Fixes#41600
Change-Id: I5e4ddcdc03cd44f5197ecfbe324638604961de84
Reviewed-on: https://go-review.googlesource.com/c/go/+/257818
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Damien Neil <dneil@google.com>
For #40700Fixes#42912
Change-Id: Ifd36950136db1fc93a8de76a2717a473210418b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/274473
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Added notes for:
* go test -c and -i flags used with unknown flags
* GO111MODULE=on by default
* GOVCS
* Dropped requirements on excluded versions
Removed TODOs for documentation on the retract directive and
'go install pkg@version'. These pages will be written after the beta.
Change-Id: Ic9877a62f908be177a6035a039b72e969e7b7f22
Reviewed-on: https://go-review.googlesource.com/c/go/+/274438
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Add tests for BGE/BGEU/BLT/BLTU branch instructions. Also add pure Go variants
of these to ensure that the test data, Go and assembly all match up.
Change-Id: I84c68605e116a4e57f6c5c765bf0aaecab84b675
Reviewed-on: https://go-review.googlesource.com/c/go/+/271913
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Quey-Liang Kao <s101062801@m101.nthu.edu.tw>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently, in the non-DynlinkingGo case with external linking, we generate a
R_X86_64_GOTPCREL relocation for the imported symbol. This results in the
external linker turning this into a R_X86_64_GLOB_DAT relocation, rather
than a R_X86_64_JUMP_SLOT. Always generate R_X86_64_PLT32 for SDYNIMPORT
calls so that these calls work correctly.
Update #36435Fixes#42671
Change-Id: I8a28884b7853cb4135053ed817bedc919482f4ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/270377
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Apparently, the macOS ARM64 kernel has a bug where when a signal
arrives and the signal stack is not currently faulted in, it may
kill the program with a SIGILL. Work around it by mlock the
signal stacks.
Fixes#42774.
Change-Id: I99a4b3fdb6d8af1c945725ddc2c25568d81c510a
Reviewed-on: https://go-review.googlesource.com/c/go/+/273686
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Fixes#41752
Change-Id: I83520d2303e5fd2e5f6329f092b40e73c13771a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/271908
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Noticed while skimming through recent master commits.
Change-Id: I42a99ea7d71c05fc5b6107627105375a21920f5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/271990
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This matches the error messages after CL 273890.
syntax/semi4.go:11:9: error: unexpected semicolon or newline, expecting ‘{’ after for clause
syntax/semi4.go:10:13: error: reference to undefined name ‘x’
syntax/semi4.go:12:17: error: reference to undefined name ‘z’
Change-Id: Ic88ff6e27d50bf70f5b2114383b84c42c0682f39
Reviewed-on: https://go-review.googlesource.com/c/go/+/273891
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
shift1.go:76:16: error: shift of non-integer operand
shift1.go:77:16: error: shift of non-integer operand
Change-Id: I48584c0b01f9f6912a93b5f9bba55b5803fbeced
Reviewed-on: https://go-review.googlesource.com/c/go/+/273888
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
As of https://golang.org/cl/273886:
fixedbugs/bug340.go:15:18: error: reference to method ‘x’ in interface with no methods
For golang/go#10700
Change-Id: Id29eb0e34bbb524117614229c4c27cfd17dae286
Reviewed-on: https://go-review.googlesource.com/c/go/+/273887
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Separating iOS into its own runtime constant broke the logic
here to derive the correct home, cache, and config directories
on iOS devices.
Fixes#42878
Change-Id: Ie4ff57895fcc34b0a9af45554ea3a346447d2e7a
GitHub-Last-Rev: 5e74e64917
GitHub-Pull-Request: golang/go#42879
Reviewed-on: https://go-review.googlesource.com/c/go/+/273947
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
CL 268578 was not formatted properly.
Change-Id: I08d2fc691e4f90a38d8165344c135b7b4f73b339
GitHub-Last-Rev: 6183bb0639
GitHub-Pull-Request: golang/go#42736
Reviewed-on: https://go-review.googlesource.com/c/go/+/271807
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
On illumos systems, libc can under some conditions make use of files
from /proc. In the case of this test, the creation of new threads was
(in the target thread) causing libc to open and close
"/proc/self/lwp/5/lwpname" to set the thread name, which raced with the
leaking descriptor check (see detailed analysis in #42431).
This change requests that the Go runtime use less threads in the child
process used to check for leaked descriptors, without just disabling the
test. After a thousand repeated trials, the test no longer fails on
illumos.
Fixes#42431.
Change-Id: Iefda26134fc91f7cb205754676e9845d9b7205cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/273966
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This is blocking forward progress of the de-bitrotting work, and I don't
know off hand how to fix this. Seeing as its disabled on other
platforms, I suspect pprof might not be a very reliable feature, so just
allow for the tests to fail for now, until somebody more motivated comes
along to fix it.
Updates #42862.
Change-Id: Ibc5cd1d82d97b9c2f887d7f3565f2fa70207c8b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/273826
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
These changes match the following gofrontend error messages:
blank1.go:16:1: error: may not define methods on non-local type
chan/perm.go:28:9: error: expected channel
chan/perm.go:29:11: error: left operand of ‘<-’ must be channel
chan/perm.go:69:9: error: argument must be channel
complit1.go:25:16: error: attempt to slice object that is not array, slice, or string
complit1.go:26:16: error: attempt to slice object that is not array, slice, or string
complit1.go:27:17: error: attempt to slice object that is not array, slice, or string
complit1.go:49:41: error: may only omit types within composite literals of slice, array, or map type
complit1.go:50:14: error: expected struct, slice, array, or map type for composite literal
convlit.go:24:9: error: invalid type conversion (cannot use type unsafe.Pointer as type string)
convlit.go:25:9: error: invalid type conversion (cannot use type unsafe.Pointer as type float64)
convlit.go:26:9: error: invalid type conversion (cannot use type unsafe.Pointer as type int)
ddd1.go:63:9: error: invalid use of ‘...’ calling non-variadic function
fixedbugs/bug176.go:12:18: error: index expression is not integer constant
fixedbugs/bug332.go:17:10: error: use of undefined type ‘T’
fixedbugs/issue4232.go:22:16: error: integer constant overflow
fixedbugs/issue4232.go:33:16: error: integer constant overflow
fixedbugs/issue4232.go:44:25: error: integer constant overflow
fixedbugs/issue4232.go:55:16: error: integer constant overflow
fixedbugs/issue4458.go:19:14: error: type has no method ‘foo’
fixedbugs/issue5172.go:24:14: error: too many expressions for struct
init.go:17:9: error: reference to undefined name ‘runtime’
initializerr.go:26:29: error: duplicate value for index 1
interface/explicit.go:60:14: error: type assertion only valid for interface types
label.go:64:9: error: reference to undefined label ‘go2’
label1.go:18:97: error: continue statement not within for
label1.go:22:97: error: continue statement not within for
label1.go:106:89: error: continue statement not within for
label1.go:108:26: error: invalid continue label ‘on’
label1.go:111:118: error: break statement not within for or switch or select
label1.go:113:23: error: invalid break label ‘dance’
map1.go:64:9: error: not enough arguments
map1.go:65:9: error: not enough arguments
map1.go:67:9: error: argument 1 must be a map
method2.go:36:11: error: reference to undefined field or method ‘val’
method2.go:37:11: error: reference to undefined field or method ‘val’
method2.go:41:12: error: method requires pointer (use ‘(*T).g’)
syntax/chan1.go:13:19: error: send statement used as value; use select for non-blocking send
syntax/chan1.go:17:11: error: send statement used as value; use select for non-blocking send
Change-Id: I98047b60a376e3d2788836300f7fcac3f2c285cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/273527
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If the linker thinks that it's in exe mode instead of pie mode, it
won't emit relocations when generating the pcln table, and we wind
up with crashes like this on windows/arm, where all binaries are
in fact relocated:
Building Go toolchain2 using go_bootstrap and Go toolchain1.
fatal error: minpc or maxpc invalid
runtime: panic before malloc heap initialized
This problem was already solved by darwin/arm64, so solve it the same
way here for windows/arm.
Fixes CL 228478.
Fixes#42786.
Change-Id: I6d1db6907c131183649fc263ccca06783188f344
Reviewed-on: https://go-review.googlesource.com/c/go/+/273566
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Apparently we're being called on arm 1 byte off, just like on 386 and
amd64, so unify the handler for isAbortPC.
Fixes#42859.
Updates #29050.
Change-Id: I97fffeb4a33d93ca3397ce1c9ba2b05137f391ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/273727
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
This function's prototype includes a return value, so return a value.
Otherwise clang gets upset:
--- FAIL: TestDLLPreloadMitigation (1.40s)
syscall_windows_test.go:986: failed to build dll: exit status 1 - nojack.c:7:1: error: non-void function does not return a value [-Werror,-Wreturn-type]
}
^
1 error generated.
Fixes#42860.
Change-Id: I65b8eb9ccb502692c5b65bd34829f331cd86eef0
Reviewed-on: https://go-review.googlesource.com/c/go/+/273726
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
None of the other, older, doc comments use the '*Logger' form, and while
'Logger' and 'logger' are both used in the package doc comment, the
common term used with the intended meaning is 'standard logger', which
appears another eleven times in doc comments.
Change-Id: I089103198fc82390517615eb27bbe7ef77107d34
Reviewed-on: https://go-review.googlesource.com/c/go/+/273486
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
