This is a port of CL 278132 from the dev.typeparams branch. A notable
addition is a new error code, since no existing codes made sense and we
have an analogous code for type switches.
Fixes#43110
Change-Id: I22b3f9d8777063223f82785504e8b7d299bc5216
Reviewed-on: https://go-review.googlesource.com/c/go/+/278813
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Mach-O relocation addend is signed 24-bit. When external linking,
if the addend is larger, we cannot put it directly into a Mach-O
relocation. This CL handles large addend by creating "label"
symbols at sym+0x800000, sym+(0x800000*2), etc., and emitting
Mach-O relocations that target the label symbols with a smaller
addend. The label symbols are generated late (similar to what
we do for RISC-V64).
One complexity comes from handling of carrier symbols, which does
not track its size or its inner symbols. But relocations can
target them. We track them in a side table (similar to what we
do for XCOFF, xcoffUpdateOuterSize).
Fixes#42738.
Change-Id: I8c53ab2397f8b88870d26f00e9026285e5ff5584
Reviewed-on: https://go-review.googlesource.com/c/go/+/278332
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
When testing if a flag (e.g. "-no-pie") is supported by the
external linker, pass arch-specific flags (like "-marm").
In particular, on the ARM builder, if CGO_LDFLAGS=-march=armv6
is set, the C toolchain fails to build if -marm is not passed.
# cc -march=armv6 1.c
1.c: In function 'main':
1.c:3:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI
int main() {
^~~
This makes the Go linker think "-no-pie" is not supported when it
actually is.
Passing -marm makes it work.
Fixes#43202.
Change-Id: I4e8b71f08818993cbbcb2494b310c68d812d6b50
Reviewed-on: https://go-review.googlesource.com/c/go/+/278592
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The code in the new (introduced in 1.15) Go object file reader was
casting a pointer-mmaped-memory into a large array prior to performing
a read of the relocations section:
return (*[1<<20]Reloc)(unsafe.Pointer(&r.b[off]))[:n:n]
For very large object files, this artificial array isn't large enough
(that is, there are more than 1048576 relocs to read), so update the
code to use a larger artifical array size.
Fixes#41621.
Change-Id: Ic047c8aef4f8a3839f2e7e3594bce652ebd6bd5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/278492
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Trust: Than McIntosh <thanm@google.com>
The transponder sets up a deferred close on accepted connections which
is fine after the client reads all data. However there are no mutexes
nor channels to block the transponder from closing. If the scheduler
runs close before the client read, it will cause an EOF failure.
Fixes#42720
Change-Id: Ic21b476c5efc9265a80a2c6f8484efdb5af66405
Reviewed-on: https://go-review.googlesource.com/c/go/+/273672
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Damien Neil <dneil@google.com>
Microsoft's linker looks at whether all input objects have an empty
section called @feat.00. If all of them do, then it enables SEH;
otherwise it doesn't enable that feature. So, since around the Windows
XP SP2 era, most tools that make PE objects just tack on that section,
so that it won't gimp Microsoft's linker logic. Go doesn't support SEH,
so in theory, none of this really matters to us. But actually, if the
linker tries to ingest an object with @feat.00 -- which are produced by
LLVM's resource compiler, for example -- it chokes because of the
IMAGE_SYM_ABSOLUTE section that it doesn't know how to deal with. Since
@feat.00 is just a marking anyway, skip IMAGE_SYM_ABSOLUTE sections that
are called @feat.00.
Change-Id: I1d7bfcf6001186c53e2c487c5ac251ca65efefee
Reviewed-on: https://go-review.googlesource.com/c/go/+/268239
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
The gofrontend code sees that the denominator is not zero,
so it computes the values. Dividing zero by a non-zero value
produces zero. The language spec doesn't require any of these
cases to report an error, so make the errors compiler-specific.
Change-Id: I5ed759a3121e38b937744d32250adcbdf2c4d3c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/278117
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The bug429 tests is an exact duplicate of TestSimpleDeadlock in the
runtime package. The runtime package is the right place for this test,
and the version in the runtime package will run faster as the build
step is combined with other runtime package tests.
Change-Id: I6538d24e6df8e8c5e3e399d3ff37d68f3e52be56
Reviewed-on: https://go-review.googlesource.com/c/go/+/278173
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The language spec only requires that floating point values be
represented with 256 bits, which is about 1e75. The issue11371 test
was assuming that the compiler could represent 1e100. Adjusting the
test so that it only assumes 256 bits of precision still keeps the
test valid, and permits it to pass when using the gofrontend.
Change-Id: I9d1006e9adc9438277f4b8002488c912e5d61cc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/278116
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
With the gc compiler the import path implies the package path,
so keeping a canonical path is important. With the gofrontend
this is not the case, so we don't need to report this as a bug.
Change-Id: I245e34f9b66383bd17e79438d4b002a3e20aa994
Reviewed-on: https://go-review.googlesource.com/c/go/+/278115
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The pattern in NNN.dir directories is that if we have a.go,
the other files import "./a". For gc it happens to work to use a path,
but not for gofrontend. Better to be consistent.
Change-Id: I2e023cbf6bd115f9fb77427b097b0ff9b9992f17
Reviewed-on: https://go-review.googlesource.com/c/go/+/278113
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The path package doesn't have a Glob function. Adjust the release notes
re. CL 264397 accordingly.
Also add links to the documentation of all mentioned functions.
For #40700.
Change-Id: Ibf3e0530fa6fab36a3f6fbc664f0800869ce9ec7
Reviewed-on: https://go-review.googlesource.com/c/go/+/278213
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
fixedbugs/issue26416.go:24:16: error: unknown field ‘t1f1’ in ‘t2’
fixedbugs/issue26416.go:25:16: error: unknown field ‘t1f2’ in ‘t3’
fixedbugs/issue26416.go:26:16: error: unknown field ‘t2f1’ in ‘t3’
fixedbugs/issue26616.go:15:9: error: single variable set to multiple-value function call
fixedbugs/issue26616.go:9:5: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:12:13: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:13:13: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:15:9: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:14:11: error: incompatible types in assignment (multiple-value function call in single-value context)
fixedbugs/issue26855.go:23:12: error: incompatible type for field 1 in struct construction
fixedbugs/issue26855.go:27:12: error: incompatible type for field 1 in struct construction
fixedbugs/issue25958.go:14:18: error: expected ‘<-’ or ‘=’
fixedbugs/issue25958.go:15:35: error: expected ‘<-’ or ‘=’
fixedbugs/issue28079b.go:13:9: error: array bound is not constant
fixedbugs/issue28079b.go:16:22: error: invalid context-determined non-integer type for left operand of shift
fixedbugs/issue28079c.go:14:22: error: invalid context-determined non-integer type for left operand of shift
fixedbugs/issue28450.go:9:19: error: ‘...’ only permits one name
fixedbugs/issue28450.go:10:18: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:11:16: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:11:24: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:13:25: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:15:19: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:16:21: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:16:31: error: ‘...’ must be last parameter
fixedbugs/issue28268.go:20:1: error: method ‘E’ redeclares struct field name
fixedbugs/issue28268.go:19:1: error: method ‘b’ redeclares struct field name
fixedbugs/issue27356.go:14:14: error: expected function
fixedbugs/issue27356.go:18:9: error: expected function
fixedbugs/issue29855.go:13:11: error: unknown field ‘Name’ in ‘T’
fixedbugs/issue27938.go:14:15: error: expected package
fixedbugs/issue27938.go:18:13: error: expected package
fixedbugs/issue27938.go:22:13: error: expected package
fixedbugs/issue27938.go:22:9: error: expected signature or type name
fixedbugs/issue29870b.go:13:9: error: ‘x’ declared but not used
fixedbugs/issue30085.go:10:18: error: wrong number of initializations
fixedbugs/issue30085.go:11:21: error: wrong number of initializations
fixedbugs/issue30087.go:10:18: error: wrong number of initializations
fixedbugs/issue30087.go:11:11: error: number of variables does not match number of values
fixedbugs/issue30087.go:12:9: error: wrong number of initializations
fixedbugs/issue30087.go:13:9: error: wrong number of initializations
fixedbugs/issue28926.go:16:14: error: use of undefined type ‘G’
fixedbugs/issue28926.go:18:14: error: use of undefined type ‘E’
fixedbugs/issue28926.go:22:24: error: use of undefined type ‘T’
fixedbugs/issue30722.go:13:13: error: invalid numeric literal
fixedbugs/issue30722.go:14:13: error: invalid numeric literal
fixedbugs/issue30722.go:15:13: error: invalid numeric literal
fixedbugs/issue33308.go:12:19: error: invalid context-determined non-integer type for left operand of shift
fixedbugs/issue33386.go:16:9: error: expected operand
fixedbugs/issue33386.go:22:9: error: expected operand
fixedbugs/issue33386.go:26:17: error: expected operand
fixedbugs/issue33386.go:27:18: error: expected operand
fixedbugs/issue33386.go:28:29: error: expected operand
fixedbugs/issue33386.go:15:17: error: reference to undefined name ‘send’
fixedbugs/issue33386.go:27:13: error: reference to undefined name ‘a’
fixedbugs/issue33386.go:21:19: error: value computed is not used
fixedbugs/issue33460.go:34:10: error: duplicate key in map literal
fixedbugs/issue33460.go:21:9: error: duplicate case in switch
fixedbugs/issue33460.go:24:9: error: duplicate case in switch
fixedbugs/issue33460.go:25:9: error: duplicate case in switch
fixedbugs/issue32723.go:12:14: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:13:13: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:16:16: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:17:16: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:18:15: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:21:15: error: invalid comparison of non-ordered type
fixedbugs/issue35291.go:13:9: error: duplicate value for index 1
fixedbugs/issue38745.go:12:12: error: reference to undefined field or method ‘M’
fixedbugs/issue38745.go:13:16: error: reference to undefined field or method ‘M’
fixedbugs/issue38745.go:17:19: error: reference to undefined field or method ‘M’
fixedbugs/issue38745.go:17:9: error: not enough arguments to return
fixedbugs/issue41500.go:16:22: error: incompatible types in binary expression
fixedbugs/issue41500.go:17:26: error: incompatible types in binary expression
fixedbugs/issue41500.go:18:22: error: incompatible types in binary expression
fixedbugs/issue41500.go:19:26: error: incompatible types in binary expression
fixedbugs/issue41575.go:23:6: error: invalid recursive type
fixedbugs/issue41575.go:9:6: error: invalid recursive type ‘T1’
fixedbugs/issue41575.go:13:6: error: invalid recursive type ‘T2’
fixedbugs/issue41575.go:17:6: error: invalid recursive type ‘a’
fixedbugs/issue41575.go:18:6: error: invalid recursive type ‘b’
fixedbugs/issue41575.go:19:6: error: invalid recursive type ‘c’
fixedbugs/issue41575.go:25:6: error: invalid recursive type ‘g’
fixedbugs/issue41575.go:32:6: error: invalid recursive type ‘x’
fixedbugs/issue41575.go:33:6: error: invalid recursive type ‘y’
fixedbugs/issue4215.go:10:9: error: not enough arguments to return
fixedbugs/issue4215.go:14:9: error: return with value in function with no return type
fixedbugs/issue4215.go:19:17: error: not enough arguments to return
fixedbugs/issue4215.go:21:9: error: not enough arguments to return
fixedbugs/issue4215.go:27:17: error: not enough arguments to return
fixedbugs/issue4215.go:29:17: error: too many values in return statement
fixedbugs/issue4215.go:31:17: error: not enough arguments to return
fixedbugs/issue4215.go:43:17: error: not enough arguments to return
fixedbugs/issue4215.go:46:17: error: not enough arguments to return
fixedbugs/issue4215.go:48:9: error: too many values in return statement
fixedbugs/issue4215.go:52:9: error: too many values in return statement
fixedbugs/issue41247.go:10:16: error: incompatible type for return value 1
fixedbugs/issue41440.go:13:9: error: too many arguments
fixedbugs/issue6772.go:10:16: error: ‘a’ repeated on left side of :=
fixedbugs/issue6772.go:17:16: error: ‘a’ repeated on left side of :=
fixedbugs/issue6402.go:12:16: error: incompatible type for return value 1
fixedbugs/issue6403.go:13:23: error: reference to undefined identifier ‘syscall.X’
fixedbugs/issue6403.go:14:15: error: reference to undefined name ‘voidpkg’
fixedbugs/issue7746.go:24:20: error: constant multiplication overflow
fixedbugs/issue7760.go:15:7: error: invalid constant type
fixedbugs/issue7760.go:16:7: error: invalid constant type
fixedbugs/issue7760.go:18:7: error: invalid constant type
fixedbugs/issue7760.go:19:7: error: invalid constant type
fixedbugs/issue7760.go:21:11: error: expression is not constant
fixedbugs/issue7760.go:22:11: error: expression is not constant
fixedbugs/issue7760.go:24:7: error: invalid constant type
fixedbugs/issue7760.go:25:7: error: invalid constant type
fixedbugs/issue7129.go:18:11: error: argument 1 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7129.go:19:11: error: argument 1 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7129.go:20:11: error: argument 1 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7129.go:20:17: error: argument 2 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7150.go:12:20: error: index expression is negative
fixedbugs/issue7150.go:13:13: error: some element keys in composite literal are out of range
fixedbugs/issue7150.go:14:13: error: some element keys in composite literal are out of range
fixedbugs/issue7150.go:15:13: error: some element keys in composite literal are out of range
fixedbugs/issue7150.go:16:13: error: some element keys in composite literal are out of range
fixedbugs/issue7675.go:16:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:16:24: error: argument 3 has incompatible type (cannot use type string as type float64)
fixedbugs/issue7675.go:16:9: error: not enough arguments
fixedbugs/issue7675.go:16:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:18:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:18:24: error: argument 3 has incompatible type (cannot use type string as type float64)
fixedbugs/issue7675.go:18:28: error: argument 4 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:18:9: error: too many arguments
fixedbugs/issue7675.go:18:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:19:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:19:9: error: not enough arguments
fixedbugs/issue7675.go:19:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:21:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:21:19: error: argument 3 has incompatible type
fixedbugs/issue7675.go:21:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:23:14: error: floating-point constant truncated to integer
fixedbugs/issue7153.go:11:15: error: reference to undefined name ‘a’
fixedbugs/issue7153.go:11:18: error: incompatible type for element 1 in composite literal
fixedbugs/issue7153.go:11:24: error: incompatible type for element 2 in composite literal
fixedbugs/issue7310.go:12:13: error: left argument must be a slice
fixedbugs/issue7310.go:13:13: error: second argument must be slice or string
fixedbugs/issue7310.go:14:15: error: incompatible types in binary expression
fixedbugs/issue6964.go:10:13: error: invalid type conversion (cannot use type complex128 as type string)
fixedbugs/issue7538a.go:14:9: error: reference to undefined label ‘_’
fixedbugs/issue8311.go:14:9: error: increment or decrement of non-numeric type
fixedbugs/issue8507.go:12:6: error: invalid recursive type ‘T’
fixedbugs/issue9521.go:16:20: error: argument 2 has incompatible type
fixedbugs/issue9521.go:17:20: error: argument 2 has incompatible type (cannot use type float64 as type int)
fixedbugs/issue8385.go:30:19: error: argument 1 has incompatible type (type has no methods)
fixedbugs/issue8385.go:30:14: error: not enough arguments
fixedbugs/issue8385.go:35:9: error: not enough arguments
fixedbugs/issue8385.go:36:9: error: not enough arguments
fixedbugs/issue8385.go:37:10: error: not enough arguments
fixedbugs/issue8385.go:38:10: error: not enough arguments
fixedbugs/issue8385.go:39:10: error: not enough arguments
fixedbugs/issue8385.go:40:10: error: not enough arguments
fixedbugs/issue8385.go:41:13: error: not enough arguments
fixedbugs/issue8438.go:13:23: error: incompatible type for element 1 in composite literal
fixedbugs/issue8438.go:14:22: error: incompatible type for element 1 in composite literal
fixedbugs/issue8438.go:15:23: error: incompatible type for element 1 in composite literal
fixedbugs/issue8440.go:10:9: error: reference to undefined name ‘n’
Change-Id: I5707aec7d3c9178c4f4d794d4827fc907b52efb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/278032
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 far as I can tell, the addend is the same for both of these, and in
this context we don't really care about setting or unsetting the thumb
selection bit, so just treat these the same way.
Change-Id: I3756c027239f77778c32b317733df9ac92272580
Reviewed-on: https://go-review.googlesource.com/c/go/+/268238
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
The linker recognizes headers for 386 and amd64 PE objects, but not arm
objects. This is easily overlooked, since its the same as the 386 header
value, except the two nibbles of the first word are swapped. This commit
simply adds the check for this. Without it, .syso objects are rejected,
which means Windows binaries can't have resources built into them. At
the same time, we add comments to better indicate which condition
applies to which arch.
Change-Id: I210411d978504c1a9540e23abc5a180e24f159ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/268237
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
The `external_cgo_thread` test in `runtime/race/output_test.go` was
producing intermittent failures. The test was performing a sleep,
which may not be enough depending on how long it takes to setup the
callBack goroutine.
Added a synchronization to make sure callBack finishes before main ends.
Whether the increment to racy++ happens first in the callBack
or in main doesn't matter: the race detector should flag the race
regardless. The output check was changed so that the test passes
regardless of which increment occurs first.
Fixes#43008
Change-Id: I325ec3dea52b3725e739fbf2bd7ae92875d2de10
Reviewed-on: https://go-review.googlesource.com/c/go/+/276752
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
In an executable, the debug_addr and debug_rnglists sections are
assembled by concatenating the input sections, and each input section
has a header, and each header may have different attributes. So just
parsing the single header isn't right. Parsing the header is not
necessary to handle offsets into these sections which is all we do.
Looking at the header is also problematic because GCC with
-gsplit-dwarf when using DWARF versions 2 through 4 emits a
.debug_addr section, but it has no header. The header was only added
for DWARF 5. So we can't parse the header at all for that case, and we
can't even detect that case in general.
This CL also fixes SeekPC with addrx and strx formats, by not using
the wrong compilation unit to find the address or string base.
To make that work when parsing the compilation unit itself, we add
support for delay the resolution of those values until we know the base.
New test binaries built with
gcc -gdwarf-5 -no-pie debug/dwarf/testdata/line[12].c
(gcc (Debian 10.2.0-15) 10.2.0)
clang -gdwarf-5 -no-pie debug/dwarf/testdata/line[12].c
(clang version 9.0.1-14)
Change-Id: I66783e0eded629bf80c467767f781164d344a54d
Reviewed-on: https://go-review.googlesource.com/c/go/+/277233
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
fixedbugs/issue20602.go:13:9: error: argument must have complex type
fixedbugs/issue20602.go:14:9: error: argument must have complex type
fixedbugs/issue19323.go:12:12: error: attempt to slice object that is not array, slice, or string
fixedbugs/issue19323.go:18:13: error: attempt to slice object that is not array, slice, or string
fixedbugs/issue20749.go:12:11: error: array index out of bounds
fixedbugs/issue20749.go:15:11: error: array index out of bounds
fixedbugs/issue20415.go:14:5: error: redefinition of ‘f’
fixedbugs/issue20415.go:12:5: note: previous definition of ‘f’ was here
fixedbugs/issue20415.go:25:5: error: redefinition of ‘g’
fixedbugs/issue20415.go:20:5: note: previous definition of ‘g’ was here
fixedbugs/issue20415.go:33:5: error: redefinition of ‘h’
fixedbugs/issue20415.go:31:5: note: previous definition of ‘h’ was here
fixedbugs/issue19977.go:12:21: error: reference to undefined name ‘a’
fixedbugs/issue20812.go:10:13: error: invalid type conversion (cannot use type string as type int)
fixedbugs/issue20812.go:11:13: error: invalid type conversion (cannot use type int as type bool)
fixedbugs/issue20812.go:12:13: error: invalid type conversion (cannot use type string as type bool)
fixedbugs/issue20812.go:13:13: error: invalid type conversion (cannot use type bool as type int)
fixedbugs/issue20812.go:14:13: error: invalid type conversion (cannot use type bool as type string)
fixedbugs/issue21256.go:9:5: error: redefinition of ‘main’
fixedbugs/issue20813.go:10:11: error: invalid left hand side of assignment
fixedbugs/issue20185.go:22:16: error: ‘t’ declared but not used
fixedbugs/issue20185.go:13:9: error: cannot type switch on non-interface value
fixedbugs/issue20185.go:22:9: error: cannot type switch on non-interface value
fixedbugs/issue20227.go:11:11: error: division by zero
fixedbugs/issue20227.go:12:12: error: division by zero
fixedbugs/issue20227.go:13:12: error: division by zero
fixedbugs/issue20227.go:15:11: error: division by zero
fixedbugs/issue20227.go:16:12: error: division by zero
fixedbugs/issue19880.go:14:13: error: invalid use of type
fixedbugs/issue23093.go:9:5: error: initialization expression for ‘f’ depends upon itself
fixedbugs/issue21979.go:29:13: error: integer constant overflow
fixedbugs/issue21979.go:39:13: error: complex constant truncated to floating-point
fixedbugs/issue21979.go:10:13: error: invalid type conversion (cannot use type string as type bool)
fixedbugs/issue21979.go:11:13: error: invalid type conversion (cannot use type int as type bool)
fixedbugs/issue21979.go:12:13: error: invalid type conversion (cannot use type float64 as type bool)
fixedbugs/issue21979.go:13:13: error: invalid type conversion (cannot use type complex128 as type bool)
fixedbugs/issue21979.go:15:13: error: invalid type conversion (cannot use type bool as type string)
fixedbugs/issue21979.go:17:13: error: invalid type conversion (cannot use type float64 as type string)
fixedbugs/issue21979.go:18:13: error: invalid type conversion (cannot use type complex128 as type string)
fixedbugs/issue21979.go:20:13: error: invalid type conversion (cannot use type string as type int)
fixedbugs/issue21979.go:21:13: error: invalid type conversion (cannot use type bool as type int)
fixedbugs/issue21979.go:27:13: error: invalid type conversion (cannot use type string as type uint)
fixedbugs/issue21979.go:28:13: error: invalid type conversion (cannot use type bool as type uint)
fixedbugs/issue21979.go:34:13: error: invalid type conversion (cannot use type string as type float64)
fixedbugs/issue21979.go:35:13: error: invalid type conversion (cannot use type bool as type float64)
fixedbugs/issue21979.go:41:13: error: invalid type conversion (cannot use type string as type complex128)
fixedbugs/issue21979.go:42:13: error: invalid type conversion (cannot use type bool as type complex128)
fixedbugs/issue21988.go:11:11: error: reference to undefined name ‘Wrong’
fixedbugs/issue22063.go:11:11: error: reference to undefined name ‘Wrong’
fixedbugs/issue22904.go:12:6: error: invalid recursive type ‘a’
fixedbugs/issue22904.go:13:6: error: invalid recursive type ‘b’
fixedbugs/issue22921.go:11:16: error: reference to undefined identifier ‘bytes.nonexist’
fixedbugs/issue22921.go:13:19: error: reference to undefined identifier ‘bytes.nonexist’
fixedbugs/issue22921.go:13:19: error: expected signature or type name
fixedbugs/issue22921.go:17:15: error: reference to undefined identifier ‘bytes.buffer’
fixedbugs/issue23823.go:15:9: error: invalid recursive interface
fixedbugs/issue23823.go:10:9: error: invalid recursive interface
fixedbugs/issue23732.go:24:13: error: too few expressions for struct
fixedbugs/issue23732.go:34:17: error: too many expressions for struct
fixedbugs/issue23732.go:37:13: error: too few expressions for struct
fixedbugs/issue23732.go:40:17: error: too many expressions for struct
fixedbugs/issue22794.go:16:14: error: reference to undefined field or method ‘floats’
fixedbugs/issue22794.go:18:19: error: unknown field ‘floats’ in ‘it’
fixedbugs/issue22794.go:19:17: error: unknown field ‘InneR’ in ‘it’
fixedbugs/issue22794.go:18:9: error: ‘i2’ declared but not used
fixedbugs/issue22822.go:15:17: error: expected function
fixedbugs/issue25727.go:12:10: error: reference to unexported field or method ‘doneChan’
fixedbugs/issue25727.go:13:10: error: reference to undefined field or method ‘DoneChan’
fixedbugs/issue25727.go:14:21: error: unknown field ‘tlsConfig’ in ‘http.Server’
fixedbugs/issue25727.go:15:21: error: unknown field ‘DoneChan’ in ‘http.Server’
fixedbugs/issue25727.go:21:14: error: unknown field ‘bAr’ in ‘foo’
Change-Id: I32ce0b7d80017b2367b8fb479a881632240d4161
Reviewed-on: https://go-review.googlesource.com/c/go/+/277455
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
fixedbugs/issue14136.go:17:16: error: unknown field ‘X’ in ‘T’
fixedbugs/issue14136.go:18:13: error: incompatible type in initialization (cannot use type int as type string)
fixedbugs/issue14520.go:9:37: error: import path contains control character
fixedbugs/issue14520.go:14:2: error: expected ‘)’
fixedbugs/issue14520.go:14:3: error: expected declaration
fixedbugs/issue14652.go:9:7: error: use of undefined type ‘any’
fixedbugs/issue14729.go:13:17: error: embedded type may not be a pointer
fixedbugs/issue15514.dir/c.go:10: error: incompatible type in initialization
fixedbugs/issue15898.go:11:9: error: duplicate type in switch
fixedbugs/issue15898.go:16:9: error: duplicate type in switch
fixedbugs/issue16439.go:10:21: error: index expression is negative
fixedbugs/issue16439.go:13:21: error: index expression is negative
fixedbugs/issue16439.go:16:21: error: index expression is not integer constant
fixedbugs/issue16439.go:18:22: error: index expression is not integer constant
fixedbugs/issue17328.go:11:20: error: expected ‘{’
fixedbugs/issue17328.go:11:20: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue17328.go:13:1: error: expected declaration
fixedbugs/issue17588.go:14:15: error: expected type
fixedbugs/issue17631.go:20:17: error: unknown field ‘updates’ in ‘unnamed struct’
fixedbugs/issue17645.go:15:13: error: incompatible type in initialization
fixedbugs/issue17758.go:13:1: error: redefinition of ‘foo’
fixedbugs/issue17758.go:9:1: note: previous definition of ‘foo’ was here
fixedbugs/issue18092.go:13:19: error: expected colon
fixedbugs/issue18231.go:17:12: error: may only omit types within composite literals of slice, array, or map type
fixedbugs/issue18393.go:24:38: error: expected type
fixedbugs/issue18419.dir/test.go:12: error: reference to unexported field or method 'member'
fixedbugs/issue18655.go:14:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:15:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:16:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:17:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:18:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:20:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:21:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:22:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18915.go:13:20: error: expected ‘;’ after statement in if expression
fixedbugs/issue18915.go:16:21: error: parse error in for statement
fixedbugs/issue18915.go:19:24: error: expected ‘;’ after statement in switch expression
fixedbugs/issue18915.go:13:12: error: ‘a’ declared but not used
fixedbugs/issue18915.go:16:13: error: ‘b’ declared but not used
fixedbugs/issue18915.go:19:16: error: ‘c’ declared but not used
fixedbugs/issue19012.go:16:17: error: return with value in function with no return type
fixedbugs/issue19012.go:18:9: error: return with value in function with no return type
fixedbugs/issue19012.go:22:16: error: argument 2 has incompatible type (cannot use type bool as type uint)
fixedbugs/issue19012.go:22:9: error: too many arguments
fixedbugs/issue19012.go:22:16: error: incompatible types in binary expression
fixedbugs/issue19012.go:24:9: error: too many arguments
fixedbugs/issue19056.go:9:9: error: expected operand
fixedbugs/issue19056.go:9:9: error: expected ‘;’ or newline after top level declaration
fixedbugs/issue19482.go:25:15: error: expected struct field name
fixedbugs/issue19482.go:27:15: error: expected struct field name
fixedbugs/issue19482.go:31:19: error: expected struct field name
fixedbugs/issue19482.go:33:15: error: expected struct field name
fixedbugs/issue19667.go:13:1: error: expected operand
fixedbugs/issue19667.go:13:1: error: missing ‘)’
fixedbugs/issue19667.go:13:105: error: expected ‘;’ after statement in if expression
fixedbugs/issue19667.go:13:105: error: expected ‘{’
fixedbugs/issue19667.go:12:19: error: reference to undefined name ‘http’
Change-Id: Ia9c75b9c78671f354f0a0623dbc075157ef8f181
Reviewed-on: https://go-review.googlesource.com/c/go/+/277433
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The type of the shift count must be an unsigned integer. Some s390x
rules for shift have their auxint type being int8. This results in a
compilation failure on s390x with an invalid operation when running
make.bash using older versions of go (e.g: go1.10.4).
This CL adds an auxint type of uint8 and changes the ops for shift and
rotate to use auxint with type uint8. The related rules are also
modified to address this change.
Fixes#43090
Change-Id: I594274b6e3d9b23092fc9e9f4b354870164f2f19
Reviewed-on: https://go-review.googlesource.com/c/go/+/277078
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
If 'go install' is invoked in module mode outside a module with a
package that could only be loaded from a module, it will now suggest
running 'go install pkg@latest'.
'go install' will still work outside a module on packages in std and
cmd, as well as .go files specified on the command line.
Fixes#42638
Change-Id: Ib0963935f028b7656178bc04a279b1114de35fbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/277355
Run-TryBot: Jay Conrod <jayconrod@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Replaced load.PackagesForBuild with a new function,
load.CheckPackageErrors. Callers should now call PackagesAndErrors,
then CheckPackageErrors for the same functionality.
Removed load.Packages. Callers should call base.Errorf and filter the
package list as needed.
This gives callers more flexibility in handling package load errors.
For #42638
Change-Id: Id75463ba695adc1ca3f8693ceb2c8978b74a3500
Reviewed-on: https://go-review.googlesource.com/c/go/+/277354
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Since CL 270057, there're many attempts to fix the expand_calls pass
with interface{}-typed. But all of them did not fix the root cause. The
main issue is during SSA conversion in gc/ssa.go, for empty interface
case, we make its type as n.Type, instead of BytePtr.
To fix these, we can just use BytePtr for now, since when itab fields
are treated as scalar.
No significal changes on compiler speed, size.
cmd/compile/internal/ssa
expandCalls.func6 9488 -> 9232 (-2.70%)
file before after Δ %
cmd/compile/internal/ssa.s 3992893 3992637 -256 -0.006%
total 20500447 20500191 -256 -0.001%
Fixes#43112
Updates #42784
Updates #42727
Updates #42568
Change-Id: I0b15d9434e0be5448453e61f98ef9c2d6cd93792
Reviewed-on: https://go-review.googlesource.com/c/go/+/276952
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: Keith Randall <khr@golang.org>
The Go spec requires that select case clauses be evaluated in order,
which is stricter than normal ordering semantics. cmd/compile handled
this correctly for send clauses, but was not correctly handling
receive clauses that involved bare variable references.
Discovered with @cuonglm.
Fixes#43111.
Change-Id: Iec93b6514dd771875b084ba49c15d7f4531b4a6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/277132
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
The various conversion functions just change the format of time values.
They don't use the Unix epoch. Although in practice the values are often
times since the Unix epoch, they aren't always, so referring to the
epoch can be confusing.
Fixes#43010
Change-Id: I640d665f0d2017f0974db05d70858037c7c91eda
Reviewed-on: https://go-review.googlesource.com/c/go/+/277073
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The tools section TODO can be removed since the tools section looks
complete by now.
All TODOs in the minor changes to the library section have been done,
so the top-level TODO is resolved. Delete it.
The currently highlighted entries under Core library section look
good. It's worth reviewing this further based on feedback from Go
1.16 pre-releases, so keep the TODO but make it non-user-visible
to unblock Go 1.16 Beta 1.
For #40700.
Change-Id: Ie72661bd457b0a93ef92e1bfc0844072f3b618a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/277212
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change adds an additional line explaining the ordering of the
supported metrics list. It's also necessary to ensure "Supported
metrics" is displayed by godoc as a proper header.
This modification does mean the description test, that ensures
descriptions line up with documentation, needs to change slightly
so it it doesn't read this new line as documentation. Make this
new line the line the test uses to decide when to begin.
Change-Id: I654c1c20e97a80ea79c8eb864445153ce91950bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/275852
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
fixedbugs/bug13343.go:10:12: error: initialization expressions for ‘b’ and ‘c’ depend upon each other
fixedbugs/bug13343.go:11:9: note: ‘c’ defined here
fixedbugs/bug13343.go:11:9: error: initialization expression for ‘c’ depends upon itself
fixedbugs/bug13343.go:11:9: error: initialization expressions for ‘c’ and ‘b’ depend upon each other
fixedbugs/bug13343.go:10:12: note: ‘b’ defined here
fixedbugs/issue10700.dir/test.go:24:10: error: reference to method ‘Do’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:25:10: error: reference to method ‘do’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:27:10: error: reference to method ‘Dont’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:28:13: error: reference to undefined field or method ‘Dont’
fixedbugs/issue10700.dir/test.go:31:10: error: reference to undefined field or method ‘do’
fixedbugs/issue10700.dir/test.go:33:13: error: reference to undefined field or method ‘do’
fixedbugs/issue10700.dir/test.go:34:10: error: reference to undefined field or method ‘Dont’
fixedbugs/issue10700.dir/test.go:35:13: error: reference to undefined field or method ‘Dont’
fixedbugs/issue10700.dir/test.go:37:10: error: reference to method ‘Do’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:38:10: error: reference to method ‘do’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:40:13: error: reference to undefined field or method ‘do’
fixedbugs/issue10700.dir/test.go:41:10: error: reference to method ‘Dont’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:42:13: error: reference to undefined field or method ‘Dont’
fixedbugs/issue10700.dir/test.go:43:10: error: reference to method ‘secret’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:44:13: error: reference to unexported field or method ‘secret’
fixedbugs/issue10975.go:13:9: error: interface contains embedded non-interface
fixedbugs/issue11326.go:26:17: error: floating-point constant overflow
fixedbugs/issue11326.go:27:17: error: floating-point constant overflow
fixedbugs/issue11326.go:28:17: error: floating-point constant overflow
fixedbugs/issue11361.go:9:11: error: import file ‘fmt’ not found
fixedbugs/issue11361.go:11:11: error: reference to undefined name ‘fmt’
fixedbugs/issue11371.go:12:15: error: floating-point constant truncated to integer
fixedbugs/issue11371.go:13:15: error: integer constant overflow
fixedbugs/issue11371.go:17:15: error: floating-point constant truncated to integer
fixedbugs/issue11590.go:9:17: error: integer constant overflow
fixedbugs/issue11590.go:9:17: error: integer constant overflow
fixedbugs/issue11590.go:10:22: error: complex real part overflow
fixedbugs/issue11590.go:10:22: error: complex real part overflow
fixedbugs/issue11590.go:11:23: error: complex real part overflow
fixedbugs/issue11590.go:11:23: error: complex real part overflow
fixedbugs/issue11590.go:9:19: error: integer constant overflow
fixedbugs/issue11590.go:10:24: error: complex real part overflow
fixedbugs/issue11590.go:11:25: error: complex real part overflow
fixedbugs/issue11610.go:11:7: error: import path is empty
fixedbugs/issue11610.go:12:4: error: invalid character 0x3f in input file
fixedbugs/issue11610.go:14:1: error: expected identifier
fixedbugs/issue11610.go:14:1: error: expected type
fixedbugs/issue11614.go:14:9: error: interface contains embedded non-interface
fixedbugs/issue13248.go:13:1: error: expected operand
fixedbugs/issue13248.go:13:1: error: missing ‘)’
fixedbugs/issue13248.go:12:5: error: reference to undefined name ‘foo’
fixedbugs/issue13266.go:10:8: error: package name must be an identifier
fixedbugs/issue13266.go:10:8: error: expected ‘;’ or newline after package clause
fixedbugs/issue13266.go:10:8: error: expected declaration
fixedbugs/issue13273.go:50:18: error: expected ‘chan’
fixedbugs/issue13273.go:53:24: error: expected ‘chan’
fixedbugs/issue13274.go:11:58: error: expected ‘}’
fixedbugs/issue13365.go:14:19: error: index expression is negative
fixedbugs/issue13365.go:15:21: error: index expression is negative
fixedbugs/issue13365.go:16:22: error: index expression is negative
fixedbugs/issue13365.go:19:13: error: some element keys in composite literal are out of range
fixedbugs/issue13365.go:22:19: error: incompatible type for element 1 in composite literal
fixedbugs/issue13365.go:23:21: error: incompatible type for element 1 in composite literal
fixedbugs/issue13365.go:24:22: error: incompatible type for element 1 in composite literal
fixedbugs/issue13415.go:14:5: error: redefinition of ‘x’
fixedbugs/issue13415.go:14:5: note: previous definition of ‘x’ was here
fixedbugs/issue13415.go:14:5: error: ‘x’ declared but not used
fixedbugs/issue13471.go:12:25: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:13:25: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:14:25: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:15:24: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:16:23: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:18:26: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:19:26: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:20:26: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:21:25: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:22:24: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:24:24: error: floating-point constant truncated to integer
fixedbugs/issue13821b.go:18:12: error: incompatible types in binary expression
fixedbugs/issue13821b.go:19:13: error: incompatible types in binary expression
fixedbugs/issue13821b.go:20:13: error: incompatible types in binary expression
fixedbugs/issue13821b.go:21:13: error: incompatible types in binary expression
fixedbugs/issue13821b.go:22:13: error: incompatible types in binary expression
fixedbugs/issue13821b.go:24:12: error: incompatible types in binary expression
fixedbugs/issue14006.go:24:18: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue14006.go:30:18: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue14006.go:37:22: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue14006.go:43:22: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue14006.go:59:17: note: previous definition of ‘labelname’ was here
fixedbugs/issue14006.go:64:17: error: label ‘labelname’ already defined
fixedbugs/issue14006.go:24:17: error: value computed is not used
fixedbugs/issue14006.go:30:17: error: value computed is not used
fixedbugs/issue14006.go:37:20: error: value computed is not used
fixedbugs/issue14006.go:43:20: error: value computed is not used
fixedbugs/issue14006.go:59:17: error: label ‘labelname’ defined and not used
fixedbugs/issue14010.go:13:14: error: invalid left hand side of assignment
fixedbugs/issue14010.go:14:14: error: invalid left hand side of assignment
fixedbugs/issue14010.go:14:9: error: invalid use of type
fixedbugs/issue14321.go:30:10: error: method ‘F’ is ambiguous in type ‘C’
fixedbugs/issue14321.go:31:10: error: ‘G’ is ambiguous via ‘A’ and ‘B’
fixedbugs/issue14321.go:33:10: error: type ‘C’ has no method ‘I’
fixedbugs/issue8183.go:12:14: error: integer constant overflow
fixedbugs/issue9036.go:21:12: error: invalid prefix for floating constant
fixedbugs/issue9036.go:22:12: error: invalid prefix for floating constant
fixedbugs/issue9076.go:14:5: error: incompatible type in initialization (cannot use type uintptr as type int32)
fixedbugs/issue9076.go:15:5: error: incompatible type in initialization (cannot use type uintptr as type int32)
For issue9083.go avoid an error about a variable that is set but not used.
fixedbugs/issue9370.go:105:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:106:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:107:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:108:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:109:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:110:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:112:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:113:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:114:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:115:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:116:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:117:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:119:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:119:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:36:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:39:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:43:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:46:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:50:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:53:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:56:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:57:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:58:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:59:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:60:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:61:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:65:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:68:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:70:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:71:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:72:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:73:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:74:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:75:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:77:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:78:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:79:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:80:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:81:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:82:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:84:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:85:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:86:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:87:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:88:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:89:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:91:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:92:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:93:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:94:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:95:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:96:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:98:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:99:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:100:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:101:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:102:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:103:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:121:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:122:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:123:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:124:15: error: incompatible types in binary expression
Change-Id: I4089de4919112b08f5f2bbec20f84fcc7dbe3955
Reviewed-on: https://go-review.googlesource.com/c/go/+/276832
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Done with:
go get -d golang.org/x/net@latest
go mod tidy
go mod vendor
go generate -run bundle std
The cmd module was updated as well, but go mod tidy undoes the change
because the x/net module doesn't contribute any packages to cmd module.
cmd/internal/moddeps.TestDependencyVersionsConsistent is happy with it:
// It's ok if there are undetected differences in modules that do not
// provide imported packages: we will not have to pull in any backports of
// fixes to those modules anyway.
Fixes#31192.
Updates #42498.
Change-Id: If303c9a7aa2ce8c2553fcb1ced7fccc9e6652ad6
Reviewed-on: https://go-review.googlesource.com/c/go/+/277012
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
When the -linkshared build mode is in effect, the Go command passes
the "-linkshared" command line option to the compiler so as to insure
special handling for things like builtin functions (which may appear
in a shared library and not the main executable). This patch extends
this behavior to the assembler, since the assembler may also wind up
referencing builtins when emitting a stack-split prolog.
Fixes#43107.
Change-Id: I56eaded79789b083f3c3d800fb140353dee33ba9
Reviewed-on: https://go-review.googlesource.com/c/go/+/276932
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When external linking, in case that the external linker generates
a code signature with a different size (e.g. as it uses a
different identifier), truncate the file after rewriting the code
signature, to make sure that no bytes after the signature (which
will invalidate the signature).
Fixes#43105.
Change-Id: I732f949fedd6de42d9f3cf6d017f7ba3f4e59e7a
Reviewed-on: https://go-review.googlesource.com/c/go/+/276693
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
os.ReadDir is a replacement for ioutil.ReadDir that returns
a slice of fs.DirEntry instead of fs.FileInfo, meaning it is the
more efficient form.
This CL updates call sites throughout the Go source tree
wherever possible. As usual, code built using the Go 1.4
bootstrap toolchain is not included. There is also a use in
go/build that appears in the public API and can't be changed,
at least not without additional changes.
Fixes#42026.
Change-Id: Icfc9dd52c6045020f6830e22c72128499462d561
Reviewed-on: https://go-review.googlesource.com/c/go/+/266366
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
As part of #42026, these helpers from io/ioutil were moved to os.
(ioutil.TempFile and TempDir became os.CreateTemp and MkdirTemp.)
Update the Go tree to use the preferred names.
As usual, code compiled with the Go 1.4 bootstrap toolchain
and code vendored from other sources is excluded.
ReadDir changes are in a separate CL, because they are not a
simple search and replace.
For #42026.
Change-Id: If318df0216d57e95ea0c4093b89f65e5b0ababb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/266365
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
go test sets the working directory to that of the package being tested,
so opening one of the package source files can be done in a simpler way.
This also allows the test to run in more environments, for example when
GOROOT_FINAL¹ is set.
Also remove the testenv.HasSrc-like check for Go source. The doc.go
file is a part of the package being built and tested, so it's expected
to be available. If it's important for this test to handle when a test
binary is built with go test -c and executed elsewhere without package
source files, something more than testenv.HasSrc would be needed.
¹ https://golang.org/cmd/go/#hdr-Environment_variablesFixes#43085.
Change-Id: Ie6ade395a8fc7beebdadbad6f4873800138dfc26
Reviewed-on: https://go-review.googlesource.com/c/go/+/276452
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Issue #41600 fixed the issue when a second request canceled a connection
while the first request was still in roundTrip.
This uncovered a second issue where a request was being canceled (in
roundtrip) but the connection was put back into the idle pool for a
subsequent request.
The fix is the similar except its now in readLoop instead of roundTrip.
A persistent connection is only added back if it successfully removed
the cancel function; otherwise we know the roundTrip has started
cancelRequest.
Fixes#42942
Change-Id: Ia56add20880ccd0c1ab812d380d8628e45f6f44c
Reviewed-on: https://go-review.googlesource.com/c/go/+/274973
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
This fixes the unexpected growth of stack in child process, which
is caused by stack checking code in runtime.sigfillset called from
runtime.sigset while clearing the signal handlers in child process.
The redundant stack checking code is generated due to missing
'//go:nosplit' directive that should be annotated for
runtime.sigfillset.
Fixes#43066
Updates #21314
Change-Id: I9483a962a4b0747074313991841e2440ee32198c
Reviewed-on: https://go-review.googlesource.com/c/go/+/276173
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
This is a port of CL 275517 from the dev.typeparams branch, to fix the
positioning of error messages for invalid const init expressions that
are inherited.
Differences from CL 275517:
+ The inherited flag is added to the constDecl intermediate
representation.
+ The errpos override is made a positioner, the internal interface
used by go/types to capture error position and span. For const decls
errpos is just set to a singular point, but using positioner is
correct and causes span start and end positions to also be
overridden.
+ Test cases are updated to assert on just 'overflows', as the go/types
error message is, for example, "cannot use 255 + iota (untyped int
constant 256) as byte value in constant declaration (overflows)".
This is more verbose than the compiler's "constant 256 overflows
byte", but changing that is out of scope.
Fixes#42991
Change-Id: I0a71d2290f7fff5513f2a6e49b83e6f0f4da30e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/276172
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Position independent code expects that R25 (aka $t9) contains the address of the
called function. As such, use R25 when calling from sigfwd.
Change-Id: I66b2b9bfa1f1bb983c7385eb2eaa19d9cd87d9fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/275893
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The gofrontend code would in some circumstances incorrectly generate a
type descriptor for an alias type, causing the type to fail to be
equal to the unaliased type.
Change-Id: I47d33b0bfde3c72a9a186049539732bdd5a6a96e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275632
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>
According to [1], this function returns NULL when it errors, rather than
INVALID_HANDLE_VALUE, which other Win32 functions return. This was
pointed out in CL 273446 for the x/sys package, and this patch here
cleans it up for the syscall package and updates the vendored x/sys
package using the usual `go get/go mod vendor` dance. The function is
currently in use by crypto/x509/root_windows.go, which calls
CertOpenStore(CERT_STORE_PROV_MEMORY), which I assume can fail under OOM
or other weird conditions. Quick reversing indicates that [1] is
correct, as there's a `xor eax, eax` in the error paths of the function
just before jumping to the epilogue.
[1] https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certopenstore#return-value
Change-Id: I77c0b0319c13313212f8710785252c494da56ed5
Reviewed-on: https://go-review.googlesource.com/c/go/+/273827
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Sub provides a convenient way to refer to a subdirectory
automatically in future operations, like Unix's chdir(2).
The CL also includes updates to fstest to check Sub implementations.
As part of updating fstest, I changed the meaning of TestFS's
expected list to introduce a special case: if you list no expected files,
that means the FS must be empty. In general it's OK not to list all
the expected files, but if you list none, that's almost certainly a
mistake - if your FS were broken and empty, you wouldn't find out.
Making no expected files mean "must be empty" makes the mistake
less likely - if your file system ever worked, then your test will keep
it working.
That change found a testing bug: embedtest was making exactly
that mistake.
Fixes#42322.
Change-Id: I63fd4aa866b30061a0e51ca9a1927e576d6ec41e
Reviewed-on: https://go-review.googlesource.com/c/go/+/274856
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
An address of offset(SP) may point to the callee args area, and
may be used to move things into/out of the args/results. If an
address like that is spilled and picked up by the GC, it may hold
an arg/result live in the callee, which may not actually be live
(e.g. a result not initialized at function entry). Make sure
they are rematerializeable, so they are always short-lived and
never picked up by the GC.
This CL changes 386, PPC64, and Wasm. On AMD64 we already have
the rule (line 2159). On other architectures, we already have
similar rules like
(OffPtr [off] ptr:(SP)) => (MOVDaddr [int32(off)] ptr)
to avoid this problem. (Probably me in the past had run into
this...)
Fixes#42944.
Change-Id: Id2ec73ac08f8df1829a9a7ceb8f749d67fe86d1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275174
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
timer.when must always be positive. addtimer and modtimer already check
that it is non-negative; we expand it to include zero. Also upgrade from
pinning bad values to throwing, as these values shouldn't be possible to
pass (except as below).
timeSleep may overflow timer.nextwhen. This would previously have been
pinned by resetForSleep, now we fix it manually.
runOneTimer may overflow timer.when when adding timer.period. Detect
this and pin to maxWhen.
addtimer is now too strict to allow TestOverflowRuntimeTimer to test an
overflowed timer. Such a timer should not be possible; to help guard
against accidental inclusion siftup / siftdown will check timers as it
goes. This has been replaced with tests for period and sleep overflows.
Change-Id: I17f9739e27ebcb20d87945c635050316fb8e9226
Reviewed-on: https://go-review.googlesource.com/c/go/+/274853
Trust: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
timer when == 0, in the context of timer0When and timerModifiedEarliest,
is a sentinel value meaning there are no timers on the heap.
TestCheckRuntimeTimerOverflow reaching into the runtime to set a timer
to when = 0 when it is otherwise not possible breaks this invariant.
After golang.org/cl/258303, we will no longer detect and run this timer,
thus blocking any other timers lower on the heap from running. This
manifests as random timers failing to fire in other tests.
The need to set this overflowed timer to when = 0 is gone with the old
timer proc implementation, so we can simply remove it.
Fixes#42424
Change-Id: Iea32100136ad8ec1bedfa77b1e7d9ed868812838
Reviewed-on: https://go-review.googlesource.com/c/go/+/274632
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Pratt <mpratt@google.com>
The s390x assembly for shlVU does a forward copy when the shift amount s
is 0. This causes corruption of the result z when z is aliased to the
input x.
This fix removes the s390x assembly for both shlVU and shrVU so the pure
go implementations will be used.
Test cases have been added to the existing TestShiftOverlap test to
cover shift values of 0, 1 and (_W - 1).
Fixes#42838
Change-Id: I75ca0e98f3acfaa6366a26355dcd9dd82499a48b
Reviewed-on: https://go-review.googlesource.com/c/go/+/274442
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
All instructions in the FMA extension on x86 are VEX prefixed.
VEX prefixed instructions generally require OSXSAVE to be enabled.
The execution of FMA instructions emitted by the Go compiler on amd64
will generate an invalid opcode exception if OSXSAVE is not enabled.
Fixes#41022
Change-Id: I49881630e7195c804110a2bd81b5bec8cac31ba8
Reviewed-on: https://go-review.googlesource.com/c/go/+/274479
Trust: Martin Möhrmann <moehrmann@google.com>
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
assign.go:59:28: error: ‘x’ repeated on left side of :=
assign.go:65:20: error: ‘a’ repeated on left side of :=
method2.go:36:11: error: reference to method ‘val’ in type that is pointer to interface, not interface
method2.go:37:11: error: reference to method ‘val’ in type that is pointer to interface, not interface
Change-Id: I8f385c75a82fae4eacf4618df8f9f65932826494
Reviewed-on: https://go-review.googlesource.com/c/go/+/274447
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Returning an error about integer overflow is needlessly pedantic.
The meaning of ReadForm(MaxInt64) is easily understood
(accept a lot of data) and can be implemented.
Fixes#40430.
Change-Id: I8a522033dd9a2f9ad31dd2ad82cf08d553736ab9
Reviewed-on: https://go-review.googlesource.com/c/go/+/275112
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Many of the standard library changes that were added before CL 272871
ended up in the "Core library" section. That section is meant for
major changes like new packages, and most of these aren't.
Consolidate all changes in the "Minor changes to the library" section
for now, so that it's easier to get a complete picture of changes for
each package, along with the remaining TODOs. Add a TODO to read them
over at the end and factor out items that are worth highlighting.
Apply minor other fixups to improve consistency.
For #40700.
Change-Id: I7dc2e7ebf2ea3385fce0c207bae4ce467998a717
Reviewed-on: https://go-review.googlesource.com/c/go/+/273267
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
CL 34641 changed the Go runtime to assume GOARM=7 support on Android.
This change completes that by assuming GOARM=7 in the toolchain, fixing
the gotcha of inexplicably slow performance on non-arm64 Android devices.
There is already code in cmd/dist to force GOARM to 7 on GOOS=android. However,
dist is most likely run with GOOS != android.
Change-Id: I5e2bf11c3ecd0f6c193229eaa8ddc570722799d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/272846
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Elias Naur <mail@eliasnaur.com>
When c.elemsize==0 we call raceacquire() and racerelease()
as opposed to calling racereleaseacquire()
The reason for this change is that, when elemsize==0, we don't
allocate a full buffer for the channel. Instead of individual
buffer entries, the race detector uses the c.buf as the only
buffer entry. This simplification prevents us following the
memory model's happens-before rules implemented in racereleaseacquire().
So, instead of calling racereleaseacquire(), we accumulate
happens-before information in the synchronization object associated
with c.buf.
The functionality in this change is implemented in a new function
called racenotify()
Fixes#42598
Change-Id: I75b92708633fdfde658dc52e06264e2171824e51
Reviewed-on: https://go-review.googlesource.com/c/go/+/271987
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Currently, gentraceback decides which frames to print or elide when
unwinding inlined frames using only the name of the outermost
function. If the outermost function should be elided, then inlined
functions will also be elided, even if they shouldn't be.
This happens in practice in at least one situation. As of CL 258938,
exported Go functions (and functions they call) can now be inlined
into the generated _cgoexp_HASH_FN function. The runtime elides
_cgoexp_HASH_FN from tracebacks because it doesn't contain a ".".
Because of this bug, it also elides anything that was inlined into it.
This CL fixes this by synthesizing a funcInfo for the inlined
functions to pass to showframe.
Fixes#42754.
Change-Id: Ie6c663a4a1ac7f0d4beb1aa60bc26fc8cddd0f9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/272131
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The additions were generated using golang.org/x/build/cmd/relnote
at CL 272907. It was modified to find previously-missed entries
by querying the Gerrit API in addition to the maintner corpus.
For #40700.
Updates #41849.
Change-Id: If575984fe40e0133ad5e8fc5411ea5063457250d
Reviewed-on: https://go-review.googlesource.com/c/go/+/272871
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
This aligns the naming with GOARCH using 386 as a build target for
this architecture and makes it more easily found when searching
for documentation related to the build target.
Change-Id: I393bb89dd2f71e568124107b13e1b288fbd0c76a
Reviewed-on: https://go-review.googlesource.com/c/go/+/271988
Trust: Martin Möhrmann <moehrmann@google.com>
Run-TryBot: Martin Möhrmann <martisch@uos.de>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Because we're expecting for future functions to be unavailable, we
should add an Unwrap() function to the DLLError struct, so that people
can test for this situation easily via:
if errors.Is(err, syscall.ERROR_PROC_NOT_FOUND) { ... }
DLLError already was wrapping the underlying Errno error, but never got
the Go 1.13 helper method.
Fixesgolang/go#42584
Change-Id: I0f32a5146946b1b37a30897ba825a56faefc792c
Reviewed-on: https://go-review.googlesource.com/c/go/+/269761
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
The Reqs function returns an mvs.Reqs implemention for the global
build list. The API that it presents assumes that the build list is
globally consistent (problematic for #40775) and readily available
(problematic for #36460).
Fortunately, it is no longer used outside of the modload package.
We can instead use individual instances of the unexported mvsReqs
struct, making the dependency on the global build list more explicit.
For #36460
For #40775
Change-Id: I8674442f2a86416b0bf9c3395cb591c1e724c9d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/272129
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Move the declaration of the -overlay flag to base.AddModCommonFlags,
where other flags that are needed for go mod commands and for builds
are declared. The flag's already initialized in modload.Init so
there's no additional work needed to be done to support it in the go
mod commands.
For #39958
Change-Id: I70725d620cc69cb820f6ed923d626f4fe041b1c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/272126
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
ListModules was used to download .info files so that 'go list -m all'
would succeed later when offline. However, 'go list -m all' may
already fail when offline after 'go mod tidy', so it doesn't make
sense to add complexity to 'go get'.
Instead, remove the ListModules call and fix the test that
accidentally depended on it.
For #42723
Change-Id: I692597cf5ca15c23fa6fc9d2bac4b6e044299482
Reviewed-on: https://go-review.googlesource.com/c/go/+/271577
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
As of CL 271646, all external callers have been eliminated. Replace
the remaining internal caller with a direct reference to the buildList
variable and remove the exported function to prevent backsliding.
For #36460
Change-Id: Iea82df1e3e604ada602dda3e830c06d441eee2a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/271647
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The modload.EditBuildList call added in CL 270980 already ensures that
installMod does not require a newer version of itself, so the condition
that this loop is checking for is redundant.
(I had meant for this change to be included in CL 270980, but
apparently somehow reverted it prior to mailing.)
For #36460
Change-Id: I4dd746b927f7012d950187cac9c510cd6fec8fd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/271646
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
With this change, constant literals (and results of constant
operations) that internally become infinities are represented
externally (to go/constant) as "unknown" values.
The language has no provisions to deal with infinite constants,
and producing unknown values allows the typechecker to report
errors and avoid invalid operations (such as multiplication of
zero with infinity).
Fixes#20583.
Change-Id: I12f36a17d262ff7957b0d3880241b5a8b2984777
Reviewed-on: https://go-review.googlesource.com/c/go/+/271706
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
At this point in installOutsideModule the build list is empty, so
Selected trivially returns "none" for all modules.
(This change could have been made in CL 266657, but it was a bit
simpler to update the QueryPattern call sites mechanically to ensure
that there would be no unintentional semantic drift.)
For #36460
Change-Id: I44fb73794985bfeebb1dde0c092313f319c2945a
Reviewed-on: https://go-review.googlesource.com/c/go/+/271419
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The 'go install' command does not support the -gccgo flag.
(I'm not sure why, but it doesn't.)
gccgo also uses system-native assembly syntax instead of cmd/compile's
Plan 9 derivative. I've added an assembly file that seems to work on
Linux, but I haven't tested it on other platforms; if it fails on
other platforms, we can refine the test as needed.
Fixes#42688
Change-Id: I0693a6a9eb58975f20cdc4160ef5f9a948563c88
Reviewed-on: https://go-review.googlesource.com/c/go/+/270978
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
The printing of the ptr values can mean that two dump outputs can't easily be
compared for the identical structure, so adding the "-d=dumpptrs" option to make
printing of Node pointer values be an option.
Change-Id: I0e92b02f069e9de2e6fa036a7841645d13cdd7a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/271339
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This updates the callbacks implementation on windows/arm for the
changes made in CL 258938. At the time, that was left as a TODO.
At the same time, it also extends the previous support for only 4
arguments to also support additional arguments on the stack. This is
required for functions like SetWinEventHook, which take 7 arguments. It
does this by pushing r0-r3 onto the stack before the normal prologue,
and then pointing the args struct to that location.
This is derived from CL 270077 and CL 270078.
Updates #40724.
Fixes#42591.
Change-Id: Icc199e7f2c24205e41be4e00015283c7e2a9b797
Reviewed-on: https://go-review.googlesource.com/c/go/+/271178
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Austin Clements <austin@google.com>
For the last remaining call site (in cmd/go/internal/work, added for
the new 'go install pkg@version' codepath in CL 254365), use
EditBuildList instead.
SetBuildList assumes that the caller has enough information to produce
a complete, coherent build list. With lazy loading, producing a
complete, coherent build list is no longer quite so trivial.
In CL 263267, I rewrote the main caller of SetBuildList (the 'go get'
command), and in the process added a more targeted modload hook
(EditBuildList). That hook also suffices for 'go install pkg@version'.
The resulting error messages are perhaps not as smooth as they ought
to be, but if they are too awkward we should probably fix them for
'go get' too, and the commands can continue to share the edit hook.
For #36460
Updates #40276
Change-Id: I698a9dcd2efe6378a4d91f21362880aa8e50001b
Reviewed-on: https://go-review.googlesource.com/c/go/+/270980
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
modload.LoadedModules reveals more information than necessary about
whether modules have been loaded lazily. The 'vendor' subcommand
doesn't actually need that much information: it has all of the
information that it needs from prior calls to LoadPackages and
ModFile.
For #36460
Change-Id: If08733cca930b2b80616b037b63985ecfd6a320b
Reviewed-on: https://go-review.googlesource.com/c/go/+/270979
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The parser reports syntactic errors in constant literals.
The go/constant package produces an "unknown" value for
syntactically correct numeric constants that are too small
or too large. Check for the unknown value and report an
error rather than silently continuing.
Fixes#42695.
Change-Id: I414214559a285d67ed50184dc750f106960b5620
Reviewed-on: https://go-review.googlesource.com/c/go/+/271377
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
When inlining a function call expression, it's possible that the
function callee subexpression has side effects that need to be
preserved. This used to not be an issue, because inlining wouldn't
recognize these as inlinable anyway. But golang.org/cl/266199 extended
the inlining logic to recognize more cases, but did not notice that
the actual inlining code was discarding side effects.
Issue identified by danscales@.
Fixes#42703.
Change-Id: I95f8fc076b6ca4e9362e80ec26dad9d87a5bc44a
Reviewed-on: https://go-review.googlesource.com/c/go/+/271219
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Within the frontend, we generally don't guarantee uniqueness of
anonymous types. For example, each struct type literal gets
represented by its own types.Type instance.
However, the field tracking code was using the struct type as a map
key. This broke in golang.org/cl/256457, because that CL started
changing the inlined parameter variables from using the types.Type of
the declared parameter to that of the call site argument. These are
always identical types (e.g., types.Identical would report true), but
they can be different pointer values, causing the map lookup to fail.
The easiest fix is to simply get rid of the map and instead use
Node.Opt for tracking the types.Field. To mitigate against more latent
field tracking failures (e.g., if any other code were to start trying
to use Opt on ODOT/ODOTPTR fields), we store this field
unconditionally. I also expect having the types.Field will be useful
to other frontend code in the future.
Finally, to make it easier to test field tracking without having to
run make.bash with GOEXPERIMENT=fieldtrack, this commit adds a
-d=fieldtrack flag as an alternative way to enable field tracking
within the compiler. See also #42681.
Fixes#42686.
Change-Id: I6923d206d5e2cab1e6798cba36cae96c1eeaea55
Reviewed-on: https://go-review.googlesource.com/c/go/+/271217
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
RWMutex provides explicit acquire/release synchronization events to the
race detector to model the mutex. It disables sync events within the
methods to avoid e.g., the atomics from adding false synchronization
events, which could cause false negatives in the race detector.
Change-Id: I5126ce2efaab151811ac264864aab1fa025a4aaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/270865
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
The child in TestPanicSystemstack prints "x\n" and then blocks on a
lock. Receiving those bytes only indicates that the child is _about to
block_. Since we don't have a way to know when it is fully blocked,
sleep a bit to give it time to block. This makes us less likely to lose
the race and signal before the child blocks, which will fail the test as
the stack trace cannot be read from a running G.
Fixes#33626
Change-Id: I8a27b1b114bf75e1e5bcb2a7a33aa69cdbc22f40
Reviewed-on: https://go-review.googlesource.com/c/go/+/268578
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
On FreeBSD >= 11 with a kernel built with COMPAT_FREEBSD11 but not
COMPAT_FREEBSD10, the pipe syscall is not available. Thus, tests using
runtime.pipe fail with ENOSYS. As suggested by Ian, fix this by calling
pipe2(0) in these tests and fall back to pipe() in case of ENOSYS.
Fixes#42659
Change-Id: Ifbb8008884b7901fe87830d162ad326122c5fab9
Reviewed-on: https://go-review.googlesource.com/c/go/+/270917
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously, 'go get' loaded retractions for every module in the build
list, which took a long time and usually wasn't helpful.
This rolls forward CL 269019, which was reverted in CL 270521. The new
revision adds a call to modload.ListModules at the end of 'go get' to
ensure .info files are cached for everything in the build list.
Fixes#42185
Change-Id: I684f66c5e674384d5a0176fbc8317e5530b8a915
Reviewed-on: https://go-review.googlesource.com/c/go/+/270858
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Immediately after a forward Seek, the offset we're writing to is
beyond len(buf)+len(heap):
|<--- buf --->|<--- heap --->|
^
off
If we do a copyHeap at this point, the new heapPos should not be
0:
|<---------- buf ----------->|<-heap->|
^
off
Recompute it.
For #42082.
Change-Id: Icb3e4e1c7bf7d1fd3d76a2e0d7dfcb319c661534
Reviewed-on: https://go-review.googlesource.com/c/go/+/270941
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The shift amount in SRAconst needs to be in the [0,31] range, so stop
MOVWing -1 to SRA in the Rsh lowering rules.
Also see CL 270117.
Passes
$ GOARCH=mips go build -toolexec 'toolstash -cmp' -a std
$ GOARCH=mipsle go build -toolexec 'toolstash -cmp' -a std
Updates #42587
Change-Id: Ib5eb99b82310e404cc2d6f0c619b21b8a15406ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/270558
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The existing code for map index expressions checked the
wrong variable (x rather than key) to see if the index
assignment was correct. Since x.mode was always valid in
that case, type-checking didn't follow the error exit in
case of an incorrect map index expression.
However, since we know the correct map element type
irrespective of the validity of the map key, the existing
code path is preferrable over exiting early via an error
because the map index expression returns a valid type which
then can be used for further type-checking.
Removed the unneeded 'if' statement and added a test case
producing the expected two errors (rather than only one if
we would "correct" the 'if' statement instead).
In summary, this commit adds a test but doesn't change the
behavior of type-checking of map index expressions.
Change-Id: I67845bfaa03600c9400f9a1462d7a68a66921ad4
Reviewed-on: https://go-review.googlesource.com/c/go/+/270658
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Repair the code that generates PC ranges for DWARF inlined routine
instances to insure that if II Y is a child of II X within the inline
tree, X's ranges include the ranges from Y. This is similar to what
we're already doing for DWARF scopes.
Updates #33188.
Change-Id: I9bb552777fcd1ae93dc01872707667ad092b1dd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/248724
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Trust: Than McIntosh <thanm@google.com>
Some rules for PPC64 were checking for a case
where a shift followed by an 'and' of a mask could
be lowered, depending on the format of the mask. The
function to verify if the mask was valid for this purpose
was not checking if the mask was 0 which we don't want to
allow. This case can happen if previous optimizations
resulted in that mask value.
This fixes isPPC64ValidShiftMask to check for a mask of 0 and return
false.
This also adds a codegen testcase to verify it doesn't try to
match the rules in the future.
Fixes#42610
Change-Id: I565d94e88495f51321ab365d6388c01e791b4dbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/270358
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
When linking internally on OpenBSD, dedup libraries treating versioned
and unversioned libraries as equivalents. Versioned libraries are preferred
and are retained over unversioned libraries.
This avoids the situation where the use of cgo results in a DT_NEEDED for a
versioned library (for example, libc.so.96.1), while a dynamic import
specifies an unversioned library (for example, libc.so). Without deduplication
this would result in two DT_NEEDED entries, causing a failure when ld.so
attempts to load the Go binrary.
Updates #36435Fixes#39257
Change-Id: I4a4942f259dece01d97bb51df9e13d67c9f94d34
Reviewed-on: https://go-review.googlesource.com/c/go/+/249978
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
A missed newline was added for one case in CL 162957, but
the parallel no-output case was missed.
Add the missed newline for the second case and update the test to
cover the full line for both cases.
Updates #30263
Change-Id: I02aa523290295a6d409cd68066b45c6990e6fb6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/258758
Reviewed-by: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
A typo caused the validation rule to check against -WL,-O... which is
not a regular flag because the L should be lowercase as in the other
rules. This caused valid linker flags to be rejected and people had to
work around this by filtering their default flags that include, e.g.,
-Wl,-O1 for a simple link optimization.
Fix the typo that wrongly rejected -Wl,-O... but allowed a non-existing
-WL,-O flag.
Change-Id: Ia3bf730f16f5ad98a39d7f17159de17b44075462
GitHub-Last-Rev: 2ec7f2a2b9
GitHub-Pull-Request: golang/go#42631
Reviewed-on: https://go-review.googlesource.com/c/go/+/270278
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
mips SRA/SLL/SRL shift amounts are used mod 32; this change aligns the
XXXconst rules to mask the shift amount by &31.
Passes
$ GOARCH=mips go build -toolexec 'toolstash -cmp' -a std
$ GOARCH=mipsle go build -toolexec 'toolstash -cmp' -a std
Fixes#42587
Change-Id: I6003ebd0bc500fba4cf6fb10254e1b557bf8c48f
Reviewed-on: https://go-review.googlesource.com/c/go/+/270117
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In certain cases, the declkared type of an OpIData is interface{}.
This was not expected (since interface{} is a pair, right?) and
thus caused a crash. What is intended is that these be treated as
a byteptr, so do that instead (this is what happens in 1.15).
Fixes#42568.
Change-Id: Id7c9e5dc2cbb5d7c71c6748832491ea62b0b339f
Reviewed-on: https://go-review.googlesource.com/c/go/+/270057
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
CL 258938 changed the way C to Go calls work such that they now
construct a C struct on the C side for the arguments and space for the
results. Any pointers in the result space must be zeroed, so we just
zero the whole struct.
However, C makes it surprisingly hard to robustly zero any struct
type. We had used a "{0}" initializer, which works in the vast
majority of cases, but fails if the type is empty or effectively
empty.
This CL fixes this by changing how the cgo tool zero-initializes the
argument struct to be more robust.
Fixes#42495.
Change-Id: Id1749b9d751e59eb7a02a9d44fec0698a2bf63cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/269337
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In chansend() and chanrecv() of chan.go, the order of calls to
raceacquire() and racerelease() was swapped, which meant that the
code was not following the memory model "by the letter of the law."
Similar for bufrecv and bufsend in select.go
The memory model says:
- A send happens before the corresponding receive completes, and
- the kth receive on a channel with capacity C happens before the
k+C send on that channel completes.
The operative word here is "completes." For example, a sender obtains
happens-before information on completion of the send-operation, which
means, after the sender has deposited its message onto the channel.
Similarly for receives.
If the order of raceacquire() and racerelease() is incorrect, the race
detector may fail to report some race conditions.
The fix is minimal from the point of view of Go. The fix does, however,
rely on a new function added to TSan:
https://reviews.llvm.org/D76322
This commit only affects execution when race detection is enabled.
Added two tests into `runtime/race/output_test.go`:
- `chanmm` tests for the issue addressed by this patch
- `mutex` is a test for inverted semaphores, which must not be broken
by this (or any other) patch
Fixes#37355
Change-Id: I5e886879ead2bd456a4b7dd1d17253641b767f63
Reviewed-on: https://go-review.googlesource.com/c/go/+/220419
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
These ioctls take a pid_t (generally a C integer aka int32) and not an int64 - we
currently get away with this on little endian 64 bit platforms, since the bytes
fall into the correct place, however this breaks on big endian 64 bit platforms
(like openbsd/mips64).
Update #40995
Change-Id: I622a0543fd562d97f76a7376a84fd2641e6d6a24
Reviewed-on: https://go-review.googlesource.com/c/go/+/267605
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change moves the code in work.(*Builder).cgo that, when there is
an overlay, copies non-Go files to objdir into work.(*Builder).Build,
and creates an overlay structure mapping from the nominal file paths
into the copies in objdir. That's propagated through to
work.(*Builder).ccompile, which will use it to pass in the path to the
overlaid contents in objdir when calling the compiler.
This allows for overlays of C/C++/Fortran files.
For #39958
Change-Id: I9a2e3d3ba6afdf7ce19be1dbf4eee34805cdc05f
Reviewed-on: https://go-review.googlesource.com/c/go/+/266376
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
A hand-edited object file can have a symbol name that uses newline and
other normally invalid characters. The cgo tool will generate Go files
containing symbol names, unquoted. That can permit those symbol names
to inject Go code into a cgo-generated file. If that Go code uses the
//go:cgo_ldflag pragma, it can cause the C linker to run arbitrary
code when building a package. If you build an imported package we
permit arbitrary code at run time, but we don't want to permit it at
package build time. This CL prevents this in two ways.
In cgo, reject invalid symbols that contain non-printable or space
characters, or that contain anything that looks like a Go comment.
In the go tool, double check all //go:cgo_ldflag directives in
generated code, to make sure they follow the existing LDFLAG restrictions.
Thanks to Imre Rad / https://www.linkedin.com/in/imre-rad-2358749b for
reporting this.
Fixes CVE-2020-28367
Change-Id: Ia1ad8f3791ea79612690fa7d26ac451d0f6df7c1
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/895832
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/269658
Trust: Katie Hockman <katie@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TestSetuidEtc() was failing sporadically on linux-ppc64. From the
three https://build.golang.org/ logs, it looked like the logged
errors could be associated with threads dying, but proc reads
were, in some way, racing with their demise.
Exploring ways to increase thread demise, revealed that races
of this type can happen on non-ppc64 systems, and that
os.IsNotExist(err) was not a sufficient error condition test
for a thread's status file disappearing. This change includes a
fix for that to.
The actual issue on linux-ppc64 appears to be tied to PID reaping
and reuse latency on whatever the build test environment is for
linux-ppc64-buildlet. I suspect this can happen on any linux
system, however, especially where the container has a limited PID
range.
The fix for this, limited to the test (the runtime syscall support
is unchanged), is to confirm that the Pid for the interrogated
thread's /proc/<TID>/status file confirms that it is still
associated with the test-process' PID.
linux-ppc64-buildlet:
go/bin/go test syscall -run=TestSetuidEtc -count=10000
ok syscall 104.285s
Fixes#42462
Change-Id: I55c84ab8361003570a405fa52ffec4949bf91113
Reviewed-on: https://go-review.googlesource.com/c/go/+/268717
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Store the PC instead of the string name of the function, and defer
that conversion until we need it.
Helper is still relatively expensive in CPU time (few hundred ns),
but memory allocation is now constant for a test rather than linear in
the number of times Helper is called.
benchstat:
name old time/op new time/op delta
TBHelper-4 1.30µs ±27% 0.53µs ± 1% -59.03% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
TBHelper-4 216B ± 0% 0B -100.00% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
TBHelper-4 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5)
Change-Id: I6565feb491513815e1058637d086b0374fa94e19
GitHub-Last-Rev: c2329cf225
GitHub-Pull-Request: golang/go#38834
Reviewed-on: https://go-review.googlesource.com/c/go/+/231717
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
This cl is a roll-forward of golang.org/cl/265758, which was rolled back
in golang.org/cl/268900. The changes made are removing cgofiles
from the list of files that are copied to objdir (because the cgofiles
themselves aren't actually provided to the compiler) and fixing test
cases to properly provide the overlay flag and to allow for paths with
backslashes (as in Windows).
The previous cl (golang.org/cl/262618) copied non-overlaid cgo files
to objdir, mostly to get around the issue that otherwise cgo-generated
files were written out with the wrong names (they'd get the base path
of the overlay file containing the replaced contents, instead of the
base path of the path whose contents are being replaced). So that CL
it would copy the files to objdir with the base path of the file
being replaced to circumvent that.
This CL changes cmd/go and cmd/cgo so that instead of copying
files, it passes the actual path of the file on disk either of
the original file (if it is not overlaid) or its replacement
file (if it is) as well as a flag --path_rewrite, newly added to
cmd/cgo, that specifies the actual original file path that corresponds
to the replaced files.
Updates #39958
Change-Id: Ia45b022f9d27cfce0f9ec6da5f3a9f53654c67b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/269017
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The comment explains differences between WalkDirFunc and WalkFunc,
but when this code moved out of path/filepath, we forgot to change
the reference to be filepath.WalkFunc. Fix that.
(The text should not be deleted, because path/filepath does not
contain this type - WalkDirFunc - nor this text anymore.)
Pointed out by Carl Johnson on CL 243916 post-submit.
For #41190.
Change-Id: I44c64d0b7e60cd6d3694cfd6d0b95468ec4612fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/268417
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The Go 1.16 code freeze has recently started. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
Those versions have already gone through code review, and now they
will undergo additional testing during the upcoming freeze period.
If new issues in these dependencies are discovered, we have the freeze
period to address them. By the end of the freeze period, we will have
confidence that the Go 1.16 release and the dependency versions it has
selected are robust.
The dependency module versions that are selected in this commit are:
github.com/google/pprof v0.0.0-20201007051231-1066cbb265c7
github.com/ianlancetaylor/demangle v0.0.0-20200414190113-039b1ae3a340
golang.org/x/arch v0.0.0-20201008161808-52c3e6f60cff
golang.org/x/crypto v0.0.0-20201016220609-9e8e0b390897
golang.org/x/mod v0.3.1-0.20200828183125-ce943fd02449
golang.org/x/net v0.0.0-20201029221708-28c70e62bb1d
golang.org/x/sys v0.0.0-20201110211018-35f3e6cf4a65
golang.org/x/text v0.3.4
golang.org/x/tools v0.0.0-20201110201400-7099162a900a
golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1
This change was created with a program from CL 256357 patch set 3
(which updates golang.org/x modules only) and the latest bundle tool,
but replacing golang.org/x/net version with a slightly older commit
golang/net@28c70e62bb due to #42498:
$ updatestd -goroot=$HOME/gotip -branch=master
> go version
go version devel +ecc3f5112e Thu Nov 5 23:21:33 2020 +0000 darwin/amd64
> go env GOROOT
/Users/dmitshur/gotip
> go version -m /Users/dmitshur/go/bin/bundle
/Users/dmitshur/go/bin/bundle: go1.15.4
path golang.org/x/tools/cmd/bundle
mod golang.org/x/tools v0.0.0-20201110201400-7099162a900a h1:5E6TPwSBG74zT8xSrVc8W59K4ch4NFobVTnh2BYzHyU=
dep golang.org/x/mod v0.3.0 h1:RM4zey1++hCTbCVQfnWeKs9/IEsaBLA8vTkd0WVtmH4=
dep golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
updating module cmd in /Users/dmitshur/gotip/src/cmd
skipping github.com/chzyer/logex (out of scope, it's not a golang.org/x dependency)
skipping github.com/chzyer/readline (out of scope, it's not a golang.org/x dependency)
skipping github.com/chzyer/test (out of scope, it's not a golang.org/x dependency)
skipping github.com/google/pprof (out of scope, it's not a golang.org/x dependency)
skipping github.com/ianlancetaylor/demangle (out of scope, it's not a golang.org/x dependency)
skipping github.com/yuin/goldmark (out of scope, it's not a golang.org/x dependency)
skipping rsc.io/pdf (out of scope, it's not a golang.org/x dependency)
> go mod edit -go=1.16
> go get -d golang.org/x/arch@52c3e6f60cffa0133a3f9b2fc7f6862504a6cba0 golang.org/x/crypto@9e8e0b390897c84cad53ebe9ed2d1d331a5394d9 golang.org/x/mod@ce943fd02449f621243c9ea6e64098e84752b92b golang.org/x/net@28c70e62bb1d140c3f2579fb7bb5095134d9cb1e golang.org/x/sync@67f06af15bc961c363a7260195bcd53487529a21 golang.org/x/sys@35f3e6cf4a65a85bc280e5fe63faed8ac8b25721 golang.org/x/text@22f1617af38ed4cd65b3b96e02bab267e560155c golang.org/x/tools@7099162a900ae8260c5b97cfaf5f374243dfa742 golang.org/x/xerrors@5ec99f83aff198f5fbd629d6c8d8eb38a04218ca
> go mod tidy
> go mod vendor
updating module std in /Users/dmitshur/gotip/src
> go mod edit -go=1.16
> go get -d golang.org/x/crypto@9e8e0b390897c84cad53ebe9ed2d1d331a5394d9 golang.org/x/net@28c70e62bb1d140c3f2579fb7bb5095134d9cb1e golang.org/x/sys@35f3e6cf4a65a85bc280e5fe63faed8ac8b25721 golang.org/x/text@22f1617af38ed4cd65b3b96e02bab267e560155c golang.org/x/tools@7099162a900ae8260c5b97cfaf5f374243dfa742
> go mod tidy
> go mod vendor
updating bundles in /Users/dmitshur/gotip/src
> go generate -run=bundle std cmd
golang.org/x/net will be updated further later, after #42498 is fixed.
github.com/google/pprof and github.com/ianlancetaylor/demangle
contribute packages but are out of scope for this generated CL.
Also rename http2configureTransport in net/http to follow the internal
rename that happened in CL 264017 to fix the build.
For #36905.
Updates #41721.
Updates #42498.
Change-Id: Ifcd2e76f0406e389b6db88041ca51cd0a2115152
Reviewed-on: https://go-review.googlesource.com/c/go/+/266898
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
This is an extra variable available via 'go env', but not read from the
user's environment. It corresponds to the same string that
runtime.Version returns, assuming a program is built by the same version
of Go.
It's similar to the output of 'go version', but without the "go version"
prefix nor the "$GOOS/$GOARCH" suffix.
The main use case here is tools, which often use 'go env' to query basic
information about the installed Go tree. Its version was one missing
piece of information, which required an extra call to 'go version'
before this change.
Fixes#41116.
Change-Id: I5c9d8c2ba856c816c9f4c462ba73c907b3441445
Reviewed-on: https://go-review.googlesource.com/c/go/+/265637
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
The previous cl (golang.org/cl/262618) copied non-overlaid cgo files
to objdir, mostly to get around the issue that otherwise cgo-generated
files were written out with the wrong names (they'd get the base path
of the overlay file containing the replaced contents, instead of the
base path of the path whose contents are being replaced). So that CL
it would copy the files to objdir with the base path of the file
being replaced to circumvent that.
This CL changes cmd/go and cmd/cgo so that instead of copying
files, it passes the actual path of the file on disk either of
the original file (if it is not overlaid) or its replacement
file (if it is) as well as a flag --path_rewrite, newly added to
cmd/cgo, that specifies the actual original file path that corresponds
to the replaced files.
Updates #39958
Change-Id: Ic4aae5ef77fe405011fcdce7f6c162488d13daa2
Reviewed-on: https://go-review.googlesource.com/c/go/+/265758
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
SYNC is supposed to correspond to 'fast-BCR-serialization' which is
encoded as 'bcr 14,0'. In CL 197178 I accidentally modified the
encoding to 'bcr 7,0' which is a no-op. This CL reverses that change.
Fixes#42479.
Change-Id: I9918d93d720f5e12acc3014cde20d2d32cc87ee5
Reviewed-on: https://go-review.googlesource.com/c/go/+/268797
Run-TryBot: Michael Munday <mike.munday@ibm.com>
Trust: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
https://man7.org/linux/man-pages/man2/copy_file_range.2.html#VERSIONS states:
A major rework of the kernel implementation occurred in 5.3. Areas
of the API that weren't clearly defined were clarified and the API
bounds are much more strictly checked than on earlier kernels.
Applications should target the behaviour and requirements of 5.3
kernels.
Rather than attempting to detect the file system for source and
destination files (which means two additional statfs syscalls) and skip
copy_file_range in case of known defects (e.g. CIFS -> CIFS), just
assume copy_file_range to be broken on kernels < 5.3.
Fixes#42400
Change-Id: I3a531296182c1d6e341772cc9d2be5bf83e52575
Reviewed-on: https://go-review.googlesource.com/c/go/+/268338
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
test_race_install checks that 'go test -i -race …' does not rebuild
already installed packages, by also passing '-v' and verifying that no
package names are printed to stderr.
CL 266368 added a deprecation message for the '-i' flag that caused
the stderr output to be non-empty, although it still does not print
any package names.
Updates #41696
Change-Id: I13e10e49b7c33139be9b13f24cb393c9f58fd85d
Reviewed-on: https://go-review.googlesource.com/c/go/+/268581
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
When either the server or client are lacking hardware support for
AES-GCM ciphers, indicated by the server lacking the relevant
instructions and by the client not putting AES-GCM ciphers at the top
of its preference list, reorder the preference list to de-prioritize
AES-GCM based ciphers when they are adjacent to other AEAD ciphers.
Also updates a number of recorded openssl TLS tests which previously
only specified TLS 1.2 cipher preferences (using -cipher), but not
TLS 1.3 cipher preferences (using -ciphersuites), to specify both
preferences, making these tests more predictable.
Fixes#41181.
Change-Id: Ied896c96c095481e755aaff9ff0746fb4cb9568e
Reviewed-on: https://go-review.googlesource.com/c/go/+/262857
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
This reverts commit 3a81338622.
Reason for revert: Some edge cases not properly covered due to changes within runtime traceback generation since 2017, that need to be examined. This change landed very late in the Go1.16 cycle.
Change-Id: I8cf6f46ea0ef6161d878e79943e6c7cdac94bccf
Reviewed-on: https://go-review.googlesource.com/c/go/+/268577
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This code was preserved just to do side-by-side testing while
transitioning to the Go implementation. There haven't been mismatch
issues, so drop the cgo code, which was making it hard to improve the Go
code without diverging.
Change-Id: I2a23039c31a46e88b94250aafbc98d4ea8daf22f
Reviewed-on: https://go-review.googlesource.com/c/go/+/232397
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a SHALL in RFC 7301, Section 3.2.
Also some more cleanup after NPN, which worked the other way around
(with the possibility that the client could pick a protocol the server
did not suggest).
Change-Id: I83cc43ca1b3c686dfece8315436441c077065d82
Reviewed-on: https://go-review.googlesource.com/c/go/+/239748
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This is a roll-forward of golang.org/cl/267197, which was reverted in
golang.org/cl/267357. It makes the following changes in addition to
the ones in the next paragraph: It avoids outputting trimpath
arguments for an overlay unless the overlay affects the package being
compiled (to avoid hitting windows command line argument limits), and
it fixes processing of regexps in the script test framework to treat
the first *non flag* argument to grep, stdout, and stderr as a regexp,
not just the first argument.
golang.org/cl/267917 was a roll-forward of golang.org/cl/262618, which
was reverted in golang.org/cl/267037. The only differences between
this CL and the original were the three calls to fflush from the C
files in build_overlay.txt, to guarantee that the string we were
expecting was
actually written out.
The CL requires rewriting the paths of the files passed to the cgo
tool toolchain to use the overlaid paths instead of the disk paths of
files. Because the directories of the overlaid paths don't exist in
general, the cgo tool have been updated to run in base.Cwd instead of
the package directory.
For #39958
Change-Id: I1bd96db257564bcfd95b3502aeca14d04bd28618
Reviewed-on: https://go-review.googlesource.com/c/go/+/267797
Trust: Michael Matloob <matloob@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Adds the (*tls.Conn).HandshakeContext method. This allows
us to pass the context provided down the call stack to
eventually reach the tls.ClientHelloInfo and
tls.CertificateRequestInfo structs.
These contexts are exposed to the user as read-only via Context()
methods.
This allows users of (*tls.Config).GetCertificate and
(*tls.Config).GetClientCertificate to use the context for
request scoped parameters and cancellation.
Replace uses of (*tls.Conn).Handshake with (*tls.Conn).HandshakeContext
where appropriate, to propagate existing contexts.
Fixes#32406
Change-Id: I33c228904fe82dcf57683b63627497d3eb841ff2
Reviewed-on: https://go-review.googlesource.com/c/go/+/246338
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Previously windows only returned the certificate-chain with the highest quality.
This change makes it so chains with a potentially lower quality
originating from other root certificates are also returned by verify.
Tests in verify_test flagged with systemLax are now allowed to pass if the system returns additional chains
Fixes#40604
Change-Id: I66edc233219f581039d47a15f2200ff627154691
Reviewed-on: https://go-review.googlesource.com/c/go/+/257257
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Without HOME or FOSSIL_HOME set, this test fails for me when run with
fossil 2.12.1.
Also verify that the 'go get' command produces an executable, which
helps to verify that the files extracted by fossil are not corrupted.
Updates #42323
Change-Id: Ie6f5d2eab6a6338e997a4f85591195e5bd9a0d37
Reviewed-on: https://go-review.googlesource.com/c/go/+/267884
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Adds the following additional convenience fields to CertificateRequest:
* KeyUsage
* ExtKeyUsage
* UnknownExtKeyUsage
* IsCA
* MaxPathLen
* BasicConstraintsValid
* MaxPathLenZero
* SubjectKeyId
* PolicyIdentifier
These fields are parsed during ParseCertificateRequest and marshalled
during CreateCertificateRequest. The parsing/marshalling code is
factored out of parseCertificate and buildExtensions (which is renamed
buildCertExtensions). This has the side effect of making these methods
somewhat easier to read.
Documentation for the fields is copied from Certificate.
Example CSR created with all of these fields parsed with openssl:
$ openssl req -in ~/test-csr.pem -noout -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject:
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:a4:cb:64:35:8e:dd:8c:2b:a6:f1:aa:39:d1:be:
d0:b9:95:1e:59:19:82:76:28:d3:85:1b:c6:88:62:
e1:15:33:be:26:18:80:14:fe:f4:d4:91:66:4e:a4:
a4:47:bd:53:db:f7:2e:e3:31:ce:5f:86:cb:92:59:
93:bb:d0:7f:a2
ASN1 OID: prime256v1
NIST CURVE: P-256
Attributes:
Requested Extensions:
X509v3 Key Usage: critical
Certificate Sign
X509v3 Extended Key Usage:
Any Extended Key Usage, 1.2.3
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Subject Key Identifier:
01:02:03
X509v3 Certificate Policies:
Policy: 1.2.3
Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:a7:88:e5:96:d4:ad:ae:24:26:ab:5f:15:6a:
3f:22:6d:0e:a6:ba:15:64:8d:78:34:f4:c4:7d:ac:37:b0:2a:
84:02:20:68:44:f0:8e:8a:1b:c1:68:be:14:a6:e3:83:41:fd:
2d:cc:00:aa:bc:50:f6:50:56:12:9e:a4:09:84:5c:bf:c1
Fixes#37172
Change-Id: Ife79d01e203827ef0ac3c787aa13c00d0751a1ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/233163
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
When a variable symbol is both imported (possibly through
inlining) and linkname'd, make sure its LSym is marked as
non-package for symbol indexing in the object file, so it is
resolved by name and dedup'd with the original definition.
Fixes#42401.
Change-Id: I8e90c0418c6f46a048945c5fdc06c022b77ed68d
Reviewed-on: https://go-review.googlesource.com/c/go/+/268178
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
The go command runs commands like git and hg to download modules.
In the past, we have had problems with security bugs in version
control systems becoming security bugs in “go get”.
The original modules draft design removed use of these commands
entirely, saying:
> We want to move away from invoking version control tools such as bzr,
> fossil, git, hg, and svn to download source code. These fragment the
> ecosystem: packages developed using Bazaar or Fossil, for example, are
> effectively unavailable to users who cannot or choose not to install
> these tools. The version control tools have also been a source of
> exciting security problems. It would be good to move them outside the
> security perimeter.
The removal of these commands was not possible in the end: being able
to fetch directly from Git repos is too important, especially for
closed source. But the security exposure has not gone away.
We remain vulnerable to problems in VCS systems, especially the less
scrutinized ones.
This change adds a GOVCS setting to let users control which version
control systems are allowed by default.
It also changes the default allowed version control systems to git and hg
for public code and any version control system for private code
(import path or module path matched by the GOPRIVATE setting).
See the changes in alldocs.go for detailed documentation.
See #41730 for proposal and discussion.
Fixes#41730.
[Replay of CL 266420. See changes from Patch Set 1 for updates to fix
a few long tests.]
Change-Id: I4fe93804548956c42aea985368b4571bdb220f48
Reviewed-on: https://go-review.googlesource.com/c/go/+/267888
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Extended the sorting logic to be stable even when there are two roots
with the same name and notBefore timestamp, like the GlobalSign ones.
Updates #38843
Change-Id: Ie4db0bb8b6a8b5ffbb7390b6bd527fc0c3badaca
Reviewed-on: https://go-review.googlesource.com/c/go/+/266677
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Currently, the benchmark output from the testing package prints small
values with three significant figures. This means it can only
distinguish 1 part in 100, or a 1% error, which can be enough to throw
off further analysis of the output. This CL increases it to four
significant figures. For time values, at least, anything beyond four
significant figures is almost certainly noise.
Fixes#34626.
Change-Id: I3bcf305427130026276e6a4c78167989319f280c
Reviewed-on: https://go-review.googlesource.com/c/go/+/267102
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Instead of parsing the PEM files and then storing the *Certificate
values forever, still parse them to see if they're valid and pick out
some fields, but then only store the decoded pem.Block.Bytes until
that cert is first needed.
Saves about 500K of memory on my (Debian stable) machine after doing a
tls.Dial or calling x509.SystemCertPool.
A more aggressive version of this is still possible: we can not keep
the pem.Block.Bytes in memory either, and re-read them from disk when
necessary. But dealing with files disappearing and even large
multi-cert PEM files changing (with offsets sliding around) made this
conservative version attractive. It doesn't change the
slurp-roots-on-startup semantics. It just does so with less memory
retained.
Change-Id: I3aea333f4749ae3b0026042ec3ff7ac015c72204
Reviewed-on: https://go-review.googlesource.com/c/go/+/230025
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
This will allow building CertPools that consume less memory. (Most
certs are never accessed. Different users/programs access different
ones, but not many.)
This CL only adds the new internal mechanism (and uses it for the
old AddCert) but does not modify any existing root pool behavior.
(That is, the default Unix roots are still all slurped into memory as
of this CL)
Change-Id: Ib3a42e4050627b5e34413c595d8ced839c7bfa14
Reviewed-on: https://go-review.googlesource.com/c/go/+/229917
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
CL 244579 added guard clauses to prevent a faulty state that was
possible under the incorrect logic of the uniquePred loop in
addLocalInductiveFacts. That faulty state was still making the
intended optimization, but not for the correct reason.
Removing the faulty state also removed the overly permissive application
of the optimization, and therefore made these two tests fail.
We disabled the tests of this optimization in CL 244579 to allow us to
quickly apply the fix in the CL. This CL now corrects the logic of the
uniquePred loop in order to apply the optimization correctly.
The comment above the uniquePred loop says that it will follow unique
predecessors until it reaches a join point. Without updating the child
node on each iteration, it cannot follow the chain of unique
predecessors more than one step. Adding the update to the child node
on each iteration of the loop allows the logic to follow the chain of
unique predecessors until reaching a join point (because a non-unique
predecessor will signify a join point).
Updates #40502.
Change-Id: I23d8367046a2ab3ce4be969631f9ba15dc533e6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/246157
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
This CL makes it so that instead of printing massive stack traces during
endless recursion, which spams users and aren't useful, it now prints out
the top and bottom 50 frames. If the number of frames <= 100
(_TracebackMaxFrames), we'll just print all the frames out.
Modified gentraceback to return counts of:
* ntotalframes
* nregularframes
which allows us to get accurate counts of the various kinds of frames.
While here, also fixed a bug that resulted from CL 37222, in which we
no longer accounted for decrementing requested frame skips, and assumed
that when printing, that skip would always be 0. The fix is instead to add
precondition that we'll only print if skip <= 0, but also decrement skip
as we iterate.
Fixes#7181.
Fixes#24628.
Change-Id: Ie31ec6413fdfbe43827b254fef7d99ea26a5277f
Reviewed-on: https://go-review.googlesource.com/c/go/+/37222
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
This CL adds support for inlining type switches, including exporting
and importing them.
Type switches are represented mostly the same as expression switches.
However, if the type switch guard includes a short variable
declaration, then there are two differences: (1) there's an ONONAME
(in the OTYPESW's Left) to represent the overall pseudo declaration;
and (2) there's an ONAME (in each OCASE's Rlist) to represent the
per-case variables.
For simplicity, this CL simply writes out each variable separately
using iimport/iiexport's normal Vargen mechanism for disambiguating
identically named variables within a function. This could be improved
somewhat, but inlinable type switches are probably too uncommon to
merit the complexity.
While here, remove "case OCASE" from typecheck1. We only type check
"case" clauses as part of a "select" or "switch" statement, never as
standalone statements.
Fixes#37837
Change-Id: I8f42f6c9afdd821d6202af4a6bf1dbcbba0ef424
Reviewed-on: https://go-review.googlesource.com/c/go/+/266203
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
This commit is a copy of filepath.WalkDir adapted to use fs.FS
instead of the native OS file system. It is the last implementation
piece of the io/fs proposal.
The original io/fs proposal was to adopt filepath.Walk, but we
have since introduced the more efficient filepath.WalkDir (#42027),
so this CL adopts that more efficient option instead.
(The changes in path/filepath bring the two copies more in line
with each other. The main change is unembedding the field
in statDirEntry, so that the fs.DirEntry passed to the WalkDirFunc
for the root of the tree does not have any extra methods.)
For #41190.
Change-Id: I9359dfcc110338c0ec64535f22cafb38d0b613a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/243916
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>
WalkDir is like Walk but can use ReadDir to read directories,
instead of Readdirnames + Lstat on every entry,
which is usually a significant performance improvement.
(The Lstat can still happen if the walk function calls d.Info.)
Fixes#42027.
[Replay of CL 266240 after it was reverted due to accidentally
enabling on Windows a test that does not work on Windows.
The original code only ran the test on os.Getuid() > 0.
The rolled-back CL skipped the test on os.Getuid() == 0.
But on Windows, os.Getuid(), it turns out, always returns -1.
So what looked like a test for root was also excluding Windows.
This CL revises the test to skip Windows explicitly.]
Change-Id: I9b3661013d6449b7486532445d934ae91e5393ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/267887
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Optimize combinations of left and right shifts by a constant value
into a 'rotate then insert selected bits [into zero]' instruction.
Use the same instruction for contiguous masks since it has some
benefits over 'and immediate' (not restricted to 32-bits, does not
overwrite source register).
To keep the complexity of this change under control I've only
implemented 64 bit operations for now.
There are a lot more optimizations that can be done with this
instruction family. However, since their function overlaps with other
instructions we need to be somewhat careful not to break existing
optimization rules by creating optimization dead ends. This is
particularly true of the load/store merging rules which contain lots
of zero extensions and shifts.
This CL does interfere with the store merging rules when an operand
is shifted left before it is stored:
binary.BigEndian.PutUint64(b, x << 1)
This is unfortunate but it's not critical and somewhat complex so
I plan to fix that in a follow up CL.
file before after Δ %
addr2line 4117446 4117282 -164 -0.004%
api 4945184 4942752 -2432 -0.049%
asm 4998079 4991891 -6188 -0.124%
buildid 2685158 2684074 -1084 -0.040%
cgo 4553732 4553394 -338 -0.007%
compile 19294446 19245070 -49376 -0.256%
cover 4897105 4891319 -5786 -0.118%
dist 3544389 3542785 -1604 -0.045%
doc 3926795 3927617 +822 +0.021%
fix 3302958 3293868 -9090 -0.275%
link 6546274 6543456 -2818 -0.043%
nm 4102021 4100825 -1196 -0.029%
objdump 4542431 4548483 +6052 +0.133%
pack 2482465 2416389 -66076 -2.662%
pprof 13366541 13363915 -2626 -0.020%
test2json 2829007 2761515 -67492 -2.386%
trace 10216164 10219684 +3520 +0.034%
vet 6773956 6773572 -384 -0.006%
total 107124151 106917891 -206260 -0.193%
Change-Id: I7591cce41e06867ba10a745daae9333513062746
Reviewed-on: https://go-review.googlesource.com/c/go/+/233317
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Michael Munday <mike.munday@ibm.com>
Remove openbsd/mips64 from incomplete ports lists - all of the necessary code
has landed and we want to run tests so we can see/deal with remaining failures.
Update #40995
Change-Id: I5d4f89af82ff3abe57570a9a8abf889498093d32
Reviewed-on: https://go-review.googlesource.com/c/go/+/267606
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When the compiler refers to a runtime builtin, it emits an indexed
symbol reference in the object file via predetermined/preassigned ID
within the PkgIdxBuiltin pseudo-package. At link time when the loader
encounters these references, it redirects them to the corresponding
defined symbol in the runtime package. This redirection process
currently assumes that if a runtime builtin is referenced, we'll
always have a definition for it. This assumption holds in most cases,
however for the builtins "runtime.racefuncenter" and
"runtime.racefuncexit", we'll only see definitions if the runtime
package we're linking against was built with "-race".
In the bug in question, build passes "-gcflags=-race" during
compilation of the main package, but doesn't pass "-race" directly to
'go build', and as a result the final link combines a
race-instrumented main with a non-race runtime; this results in R_CALL
relocations with zero-valued target symbols, resulting in a panic
during stack checking.
This patch changes the loader's resolve method to detect situations
where we're asking for builtin "runtime.X", but the runtime package
read in doesn't contain a definition for X.
Fixes#42396.
Change-Id: Iafd38bd3b0f7f462868d120ccd4d7d1b88b27436
Reviewed-on: https://go-review.googlesource.com/c/go/+/267881
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Tools often need to associate errors not with a single position, but
with a span of source code. For example, gopls currently estimates
diagnostic spans using heuristics to expand the positions reported by
the type checker to surrounding source code. Unfortunately this is often
inaccurate.
This CL lays the groundwork to solve this within go/types by adding a
start and end position to type checker errors. This is an experimental
API, both because we are uncertain of the ideal representation for these
spans and because their initial positioning is naive. In most cases this
CL simply expands errors to the surrounding ast.Node being typechecked,
if available. This might not be the best error span to present to the
user. For these reasons the API is unexported -- gopls can read these
positions using reflection, allowing us to gain experience and improve
them during the next development cycle.
For golang/go#42290
Change-Id: I39a04d70ea2bb2134b4d4c937f32b2ddb4456430
Reviewed-on: https://go-review.googlesource.com/c/go/+/265250
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Test script expects the regexp argument for stdout, stderr, and cmp
to be the first argument after the command, but that might not be the
case if the -q or -count flags are provided. Treat the first argument
after a flag as a regexp instead.
For #39958
Change-Id: I369926109ec10cca8b2c3baca27e7a3f7baf364b
Reviewed-on: https://go-review.googlesource.com/c/go/+/267877
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
startm contains a critical section from when it takes ownership of a P
(either on function entry or call to pidleput) until it wakes the M
receiving the P. If preempted in this critical section, the owned P is
left in limbo. If preempted for a GC stop, there will be nothing to stop
the owned P and STW will wait forever.
golang.org/cl/232298 introduced the first call to startm that is not on
the system stack (via a wakep call), introducing the possibility of
preemption. Disable preemption in startm to ensure this remains
non-preemptible.
Since we're not always on the system stack anymore, we also need to be
careful in allocm.
Updates #42237
Change-Id: Icb95eef9eb262121856485316098331beea045da
Reviewed-on: https://go-review.googlesource.com/c/go/+/267257
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Pratt <mpratt@google.com>
Previously, we resolved each argument to 'go get' to a package path or
module path based on what was in the build list at existing versions,
even if the argument specified a different version explicitly. That
resulted in bugs like #37438, in which we variously resolved the wrong
version or guessed the wrong argument type for what is unambiguously a
package argument at the requested version.
We were also using a two-step upgrade/downgrade algorithm, which could
not only upgrade more that is strictly necessary, but could also
unintentionally upgrade *above* the requested versions during the
downgrade step.
This change instead uses an iterative approach, with an explicit
disambiguation step for the (rare) cases where an argument could match
the same package path in multiple modules. We use a hook in the
package loader to halt package loading as soon as an incorrect version
is found — preventing over-resolving — and verify that the result
after applying downgrades successfully obtained the requested versions
of all modules.
Making 'go get' be correct and usable is especially important now that
we are defaulting to read-only mode (#40728), for which we are
recommending 'go get' more heavily.
While I'm in here refactoring, I'm also reworking the API boundary
between the modget and modload packages. Previously, the modget
package edited the build list directly, and the modload package
accepted the edited build list without validation. For lazy loading
(#36460), the modload package will need to maintain additional
metadata about the requirement graph, so it needs tighter control over
the changes to the build list.
As of this change, modget no longer invokes MVS directly, but instead
goes through the modload package. The resulting API gives clearer
reasons in case of updates, which we can use to emit more useful
errors.
Fixes#37438
Updates #36460
Updates #40728
Change-Id: I596f0020f3795870dec258147e6fc26a3292c93a
Reviewed-on: https://go-review.googlesource.com/c/go/+/263267
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This allows a single QueryPattern call to resolve a path that could be
either a package or a module. It is important to be able to make a
single QueryPattern call — rather than a QueryPattern followed by a
Query for the specific module path — to provide appropriate fallback
behavior: if the proxy returns package results but does not contain a
module result, we don't want to fall back to the next proxy to look
for the (probably-nonexistent) module.
For #37438
Change-Id: I419b8bb3ab4565f443bb5cee9a8b206f453b9801
Reviewed-on: https://go-review.googlesource.com/c/go/+/266657
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
CL 242083 corrected an inaccurate error message related to the
assignability of untyped constant values. Previously the error message
was of the form "cannot convert ... to ...", which is misleading when
there is no explicit conversion in the syntax. The new error message
corrected this to "cannot use ... as ... in ...", but also appended an
inner error message that can be quite verbose. For example:
cannot use "123" (untyped string constant) as int value in assignment:
cannot convert "123" (untyped string constant) to int"
This might be more accurate, but is a regression in readability. Correct
this by only including the inner error message in the rare cases where
it is helpful: if the constant value overflows or is truncated.
For golang/go#22070
Change-Id: I8b8ee6ef713f64facc319894be09398b0b5ea500
Reviewed-on: https://go-review.googlesource.com/c/go/+/267717
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Remove all cpu features from the ARM64 struct that are not initialized
to reduce cache lines used and to avoid those features being
accidentially used without actual detection if they are present.
Add missing option to mask the CPUID feature.
Change-Id: I94bf90c0655de1af2218ac72117ac6c52adfc289
Reviewed-on: https://go-review.googlesource.com/c/go/+/267658
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Trust: Martin Möhrmann <moehrmann@google.com>
Fixes the check for RFC 5322 "obsolete time zone" to ensure
that we correctly extract the entire date from the "T" of the
implied time zone.
Obsolete Time zones come in the form:
* GMT
* PST
* MDT
etc, as per Section 4.3 of RFC 5322,
https://tools.ietf.org/html/rfc5322#section-4.3.
The prior check from CL 117596 erronenously used strings.Index
which selects the first "T", and that meant that dates containing
days "Tue" or "Thu" could not be parsed.
We also now deal with "T" in the CFWS "Comment Folding White Space".
Thus we'll now accept dates:
* Thu, 20 Nov 1997 09:55:06 MDT
* Thu, 20 Nov 1997 09:55:06 MDT (MDT)
* Fri, 21 Nov 1997 09:55:06 MDT (This comment)
* Fri, 21 Nov 1997 09:55:06 MDT (MDT
Fixes#39260
Change-Id: I6d59d99bc4f05a82582c826b5c5a080a25fd999b
Reviewed-on: https://go-review.googlesource.com/c/go/+/235200
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
The go command runs commands like git and hg to download modules.
In the past, we have had problems with security bugs in version
control systems becoming security bugs in “go get”.
The original modules draft design removed use of these commands
entirely, saying:
> We want to move away from invoking version control tools such as bzr,
> fossil, git, hg, and svn to download source code. These fragment the
> ecosystem: packages developed using Bazaar or Fossil, for example, are
> effectively unavailable to users who cannot or choose not to install
> these tools. The version control tools have also been a source of
> exciting security problems. It would be good to move them outside the
> security perimeter.
The removal of these commands was not possible in the end: being able
to fetch directly from Git repos is too important, especially for
closed source. But the security exposure has not gone away.
We remain vulnerable to problems in VCS systems, especially the less
scrutinized ones.
This change adds a GOVCS setting to let users control which version
control systems are allowed by default.
It also changes the default allowed version control systems to git and hg
for public code and any version control system for private code
(import path or module path matched by the GOPRIVATE setting).
See the changes in alldocs.go for detailed documentation.
See #41730 for proposal and discussion.
Fixes#41730.
Change-Id: I1999ddf7445b36a7572965be5897c7a1ff7f4265
Reviewed-on: https://go-review.googlesource.com/c/go/+/266420
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
WalkDir is like Walk but can use ReadDir to read directories,
instead of Readdirnames + Lstat on every entry,
which is usually a significant performance improvement.
(The Lstat can still happen if the walk function calls d.Info.)
Fixes#42027.
Change-Id: Ie11024b23be2656e320d41fd81ff0d8810aa729e
Reviewed-on: https://go-review.googlesource.com/c/go/+/266240
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>
The wrong value for the first reg parameter was selected.
Likewise the wrong opcode was selected. This should match
rlwnm (rrr type), not rlwinm (irr type).
Similarly, fix the optab matching rules so clrlslwi does
not match reg,reg,const,reg arguments. This is not a valid
operand combination for clrlslwi.
Fixes#42368
Change-Id: I4eb16d45a760b9fd3f497ef9863f82465351d39f
Reviewed-on: https://go-review.googlesource.com/c/go/+/267421
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
The refactoring of this code while adding ReadDir stopped
pre-allocating a 100-entry slice for the results.
That seemed like a good idea in general, since many
directories have nowhere near 100 entries, but it had the
side effect of returning a nil slice for an empty directory.
Some “golden” tests that are too sensitive about nil vs not
inside Google broke because Readdirnames(-1) was now
returning nil instead of []string{} on an empty directory.
It seems likely there are other such tests in the wild, and
it doesn't seem worth breaking them.
This commit restores the non-nil-ness of the old result,
without restoring the excessive preallocation.
Fixes#42367.
Change-Id: I2be72030ac703346e859a97c2d4e456fadfce9b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/267637
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>
A recent update of the Fossil SCM application changes
the line prefix when the fossil info command is used.
Instead of the revision hash starting with "uuid:", it has been
changed to "hash:".
Fossil check-in introducing this change:
https://fossil-scm.org/home/info/8ad5e4690854a81a
To support older and new versions, fossilParseStat will
now check for either version of the prefix when attempting
to find the line containing the hash of the desired revision.
Fixes#42323
Change-Id: I6eff49f9989b37b295322a8569e222a1fd02f6e3
GitHub-Last-Rev: f4e6652307
GitHub-Pull-Request: golang/go#42324
Reviewed-on: https://go-review.googlesource.com/c/go/+/267080
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The LDANDx instructions were misleading because they correspond to the
mnemonic LDCLRx as defined in the Arm Architecture Reference Manual for
Armv8. This changes the assembler to use the same mnemonic as the GNU
assembler and the manual.
The instruction has the form:
LDCLRx Rs, (Rb), Rt: *Rb -> Rt, Rs AND NOT(*Rb) -> *Rb
Change-Id: I94ae003e99e817209bba1afe960e612bf3a0b410
Reviewed-on: https://go-review.googlesource.com/c/go/+/267138
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: fannie zhang <Fannie.Zhang@arm.com>
Add a physPageAlignedStack boolean which if set, results in over allocation
by a physical page, the allocation being rounded to physical page alignment
and the unused memory surrounding the allocation being freed again.
OpenBSD/octeon has 16KB physical pages and requires stacks to be physical page
aligned in order for them to be remapped as MAP_STACK. This change allows Go
to work on this platform.
Based on a suggestion from mknyszek in issue #41008.
Updates #40995Fixes#41008
Change-Id: Ia5d652292b515916db473043b41f6030094461d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/266919
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a partial revert of https://go-review.googlesource.com/c/go/+/248219
because we found that a non-trivial amount of code erroneously calls
ParseFloat(s, 10) or even ParseFloat(s, 0) and expects it to work --
before that change was merged, ParseFloat accepted a bitSize of
anything other than 32 or 64 to mean 64 (and ParseComplex was similar).
So revert that behavior to avoid breaking people's code, and add tests
for this.
I may add a vet check to flag ParseFloat(s, not_32_or_64) in a later
change.
See #42297 for more details.
Change-Id: I4bc0156bd74f67a39d5561b6e5fde3f2d20bd622
Reviewed-on: https://go-review.googlesource.com/c/go/+/267319
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previous fix in issue #20929 for adding comment marker does
not check whether string field have // prefix or not.
This commit ensures string field does not contain // before adding
prefix to the line. Test also included in this commit.
Fixes#40992
Change-Id: Ibc5e8ef147eeb2ed732fb9e19815c8b21fcfb2ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/251237
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
The code I wrote in ldmacho.go in CL 266373 was plainly wrong. It
didn't carry rAdd over correctly. Fixed. Also added sign extension
(as ld64 does).
Internal linking with -race mode now works. Enable it.
Updates #38485.
Change-Id: I78aa949687bf6a0987913059059160b018c7560e
Reviewed-on: https://go-review.googlesource.com/c/go/+/267097
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This change modifies the consistent stats implementation to keep the
per-P sequence counter on each P instead of each mcache. A valid mcache
is not available everywhere that we want to call e.g. allocSpan, as per
issue #42339. By decoupling these two, we can add a mechanism to allow
contexts without a P to update stats consistently.
In this CL, we achieve that with a mutex. In practice, it will be very
rare for an M to update these stats without a P. Furthermore, the stats
reader also only needs to hold the mutex across the update to "gen"
since once that changes, writers are free to continue updating the new
stats generation. Contention could thus only arise between writers
without a P, and as mentioned earlier, those should be rare.
A nice side-effect of this change is that the consistent stats acquire
and release API becomes simpler.
Fixes#42339.
Change-Id: Ied74ab256f69abd54b550394c8ad7c4c40a5fe34
Reviewed-on: https://go-review.googlesource.com/c/go/+/267158
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change moves the responsibility of throwing if an mcache is not
available to the caller, because the inlining cost of throw is set very
high in the compiler. Even if it was reduced down to the cost of a usual
function call, it would still be too expensive, so just move it out.
This choice also makes sense in the context of #42339 since we're going
to have to handle the case where we don't have an mcache to update stats
in a few contexts anyhow.
Also, add getMCache to the list of functions that should be inlined to
prevent future regressions.
getMCache is called on the allocation fast path and because its not
inlined actually causes a significant regression (~10%) in some
microbenchmarks.
Fixes#42305.
Change-Id: I64ac5e4f26b730bd4435ea1069a4a50f55411ced
Reviewed-on: https://go-review.googlesource.com/c/go/+/267157
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a roll-forward of golang.org/cl/262618, which was reverted in
golang.org/cl/267037. The only differences between this CL and the
original are the three calls to fflush from the C files in
build_overlay.txt, to guarantee that the string we're expecting is
actually written out.
This requires rewriting the paths of the files passed to the cgo tool
toolchain to use the overlaid paths instead of the disk paths of
files. Because the directories of the overlaid paths don't exist in
general, the cgo tool have been updated to run in base.Cwd instead of
the package directory.
For #39958
Change-Id: If7e5e057c62c0c22ddb724f9fe650902fc5f4832
Reviewed-on: https://go-review.googlesource.com/c/go/+/267197
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Michael Matloob <matloob@golang.org>
In Go 1.12, we changed the runtime to use MADV_FREE when available on
Linux (falling back to MADV_DONTNEED) in CL 135395 to address issue
#23687. While MADV_FREE is somewhat faster than MADV_DONTNEED, it
doesn't affect many of the statistics that MADV_DONTNEED does until
the memory is actually reclaimed under OS memory pressure. This
generally leads to poor user experience, like confusing stats in top
and other monitoring tools; and bad integration with management
systems that respond to memory usage.
We've seen numerous issues about this user experience, including
#41818, #39295, #37585, #33376, and #30904, many questions on Go
mailing lists, and requests for mechanisms to change this behavior at
run-time, such as #40870. There are also issues that may be a result
of this, but root-causing it can be difficult, such as #41444 and
#39174. And there's some evidence it may even be incompatible with
Android's process management in #37569.
This CL changes the default to prefer MADV_DONTNEED over MADV_FREE, to
favor user-friendliness and minimal surprise over performance. I think
it's become clear that Linux's implementation of MADV_FREE ultimately
doesn't meet our needs. We've also made many improvements to the
scavenger since Go 1.12. In particular, it is now far more prompt and
it is self-paced, so it will simply trickle memory back to the system
a little more slowly with this change. This can still be overridden by
setting GODEBUG=madvdontneed=0.
Fixes#42330 (meta-issue).
Fixes#41818, #39295, #37585, #33376, #30904 (many of which were
already closed as "working as intended").
Change-Id: Ib6aa7f2dc8419b32516cc5a5fc402faf576c92e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/267100
Trust: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Steps run:
$ cd $(go env GOROOT)/src
$ go get -d golang.org/x/sys
$ go mod tidy
$ go mod vendor
$ go generate syscall/... internal/syscall/...
$ cd cmd
$ go get -d golang.org/x/sys
$ go mod tidy
$ go mod vendor
$ cd ..
$ git add .
This change subsumes CL 260860.
For #36905
Change-Id: I7c677c6aa1ad61b9cbd8cf9ed208ed5a30f29c87
Reviewed-on: https://go-review.googlesource.com/c/go/+/267103
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Adjust mksyscall_windows.go to activate module mode and set
-mod=readonly, and to suppress its own deprecation warning when run
from within GOROOT/src.
We can't vendor the mkwinsyscall tool in to the std module directly,
because std-vendored dependencies (unlike the dependencies of all
other modules) turn into actual, distinct packages in 'std' when
viewed from outside the 'std' module. We don't want to introduce a
binary in the 'std' meta-pattern, but we also don't particularly want
to add more special-cases to the 'go' command right now when we have
an existing wrapper program that can do the job.
I also regenerated the affected packages to ensure that they are
consistent with the current version of mksyscall, which produced some
declaration-order changes in
internal/syscall/windows/zsyscall_windows.go.
Fixes#41916
Updates #25922
Change-Id: If6e6f8ba3dd372a7ecd6820ee6c0ca38d55f0f35
Reviewed-on: https://go-review.googlesource.com/c/go/+/261499
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
We already remove racefuncenter and racefuncexit if they are not
needed (i.e. the function doesn't have any other race calls).
racefuncenterfp is like racefuncenter but used on LR machines.
Remove unnecessary racefuncenterfp as well.
Change-Id: I65edb00e19c6d9ab55a204cbbb93e9fb710559f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/267099
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Optimize small (s <= 32) zeroing/moving operations on riscv64.
Avoid generating unaligned memory accesses.
The code is almost one to one translation of the corresponding
mips64 rules with additional rule for s=32.
Change-Id: I753b0b8e53cb9efcf43c8080cab90f3d03539fb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/266217
Reviewed-by: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Add "go/analysis/passes/testinggoroutine" from x/tools and vendor its source in.
This pass will catch misuses of:
* testing.T.Fail*
* testing.T.Fatal*
* testing.T.Skip*
inside goroutines explicitly started by the go keyword.
The pass was implemented in CL 212920.
While here, found 2 misuses in:
* database/sql/sql_test.go
* runtime/syscall_windows_test.go
and fixed them in CL 235527.
Fixes#5746
Change-Id: I1740ad3f1d677bb5d78dc5d8d66bac6ec287a2b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/235677
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
In golang.org/cl/266199, I reused the existing code in inlining that
recognizes anonymous variables. However, it turns out that code
mistakenly recognizes anonymous return parameters as named when
inlining a function from the same package.
The issue is funcargs (which is only used for functions parsed from
source) synthesizes ~r names for anonymous return parameters, but
funcargs2 (which is only used for functions imported from export data)
does not.
This CL fixes the behavior so that anonymous return parameters are
handled identically whether a function is inlined within the same
package or across packages. It also adds a proper cross-package test
case demonstrating #33160 is fixed in both cases.
Change-Id: Iaa39a23f5666979a1f5ca6d09fc8c398e55b784c
Reviewed-on: https://go-review.googlesource.com/c/go/+/266719
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
(*Process).Signal returns an error sentinel, previously errFinished,
when (*Process).done or syscall.ESRCH. Callers would like the ability to
test for this state, so the value has been exported as ErrProcessDone.
Fixes#39444
Change-Id: I510e7647cc032af290180de5149f35ab7b09a526
Reviewed-on: https://go-review.googlesource.com/c/go/+/242998
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Sign extension for consts is unnecessary and zero extension for consts can be avoided
via casts. This removes over 16,000 instructions from the Go binary, in part because it
allows for better zero const absorbtion in blocks - for example,
`(BEQ (MOVBU (MOVBconst [0])) cond yes no)` now becomes `(BEQZ cond yes no)` when
this change is combined with existing rules.
Change-Id: I27e791bfa84869639db653af6119f6e10369ba3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/265041
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This requires rewriting the paths of the files passed to the cgo tool
toolchain to use the overlaid paths instead of the disk paths of
files. Because the directories of the overlaid paths don't exist in
general, the cgo tool have been updated to run in base.Cwd instead of
the package directory.
For #39958
Change-Id: I8986de889f56ecc2e64fa69f5f6f29fa907408f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/262618
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
cmd/cgo now has a -trimpath flag that behaves the same as the
-trimpath flag to cmd/compile. This will be used to correct paths
to cgo files that are overlaid.
The code that processes trimpath in internal/objapi has been slightly
refactored because it's currently only accessible via AbsFile, which
does some additional processing to the path names. Now an
ApplyRewrites function is exported that just applies the trimpath
rewrites.
Also remove unused srcfile argument to cmd/cgo.(*Package).godefs.
For #39958
Change-Id: I497d48d0bc2fe1f6ab2b5835cbe79f15b839ee59
Reviewed-on: https://go-review.googlesource.com/c/go/+/266358
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Changed fmt.go to print out some extra information for various kinds of
Nodes. This includes some extra (small) info in the %j (jconv) output,
and some missing sections (such as Dcls and the body of a closure) in
nodedump().
Also, added some extra doc comments for a few Node types in syntax.go
Change-Id: I2ec7184e2abe0d5fbe3fb5a2506da7c7b06f2fb1
Reviewed-on: https://go-review.googlesource.com/c/go/+/266437
Run-TryBot: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently worldsema is not released with direct handoff, so the
semaphore is an unfair synchronization mechanism. If, for example,
ReadMemStats is called in a loop, it can continuously stomp on attempts
by the GC to stop the world.
Note that it's specifically possible for ReadMemStats to delay a STW to
end GC since ReadMemStats is able to STW during a GC since #19112 was
fixed.
While this particular case is unlikely and the right answer in most
applications is to simply not call such an expensive operation in a
loop, this pattern is used often in tests.
Fixes#40459.
Change-Id: Ia4a54f0fd956ea145a319f9f06c4cd37dd52fd8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/243977
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: David Chase <drchase@google.com>
We use systemstack on the locking path to avoid stack splits which could
cause locks to be recorded out of order (see comment on lockWithRank).
This concern is irrelevant on lock assertions, where we simply need to
see if a lock is held and don't care if another is taken in the
meantime. Thus we can simply drop these unless we actually need to
crash.
Updates #40677
Change-Id: I85d730913a59867753ee1ed0386f8c5efda5c432
Reviewed-on: https://go-review.googlesource.com/c/go/+/266718
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
Some functions that required holding the heap lock _or_ world stop have
been simplified to simply requiring the heap lock. This is conceptually
simpler and taking the heap lock during world stop is guaranteed to not
contend. This was only done on functions already called on the
systemstack to avoid too many extra systemstack calls in GC.
Updates #40677
Change-Id: I15aa1dadcdd1a81aac3d2a9ecad6e7d0377befdc
Reviewed-on: https://go-review.googlesource.com/c/go/+/250262
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
Stopping the world is an implicit lock for many operations, so we should
assert the world is stopped in functions that require it.
This is enabled along with the rest of lock ranking, though it is a bit
orthogonal and likely cheap enough to enable all the time should we
choose.
Requiring a lock _or_ world stop is common, so that can be expressed as
well.
Updates #40677
Change-Id: If0a58544f4251d367f73c4120c9d39974c6cd091
Reviewed-on: https://go-review.googlesource.com/c/go/+/248577
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
https://reviews.llvm.org/D90435 is the counterpart in LLVM TSAN.
race_linux_arm64.syso is built with LLVM commit
00da38ce2d36c07f12c287dc515d37bb7bc410e9 on a macOS/ARM64 machine.
(It is not built on a builder with golang.org/x/build/cmd/racebuild
as we don't have darwin/arm64 builder for now.)
Updates #38485.
Change-Id: I391efdacd9480197e308370bfccd05777deb4aee
Reviewed-on: https://go-review.googlesource.com/c/go/+/266373
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I find it pretty difficult to reason about test-dependency modules
when they aren't in the same file as the rest of the test.
Now that 'go get' supports replacements (CL 258220 and CL 266018),
we can localize tests that need 'go get' but don't specifically depend
on module proxy semantics.
For #36460
For #37438
Change-Id: Ib37a6c170f251435399dfc23e60d96681a81eadc
Reviewed-on: https://go-review.googlesource.com/c/go/+/266369
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This patch changes the way the linker emits the DWARF line table
prologue, specifically the file table. Previously files were left
unmodified, and the directory table was empty. For each compilation
unit we now scan the unit file table and build up a common set of
directories, emit them into the directory table, and then emit file
entries that refer to the dirs. This provides a modest binary size
savings.
For kubernetes kubelet:
$ objdump -h /tmp/kubelet.old | fgrep debug_line
36 .zdebug_line 019a55f5 0000000000000000 0000000000000000 084a5123 2**0
$ objdump -h /tmp/kubelet.new | fgrep debug_line
36 .zdebug_line 01146fd2 0000000000000000 0000000000000000 084a510a 2**0
[where the value following the section name above is the section size
in hex, so roughly a 30% decrease in this case.]
The actual savings will depend on the length of the pathnames
involved, so it's hard to really pin down how much savings we'll see
here. In addition, emitting the files this way reduces the
"compressibility" of the line table, so there could even be cases
where we don't win at all.
Updates #6853, #19784, #36495.
Change-Id: I298d8561da5ed3ebc9d38aa772874851baa2f4f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/263017
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Than McIntosh <thanm@google.com>
[This is a roll-forward of CL 262319, with a fix for some Darwin test
failures].
Change the definitions of selected runtime assembly routines
from ABI0 (the default) to ABIInternal. The ABIInternal def is
intended to indicate that these functions don't follow the existing Go
runtime ABI. In addition, convert the assembly reference to
runtime.main (from runtime.mainPC) to ABIInternal. Finally, for
functions such as "runtime.duffzero" that are called directly from
generated code, make sure that the compiler looks up the correct
ABI version.
This is intended to support the register abi work, however these
changes should not have any issues even when GOEXPERIMENT=regabi is
not in effect.
Updates #27539, #40724.
Change-Id: Idf507f1c06176073563845239e1a54dad51a9ea9
Reviewed-on: https://go-review.googlesource.com/c/go/+/266638
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
In CL 264179, some reorganization of error codes was deferred in order
to minimize diffs between patch-sets.
This CL reorganizes the error codes as discussed. It is a pure
reordering, with no material changes other than the changing of internal
const values.
For #42290
Change-Id: I0e9b421a92e96b19e53039652f8de898c5255290
Reviewed-on: https://go-review.googlesource.com/c/go/+/266637
Run-TryBot: Robert Findley <rfindley@google.com>
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In the current (pre-CL) version of the spec, the 2nd last shift
example appears to be using the array declared in the last example.
On a 32-bit platform, that array would have length 0, which would
lead to a panic in the 2nd last example. Also, if this code were
inside a function, it wouldn't compile (array declared after use).
Use an explicitly declared array for that specific shift example.
Also, split out all cases that produce different results for 32-
vs 64-bit ints.
Fixes#41835.
Change-Id: Ie45114224509e4999197226f91f7f6f934449abb
Reviewed-on: https://go-review.googlesource.com/c/go/+/260398
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
gcBgMarkWorker G's are primarily scheduled by findRunnableGCWorker, but
that no longer needs to be strictly enforced. Temporary preemption to a
runq is fine when the P is not in use.
We still releasem in gopark in the normal case for efficiency: if
gcDrain stops because gp.preempt is set, then gopark would always
preempt. That is fine, but inefficient, since it will reschedule simply
to park again. Thus, we keep releasem in unlockf to skip this extra
cycle.
Change-Id: I6d1a42e3ca41b76227142a6b5bfb376c9213e3c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/262349
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Pratt <mpratt@google.com>
Background mark workers perform per-P marking work. Currently each
worker is assigned a P at creation time. The worker "attaches" to the P
via p.gcBgMarkWorker, making itself (usually) available to
findRunnableGCWorker for scheduling GC work.
While running gcMarkDone, the worker "detaches" from the P (by clearing
p.gcBgMarkWorker), since it may park for other reasons and should not be
scheduled by findRunnableGCWorker.
Unfortunately, this design is complex and difficult to reason about. We
simplify things by changing the design to eliminate the hard P
attachment. Rather than workers always performing work from the same P,
workers perform work for whichever P they find themselves on. On park,
the workers are placed in a pool of free workers, which each P's
findRunnableGCWorker can use to run a worker for its P.
Now if a worker parks in gcMarkDone, a P may simply use another worker
from the pool to complete its own work.
The P's GC worker mode is used to communicate the mode to run to the
selected worker. It is also used to emit the appropriate worker
EvGoStart tracepoint. This is a slight change, as this G may be
preempted (e.g., in gcMarkDone). When it is rescheduled, the trace
viewer will show it as a normal goroutine again. It is currently a bit
difficult to connect to the original worker tracepoint, as the viewer
does not display the goid for the original worker (though the data is in
the trace file).
Change-Id: Id7bd3a364dc18a4d2b1c99c4dc4810fae1293c1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/262348
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Pratt <mpratt@google.com>
Tools using go/types sometimes need to implement special handling for
certain errors produced by the type-checker. They can offer suggested
fixes, expand the error position to surrounding syntax, highlight
related syntax (for example in the case of a declaration cycle), link to
additional documentation, group errors by category, or correlate errors
with signals produced by other static analysis tools.
All these require a notion of error identity. Tools need to be able to
reliably determine the nature of an error without re-implementing type
checking logic or parsing error messages. This CL is a first-pass at
adding such an identifier to types.Error: a (for the moment unexported)
field containing one of many declared errorCode constants.
A wide variety of error code constants are defined, and assigned to type
checker errors according to their 'functional equivalence', meaning that
they should be ideally be stable under refactoring.
With few exceptions, each error code is documented with an example that
produces it. This is enforced by tests.
When error codes are exported they will represent quite a large API
surface. For this reason, as well as the likelihood that error codes
will change at the start, both the code field and the codes themselves
are initially unexported. gopls will read these fields using reflection
during this experimental phase. Others can obviously do the same,
provided they accept the lack of forward compatibility.
For #42290
Change-Id: I15e3c2bffd2046c20297b1857057d421f633098a
Reviewed-on: https://go-review.googlesource.com/c/go/+/264179
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Currently, on all supported platforms, the race detector (LLVM
TSAN) expects the Go heap is at 0xc000000000 - 0xe000000000.
Move the raceenabled condition first, so we always allocate
there.
This means on Linux/ARM64 when race detector is on we will
allocate to 0xc000000000 - 0xe000000000, instead of 0x4000000000.
The old address is meant for 39-bit VMA. But the race detector
only supports 48-bit VMA anyway. So this is fine.
Change-Id: I51ac8eff68297b37c8c651a93145cc94f83a939d
Reviewed-on: https://go-review.googlesource.com/c/go/+/266372
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A method selector expression can pick out a method or promoted method
(represented by ODOTMETH), but it can also pick out an interface
method from an embedded interface-typed field (represented by
ODOTINTER).
In the case that we're picking out an interface method, we're not able
to fully devirtualize the method call. However, we're still able to
improve escape analysis somewhat. E.g., the included test case
demonstrates that we can optimize "i.M()" to "i.(T).I.M()", which
means the T literal can be stack allocated instead of heap allocated.
Fixes#42279.
Change-Id: Ifa21d19011e2f008d84f9624b7055b4676b6d188
Reviewed-on: https://go-review.googlesource.com/c/go/+/266300
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
In ParseComplex, the "size" passed to parseFloatPrefix should be 64 for
complex128, not 128. It still works because of how parseFloatPrefix
is forgiving about the size if it's not 32, but worth fixing anyway.
Make ParseComplex and ParseFloat return a bit size error for anything
other than 128 or 64 (for ParseComplex), or 64 or 32 (for ParseFloat).
Add "InvalidBitSize" tests for these cases.
Add tests for ParseComplex with bitSize==64: this is done in a similar
way to how the ParseFloat 32-bit tests work, re-using the tests for the
larger bit size.
Add tests for FormatComplex -- there were none before.
Fixes#40706
Change-Id: I16ddd546e5237207cc3b8c2181dd708eca42b04f
Reviewed-on: https://go-review.googlesource.com/c/go/+/248219
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Minux Ma <minux@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
There is no documentation on a number of methods of the strings.Reader
struct, so this change adds documentation referring to the relevant
io.* interfaces implemented. This is consistent with pre-existing
documentation in this struct.
Fixes#40381
Change-Id: I3dec65ecafca5b79d85d30a676d297e5ee9ab47e
GitHub-Last-Rev: f42429946a
GitHub-Pull-Request: golang/go#40654
Reviewed-on: https://go-review.googlesource.com/c/go/+/247523
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Append operations in the decimal String function may cause several allocations.
Use make to pre allocate slices in String that have enough capacity to avoid additional allocations in append operations.
name old time/op new time/op delta
DecimalConversion-8 139µs ± 7% 109µs ± 2% -21.06% (p=0.000 n=10+10)
Change-Id: Id0284d204918a179a0421c51c35d86a3408e1bd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/233980
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Trust: Martin Möhrmann <moehrmann@google.com>
In many cases, it is not necessary to parse long
decimal mantissas entirely to produce the correctly
rounded floating-point number. It is enough to parse
the short, rounded lower and upper bounds and in most cases
they round to the same floating point number because uint64
can hold 19 digits.
Previously this case was handled by the extFloat code path
(Grisu3 algorithm).
name old time/op new time/op delta
Atof64Big-4 1.07µs ± 2% 0.11µs ± 2% -89.61% (p=0.000 n=10+9)
Atof64RandomLongFloats-4 8.03µs ± 2% 0.14µs ± 7% -98.24% (p=0.000 n=10+10)
Atof32RandomLong-4 760ns ± 1% 156ns ± 0% -79.46% (p=0.000 n=10+8)
Benchmarks versus extFloat:
name old time/op new time/op delta
Atof64Big-4 121ns ± 3% 111ns ± 2% -7.93% (p=0.000 n=10+9)
Atof64RandomLongFloats-4 144ns ± 1% 142ns ± 7% ~ (p=0.167 n=10+10)
Atof32RandomLong-4 129ns ± 1% 156ns ± 0% +21.12% (p=0.000 n=10+8)
Change-Id: Id734b8c11e74b49a444fda67ee72870ae9422e60
Reviewed-on: https://go-review.googlesource.com/c/go/+/264677
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
We don't put Go static symbols in the symbol table, as they are
always compiler-generated (there is no way to define a static
symbol in user code in Go). We retain static symbols in assembly
code, as it may be user-defined. Also retain static symbols in C.
This is the second attempt of CL 263259, which was reverted
because it broke AIX tests in that it brought TOC.stmp symbols
in the symbol table. This time we use SymPkg(s) == "" to identify
non-Go symbols, instead of IsExternal(s), as the latter also
includes linker-modified Go symbols.
Change-Id: I5c752c54f0fc6ac4cde6a0e8161dac5b72a47d56
Reviewed-on: https://go-review.googlesource.com/c/go/+/266237
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
These messages can happen if there are
duplicate body-less function declarations.
Using panic gives the panic handler
a chance to handle the panic by printing the
queued error messages instead of an internal error.
And if there are no queued error messages,
using panic pinpoints the stack trace leading
to the incorrect use of NewFuncInfo/NewFileInfo.
Change-Id: I7e7ea9822ff9a1e7140f5e5b7cfd6437ff9318a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/266338
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
We should still be able to devirtualize here, but I need to understand
the AST better. While I'm doing that, at least switch to a graceful
failure case (i.e., skip the optimization and print a warning message)
to fix the x/text builders.
Updates #42279.
Change-Id: Ie2b0b701fccf590d0cabfead703fc2fa999072cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/266359
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
After inlining, add a pass that looks for interface calls where we can
statically determine the interface value's concrete type. If such a
case is found, insert an explicit type assertion to the concrete type
so that escape analysis can see it.
Fixes#33160.
Change-Id: I36932c691693f0069e34384086d63133e249b06b
Reviewed-on: https://go-review.googlesource.com/c/go/+/264837
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
When inlining a function call "f()", if "f" contains exactly 1
"return" statement and doesn't name its result parameters, it's
inlined to declare+initialize the result value using the AST
representation that's compatible with staticValue.
Also, extend staticValue to skip over OCONVNOP nodes (often introduced
by inlining), and fix various bits of code related to handling method
expressions.
Updates #33160.
Change-Id: If8652e319f0a5700cf9d40a7a62e369a2a359229
Reviewed-on: https://go-review.googlesource.com/c/go/+/266199
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This reverts CL 263457.
It turns out that this still missed changes to cmd/link/internal/ld/config.go
and some of these build modes also fail once cgo is enabled. Disable again for
now.
Change-Id: Iaf40d44e1551afd5b040d357f04af134f55a64a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/266317
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Joel Sing <joel@sing.id.au>
This change fixes two failng tests on linux-ppc64x:
- TestAllThreadsSyscall() exposed a real bug in the ppc64x support:
- It turns out that the r2 syscall return value is not defined
on all architectures. Notably linux-ppc64x so address that by
introducing a private architectural constant in the syscall
package, archHonorsR2: true if r2 has a determanistic value.
- TestSetuidEtc() was sensitive to /proc/<PID>/status content:
- The amount of padding space has changed with kernel vintage.
- Stress testing revealed a race with /proc files disappearing.
Fixes#42178
Change-Id: Ie6fc0b8f2f94a409ac0e5756e73bfce113274709
Reviewed-on: https://go-review.googlesource.com/c/go/+/266202
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The inlining pass previously bailed upon encountering a go or defer statement, so it would not inline functions e.g. used to provide arguments to the deferred function. This change preserves the behavior of not inlining the
deferred function itself, but it allows the inlining walk to proceed into its arguments.
Fixes#42194
Change-Id: I4e82029d8dcbe69019cc83ae63a4b29af45ec777
Reviewed-on: https://go-review.googlesource.com/c/go/+/264997
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The final piece of //go:embed support: have the go command stitch
together parsing in go/build, low-level data initialization in cmd/compile,
and the new data structures in package embed, to make the //go:embed
feature actually function.
And test, now that all the pieces are available to work together.
For #41191.
(Issue not fixed: still need to add a tool for use by Bazel.)
Change-Id: Ib1d198345c3b4d557d340f292eda13b984b65d65
Reviewed-on: https://go-review.googlesource.com/c/go/+/243945
Trust: Russ Cox <rsc@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Trust: Johan Brandhorst <johan.brandhorst@gmail.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Johan Brandhorst <johan.brandhorst@gmail.com>
This reverts CL 250497. It also moves all blank identifier imports below the rest of the imports for clarity.
Reason for revert: The blank identifier import was intentional to show that it's needed for its registration side effect. The duplicate import should stay since it communicates that the side-effect is important to tools and to future developers updating this file.
Change-Id: I626e6329db50f47453aa71085a05d21bf6efe0ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/265078
Run-TryBot: Katie Hockman <katie@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change the definitions of selected runtime assembly routines
from ABI0 (the default) to ABIInternal. The ABIInternal def is
intended to indicate that these functions don't follow the existing Go
runtime ABI. In addition, convert the assembly reference to
runtime.main (from runtime.mainPC) to ABIInternal. Finally, for
functions such as "runtime.duffzero" that are called directly from
generated code, make sure that the compiler looks up the correct
ABI version.
This is intended to support the register abi work, however these
changes should not have any issues even when GOEXPERIMENT=regabi is
not in effect.
Updates #27539, #40724.
Change-Id: I9846f8dcaccc95718cf2e61a18b7e924a0677e4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/262319
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This patch adds support for CASx and CASPx atomic instructions.
go syntax gnu syntax
CASD Rs, (Rn|RSP), Rt => cas Xs, Xt, (Xn|SP)
CASALW Rs, (Rn|RSP), Rt => casal Ws, Wt, (Xn|SP)
CASPD (Rs, Rs+1), (Rn|RSP), (Rt, Rt+1) => casp Xs, Xs+1, Xt, Xt+1, (Xn|SP)
CASPW (Rs, Rs+1), (Rn|RSP), (Rt, Rt+1) => casp Ws, Ws+1, Wt, Wt+1, (Xn|SP)
This patch changes the type of prog.RestArgs from "[]Addr" to
"[]struct{Addr, Pos}", Pos is a enum, indicating the position of
the operand.
This patch also adds test cases.
Change-Id: Ib971cfda7890b7aa895d17bab22dea326c7fcaa4
Reviewed-on: https://go-review.googlesource.com/c/go/+/233277
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This patch enables VSLI, VUADDW(2), VUSRA and FMOVQ SIMD instructions
required by the issue #40725. And the GNU syntax of 'FMOVQ' is 128-bit
ldr/str(immediate, simd&fp).
Add test cases.
Fixes#40725
Change-Id: Ide968ef4a9385ce4cd8f69bce854289014d30456
Reviewed-on: https://go-review.googlesource.com/c/go/+/258397
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
As it says, delay expanpsion of OpArg to the expand_calls phase,
to enable (eventually) interprocedural SSA optimizations, and
(sooner) change to a register ABI.
Includes a round of cleanup to function names and comments,
largely to match the expanded scope of the functions.
This CL removes the per-function dependence on GOSSAHASH,
but the go116lateCallExpansion kill switch remains (and was
tested locally to ensure it worked).
Two functions in expand_calls.go that performed overlapping
things were combined into a single function that is called
twice.
Fixes#42236.
For #40724.
Change-Id: Icbb78947eaa39f17f2c1210d5c2caef20abd6571
Reviewed-on: https://go-review.googlesource.com/c/go/+/262117
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Some of the current functions for encoding load/store with
immediate offset instructions, like opstr12(), opstr9(),
opldr12(), opldr9() and opldrpp(), etc., they have the same
code, so this patch refactors them and merges them into two
functions opstr() and opldr().
Change-Id: I60367f8b720b77c7ebe6d66905a950dcf7701836
Reviewed-on: https://go-review.googlesource.com/c/go/+/263479
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: fannie zhang <Fannie.Zhang@arm.com>
This is done by decomposing the number to be divided in 32-bit
components and using the 32-bit magic multiply. For the lowering to be
effective the constant must fit in 16 bits.
On ARM the expression n / 5 compiles to 25 instructions.
Benchmark for GOARCH=arm (Cortex-A53)
name old time/op new time/op delta
DivconstU64/3-6 1.19µs ± 0% 0.03µs ± 1% -97.40% (p=0.000 n=9+9)
DivconstU64/5-6 1.18µs ± 1% 0.03µs ± 1% -97.38% (p=0.000 n=10+8)
DivconstU64/37-6 1.13µs ± 1% 0.04µs ± 1% -96.51% (p=0.000 n=10+8)
DivconstU64/1234567-6 852ns ± 0% 901ns ± 1% +5.73% (p=0.000 n=8+9)
Benchmark for GOARCH=386 (Haswell)
name old time/op new time/op delta
DivconstU64/3-4 18.0ns ± 2% 5.6ns ± 1% -69.06% (p=0.000 n=10+10)
DivconstU64/5-4 17.8ns ± 1% 5.5ns ± 1% -68.87% (p=0.000 n=9+10)
DivconstU64/37-4 17.8ns ± 1% 7.3ns ± 0% -58.90% (p=0.000 n=10+10)
DivconstU64/1234567-4 17.5ns ± 1% 16.0ns ± 0% -8.55% (p=0.000 n=10+9)
Change-Id: I38a19b4d59093ec021ef2e5241364a3dad4eae73
Reviewed-on: https://go-review.googlesource.com/c/go/+/264683
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
rewrite.go has two identical functions log2 and log64; the former has
been there for a while, while the latter was added together with
log{8,16,32} for use in typed rules.
This change deletes log2 and switches to using log64 everywhere.
Change-Id: I759b878814e4c115a5fa470274f22477738d69ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/265457
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Following golang.org/cl/259578, findrunnable still must touch every
other P in checkTimers in order to look for timers to steal. This scales
poorly with GOMAXPROCS and potentially performs poorly by pulling remote
Ps into cache.
Add timerpMask, a bitmask that tracks whether each P may have any timers
on its timer heap.
Ideally we would update this field on any timer add / remove to always
keep it up to date. Unfortunately, updating a shared global structure is
antithetical to sharding timers by P, and doing so approximately doubles
the cost of addtimer / deltimer in microbenchmarks.
Instead we only (potentially) clear the mask when the P goes idle. This
covers the best case of avoiding looking at a P _at all_ when it is idle
and has no timers. See the comment on updateTimerPMask for more details
on the trade-off. Future CLs may be able to expand cases we can avoid
looking at the timers.
Note that the addition of idlepMask to p.init is a no-op. The zero value
of the mask is the correct init value so it is not necessary, but it is
included for clarity.
Benchmark results from WakeupParallel/syscall/pair/race/1ms (see
golang.org/cl/228577). Note that these are on top of golang.org/cl/259578:
name old msec new msec delta
Perf-task-clock-8 244 ± 4% 246 ± 4% ~ (p=0.841 n=5+5)
Perf-task-clock-16 247 ±11% 252 ± 4% ~ (p=1.000 n=5+5)
Perf-task-clock-32 270 ± 1% 268 ± 2% ~ (p=0.548 n=5+5)
Perf-task-clock-64 302 ± 3% 296 ± 1% ~ (p=0.222 n=5+5)
Perf-task-clock-128 358 ± 3% 352 ± 2% ~ (p=0.310 n=5+5)
Perf-task-clock-256 483 ± 3% 458 ± 1% -5.16% (p=0.008 n=5+5)
Perf-task-clock-512 663 ± 1% 612 ± 4% -7.61% (p=0.008 n=5+5)
Perf-task-clock-1024 1.06k ± 1% 0.95k ± 2% -10.24% (p=0.008 n=5+5)
Updates #28808
Updates #18237
Change-Id: I4239cd89f21ad16dfbbef58d81981da48acd0605
Reviewed-on: https://go-review.googlesource.com/c/go/+/264477
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Pratt <mpratt@google.com>
procfs(5) is not always mounted in DragonFly BSD, for example during
the binary package build with synth. os.Executable() consumers
will then fail, we've spotted this when trying to build tinygo:
[...]
copying source files
./build/tinygo build-builtins -target=armv6m-none-eabi [...]
panic: could not get executable path: readlink /proc/curproc/file:
no such file or directory
[...]
Use KERN_PROC_PATHNAME as FreeBSD does.
Change-Id: Ic65bea02cd0309fb24dec8ba8d2b151d1acde67b
GitHub-Last-Rev: 083120a43b
GitHub-Pull-Request: golang/go#36826
Reviewed-on: https://go-review.googlesource.com/c/go/+/216622
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Tx acquires tx.closemu W-lock and then acquires stmt.closemu.W-lock
to fully close the transaction and associated prepared statement.
Stmt query and execution run in reverse ways - acquires
stmt.closemu.R-lock and then acquires tx.closemu.R-lock to grab tx
connection, which may cause deadlock.
Prevent the lock is held around tx.closePrepared to ensure no
deadlock happens.
Fixes#40985
Change-Id: If53909822b87bce11861a6e3035ecb9476d2cd17
Reviewed-on: https://go-review.googlesource.com/c/go/+/250178
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Follow-up for CL 265819.
Given the -pre tag added recently, a new stable version is likely
tagged soon. This would break TestCodeRepoVersions on the longtest
builders again. Since the other test cases in codeRepoVersionsTests
already provide enough coverage, drop gopkg.in/russross/blackfriday.v2
to avoid breaking TestCodeRepoVersions once the release happens.
Updates #28856
Change-Id: If86a637b5e47f59faf9048fc1cbbae6e8f1dcc53
Reviewed-on: https://go-review.googlesource.com/c/go/+/265917
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Sysmon can actually get the RW lock execLock while holding the sysmon
lock (if no M is available), so there is an edge from lockRankSysmon to
lockRankRwmutexR. The stack trace is sysmon() [gets sched.sysmonlock] ->
startm() -> newm() -> newm1() -> execLock.runlock() [gets
execLock.rLock]
Change-Id: I9658659ba3899afb5219114d66b989abd50540db
Reviewed-on: https://go-review.googlesource.com/c/go/+/265721
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
With previous CLs, internal linking without cgo should work well.
Enable it by default. And stop always requiring cgo.
Enable tests that were previously disabled due to the lack of
internal linking.
Updates #38485.
Change-Id: I45125b9c263fd21d6847aa6b14ecaea3a2989b29
Reviewed-on: https://go-review.googlesource.com/c/go/+/265121
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, on darwin/arm64 we set up TLS using cgo. TLS is not
set for pure Go programs. As we use libc for syscalls on darwin,
we need to save the G register before the libc call. Otherwise it
is not signal-safe, as a signal may land during the execution of
a libc function, where the G register may be clobbered.
This CL initializes TLS in Go, by calling the pthread functions
directly without cgo. This makes it possible to save the G
register to TLS in pure Go programs (done in a later CL).
Inspired by Elias's CL 209197. Write the logic in Go instead of
assembly.
Updates #38485, #35853.
Change-Id: I257ba2a411ad387b2f4d50d10129d37fec7a226e
Reviewed-on: https://go-review.googlesource.com/c/go/+/265118
Trust: Cherry Zhang <cherryyz@google.com>
Trust: Elias Naur <mail@eliasnaur.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-10-28 13:25:44 +00:00
1274 changed files with 49650 additions and 21424 deletions
now correctly support callback functions with multiple
sub-<code>uintptr</code>-sized arguments in a row. This may
require changing uses of these functions to eliminate manual
padding between small arguments.
</p>
<p><!-- CL 261917 -->
<ahref="/pkg/syscall/?GOOS=windows#SysProcAttr"><code>SysProcAttr</code></a> on Windows has a new NoInheritHandles field that disables inheriting handles when creating a new process.
</p>
<p><!-- CL 269761, golang.org/issue/42584 -->
<ahref="/pkg/syscall/?GOOS=windows#DLLError"><code>DLLError</code></a> on Windows now has an Unwrap function for unwrapping its underlying error.
`{"location":{"uri":"file://tmpdir/file.go","range":{"start":{"line":9,"character":13},"end":{"line":9,"character":13}}},"message":"escflow: flow: y = z:"},`+
`{"location":{"uri":"file://tmpdir/file.go","range":{"start":{"line":9,"character":13},"end":{"line":9,"character":13}}},"message":"escflow: from y := z (assign-pair)"},`+
`{"location":{"uri":"file://tmpdir/file.go","range":{"start":{"line":9,"character":13},"end":{"line":9,"character":13}}},"message":"escflow: from y.b (dot of pointer)"},`+
`{"location":{"uri":"file://tmpdir/file.go","range":{"start":{"line":9,"character":13},"end":{"line":9,"character":13}}},"message":"escflow: from \u0026y.b (address-of)"},`+
`{"location":{"uri":"file://tmpdir/file.go","range":{"start":{"line":9,"character":3},"end":{"line":9,"character":3}}},"message":"escflow: from return (*int)(~r1) (return)"}]}`)
`{"location":{"uri":"file://tmpdir/file.go","range":{"start":{"line":9,"character":13},"end":{"line":9,"character":13}}},"message":"escflow: from ~R0 = \u003cN\u003e (assign-pair)"},`+
`{"location":{"uri":"file://tmpdir/file.go","range":{"start":{"line":9,"character":3},"end":{"line":9,"character":3}}},"message":"escflow: from return (*int)(~R0) (return)"}]}`)
{name:"Select0",argLength:1,zeroWidth:true},// the first component of a tuple
{name:"Select1",argLength:1,zeroWidth:true},// the second component of a tuple
{name:"SelectN",argLength:1,aux:"Int64"},// arg0=tuple, auxint=field index. Returns the auxint'th member.
{name:"SelectNAddr",argLength:1,aux:"Int64"},// arg0=tuple, auxint=field index. Returns the address of auxint'th member. Used for un-SSA-able result types.
{name:"SelectN",argLength:1,aux:"Int64"},// arg0=result, auxint=field index. Returns the auxint'th member.
{name:"SelectNAddr",argLength:1,aux:"Int64"},// arg0=result, auxint=field index. Returns the address of auxint'th member. Used for un-SSA-able result types.
{name:"MakeResult",argLength:-1},// arg0 .. are components of a "Result" (like the result from a Call). The last arg should be memory (like the result from a call).
// Atomic operations used for semantically inlining sync/atomic and
// runtime/internal/atomic. Atomic loads return a new memory so that
@@ -573,8 +574,16 @@ var genericOps = []opData{
// These variants have the same semantics as above atomic operations.
// But they are used for generating more efficient code on certain modern machines, with run-time CPU feature detection.
// Currently, they are used on ARM64 only.
{name:"AtomicAdd32Variant",argLength:3,typ:"(UInt32,Mem)",hasSideEffects:true},// Do *arg0 += arg1. arg2=memory. Returns sum and new memory.
{name:"AtomicAdd64Variant",argLength:3,typ:"(UInt64,Mem)",hasSideEffects:true},// Do *arg0 += arg1. arg2=memory. Returns sum and new memory.
{name:"AtomicAdd32Variant",argLength:3,typ:"(UInt32,Mem)",hasSideEffects:true},// Do *arg0 += arg1. arg2=memory. Returns sum and new memory.
{name:"AtomicAdd64Variant",argLength:3,typ:"(UInt64,Mem)",hasSideEffects:true},// Do *arg0 += arg1. arg2=memory. Returns sum and new memory.
{name:"AtomicExchange32Variant",argLength:3,typ:"(UInt32,Mem)",hasSideEffects:true},// Store arg1 to *arg0. arg2=memory. Returns old contents of *arg0 and new memory.
{name:"AtomicExchange64Variant",argLength:3,typ:"(UInt64,Mem)",hasSideEffects:true},// Store arg1 to *arg0. arg2=memory. Returns old contents of *arg0 and new memory.
{name:"AtomicCompareAndSwap32Variant",argLength:4,typ:"(Bool,Mem)",hasSideEffects:true},// if *arg0==arg1, then set *arg0=arg2. Returns true if store happens and new memory.
{name:"AtomicCompareAndSwap64Variant",argLength:4,typ:"(Bool,Mem)",hasSideEffects:true},// if *arg0==arg1, then set *arg0=arg2. Returns true if store happens and new memory.
// on the tour from p1 to p2. We've precomputed minimum
// depth blocks for powers-of-two subsequences of the tour.
// Combine the right two precomputed values to get the answer.
logS:=uint(log2(int64(p2-p1)))
logS:=uint(log64(int64(p2-p1)))
bid1:=lca.rangeMin[logS][p1]
bid2:=lca.rangeMin[logS][p2-1<<logS+1]
iflca.blocks[bid1].depth<lca.blocks[bid2].depth{
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
