When a method is called using the Type.Method(receiver, args...) syntax
without the receiver, or enough arguments, provide the more helpful
error message "not enough arguments in call to method expression
Type.Method" instead of the old message "not enough arguments in call
to Type.Method".
Fixes#8385
Change-Id: Id5037eb1ee5fa93687d4a6557b4a8233b29e9df2
Reviewed-on: https://go-review.googlesource.com/2193
Reviewed-by: Russ Cox <rsc@golang.org>
It's easy for someone who wants a time bigger than any
valid time to reach for time.Unix(1<<63-1, 0), so it
makes sense to explicit say such value is not valid.
Fixes#10906 (again).
Change-Id: If71e32472ae40d86c30e629b982406040a73c4c7
Reviewed-on: https://go-review.googlesource.com/10266
Reviewed-by: Russ Cox <rsc@golang.org>
The Slicing-By-8 [1] algorithm has much performance improvements than
current approach. This patch only uses it for IEEE, which is the most
common case in practice.
There is the benchmark on Mac OS X 10.9:
benchmark old MB/s new MB/s speedup
BenchmarkIEEECrc1KB 349.40 353.03 1.01x
BenchmarkIEEECrc4KB 351.55 934.35 2.66x
BenchmarkCastagnoliCrc1KB 7037.58 7392.63 1.05x
This algorithm need 8K lookup table, so it's enabled only for block
larger than 4K.
We can see about 2.6x improvement for IEEE.
Change-Id: I7f786d20f0949245e4aa101d7921669f496ed0f7
Reviewed-on: https://go-review.googlesource.com/1863
Reviewed-by: Russ Cox <rsc@golang.org>
Check that if a version is declared, for example
in '<?xml version="XX" ?>', version must be '1.0'.
Change-Id: I16ba9f78873a5f31977dcf75ac8e671fe6c08280
Reviewed-on: https://go-review.googlesource.com/8961
Reviewed-by: Russ Cox <rsc@golang.org>
When the scanner receives a non-whitespace character in stateEndTop,
it creates an error message and caches it to return on the next
transition. nextValue() uses the scanner to sub-scan for a value
inside a larger JSON structure. Since stateEndTop is triggered
*after* the ending byte, whatever character immediately follows the
sub-value gets pulled into the scanner's state machine as well.
Even though it is not used and doesn't cause an error, it does
cause the state machine to allocate an error that will never be used.
The fix is to probe the state machine with whitespace after
scanEndObject or scanEndArray to see if the next character would
result in a scanEnd state transition. If so, we can return right
away without processing the next character and avoid triggering
an allocation.
benchmark old ns/op new ns/op delta
BenchmarkCodeEncoder 17022194 16611336 -2.41%
BenchmarkCodeMarshal 18443250 18090144 -1.91%
BenchmarkCodeDecoder 61502053 61010936 -0.80%
BenchmarkCodeUnmarshal 61410829 60363605 -1.71%
BenchmarkCodeUnmarshalReuse 59124836 58361772 -1.29%
BenchmarkUnmarshalString 602 603 +0.17%
BenchmarkUnmarshalFloat64 535 537 +0.37%
BenchmarkUnmarshalInt64 482 482 +0.00%
BenchmarkIssue10335 1206 799 -33.75%
BenchmarkSkipValue 17605751 18355391 +4.26%
BenchmarkEncoderEncode 612 604 -1.31%
benchmark old MB/s new MB/s speedup
BenchmarkCodeEncoder 114.00 116.82 1.02x
BenchmarkCodeMarshal 105.21 107.27 1.02x
BenchmarkCodeDecoder 31.55 31.81 1.01x
BenchmarkCodeUnmarshal 31.60 32.15 1.02x
BenchmarkSkipValue 111.63 107.07 0.96x
benchmark old allocs new allocs delta
BenchmarkIssue10335 11 4 -63.64%
BenchmarkEncoderEncode 2 2 +0.00%
benchmark old bytes new bytes delta
BenchmarkIssue10335 376 272 -27.66%
BenchmarkEncoderEncode 40 40 +0.00%
Fixes#10335
Change-Id: I3d4f2b67f7a038adfb33ba48bb6b680f528baf18
Reviewed-on: https://go-review.googlesource.com/9074
Reviewed-by: Russ Cox <rsc@golang.org>
Suggest running 'go help gopath' when the running 'go install .'
and the folder is outside of GOPATH.
Added link to 'https://golang.org/doc/code.html' in gopath help
for more information.
Example output:
% go install .
go install: no install location for directory f:\x\badmessage outside GOPATH
please run 'go help gopath' for more information
% go help gopath
... SNIP ...
See https://golang.org/doc/code.html for an example.
Fixes#8457
Change-Id: I0ef6ee3c65bb12af2168eafeb757258aa3835664
Reviewed-on: https://go-review.googlesource.com/9258
Reviewed-by: Russ Cox <rsc@golang.org>
Check for errors when reading the headers following the pax headers.
Fixes#11169.
Change-Id: Ifec4a949ec8df8b49fa7cb7a67eb826fe2282ad8
Reviewed-on: https://go-review.googlesource.com/11031
Reviewed-by: Russ Cox <rsc@golang.org>
Return a meaningful message when a profile is empty.
Also rename "IO blocking" to "Network blocking",
currently only network blocking is captured.
Fixes#11098
Change-Id: Ib6f1292b8ade4805756fcb6696ba1fca8f9f39a9
Reviewed-on: https://go-review.googlesource.com/11243
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There were two issues.
1. Delayed EvGoSysExit could have been emitted during TraceStart,
while it had not yet emitted EvGoInSyscall.
2. Delayed EvGoSysExit could have been emitted during next tracing session.
Fixes#10476Fixes#11262
Change-Id: Iab68eb31cf38eb6eb6eee427f49c5ca0865a8c64
Reviewed-on: https://go-review.googlesource.com/9132
Reviewed-by: Russ Cox <rsc@golang.org>
All the other error messages in this package are "lzw: etc".
Change-Id: Ie359a8912d213f92b15f02abc953127380503048
Reviewed-on: https://go-review.googlesource.com/11228
Reviewed-by: David Symonds <dsymonds@golang.org>
In preparation for rename of cgocall_errno into cgocall and
asmcgocall_errno into asmcgocall in the fllowinng CL.
rsc requested CL 9387 to be split into two parts. This is first part.
Change-Id: I7434f0e4b44dd37017540695834bfcb1eebf0b2f
Reviewed-on: https://go-review.googlesource.com/11166
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Work-around issue #11265 and re-enable tests for Plan9.
Change-Id: I3aabb674a149b8eb936f948dd4cda5fd81454646
Reviewed-on: https://go-review.googlesource.com/11194
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change will brake the build. The immediately following change
contains the necessary adjustments to make it work again. We're
doing this in two steps to expose the manual changes applied.
Change-Id: I225947da23e190b12e12cbd0c5e6e91628de7f53
Reviewed-on: https://go-review.googlesource.com/11151
Reviewed-by: Alan Donovan <adonovan@google.com>
This fixes a hang during runtime.TestTraceStress.
It also fixes double-scan of stacks, which leads to
stack barrier installation failures.
Both of these have shown up as flaky failures on the dashboard.
Fixes#10941.
Change-Id: Ia2a5991ce2c9f43ba06ae1c7032f7c898dc990e0
Reviewed-on: https://go-review.googlesource.com/11089
Reviewed-by: Austin Clements <austin@google.com>
//go:systemstack means that the function must run on the system stack.
Add one use in runtime as a demonstration.
Fixes#9174.
Change-Id: I8d4a509cb313541426157da703f1c022e964ace4
Reviewed-on: https://go-review.googlesource.com/10840
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
I updated some references to 6g, 6l and friends that I came across, as those
programs don't exist anymore. I also fixed some echos in make.rc to match other make.* scripts while I was there.
Change-Id: Ib84532cd4688cf65174dd9869e5d42af98a20a48
Reviewed-on: https://go-review.googlesource.com/11162
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Corrected several issues:
* RFC1951 section 3.2.7 dictates that it is okay for the HDist tree to have a
single code of zero bits. Furthermore, the behavior of the C zlib library
permits empty trees even when there are more than one codes.
* RFC1951 section 3.2.5 shows that HLit codes 286 and 287 are invalid. Thus,
Go's implementation should choke on inputs using these codes.
* RFC1951 section 3.2.5 and 3.2.7 are ambiguous about whether the number of
HDist codes can be greater than 30. The C zlib library (which is the canonical
reference implementation) performs this check here:
62d6112a79/inflate.c (L906)
In addition, a number of test cases were added to the unit tests that exercises
these edge cases. The test cases listed in TestStreams will either fail or
succeed in a manner matching the behaviour of the C zlib version. Given that the
C zlib implementation is the reference for the world, Go's implementation should
match C zlib behaviour.
Fixes#11030
Change-Id: Ic24e4e40ce5832c7e1930249246e86d34bfedaa6
Reviewed-on: https://go-review.googlesource.com/11000
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Also modified test/run.go to ignore messages prefixed <autogenerated>
because those cannot be described with "// ERROR ...", and backed out
patch from issue #9537 because it is no longer necessary. The reasons
described in the 9537 discussion for why escape analysis cannot run
late no longer hold, happily.
Fixes#11053.
Change-Id: Icb14eccdf2e8cde3d0f8fb8a216b765400a96385
Reviewed-on: https://go-review.googlesource.com/11088
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David Chase <drchase@google.com>
This change reintroduces CL 8523. CL 8523 was reverted because
it broke darwin and netbsd builds. Now that this test is part
of "go tool dist test" command we could skip OSes that fail.
Updates #10360
Change-Id: Iaaeb5b800126492f36415a439c333a218fe4ab67
Reviewed-on: https://go-review.googlesource.com/11119
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
So the tests don't interfere with each other on windows.
Fixes#11217
Change-Id: I4b3936bc64c95c7274298d6f137b24a28876b625
Reviewed-on: https://go-review.googlesource.com/11138
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change allows LookupAddr to use getnameinfo through cgo for working
together with various name services other than DNS.
Fixes#7855.
Change-Id: I5b3b4aefe3d1b904541c3350865734d8cbb1c1c4
Reviewed-on: https://go-review.googlesource.com/3420
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This flag is not needed in the std repo because we don't have
tests requiring it. Remove it before it's frozen into the API.
Change-Id: I18b861eea146ad67e7a3c26ee8be681d8065ef12
Reviewed-on: https://go-review.googlesource.com/11150
Reviewed-by: Alan Donovan <adonovan@google.com>
This makes the behaviour match what happens when duplicate symbols are read
from regular object files and fixes errors about cgoAlwaysFalse when linking
an executable that uses cgo against a shared library.
Change-Id: Ibb8cd8fe3f7813cde504b7483f1e857868d7e063
Reviewed-on: https://go-review.googlesource.com/11117
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TestHostname was re-enabled in CL 10753.
However, on Plan 9 the hostname is not obtained
by executing a "hostname" command, but by reading
the #c/sysname file.
Change-Id: I80c0e303f4983fe39ceb300ad64e2c4a8392b695
Reviewed-on: https://go-review.googlesource.com/11033
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, when shrinkstack computes whether the halved stack
allocation will have enough room for the stack, it accounts for the
stack space that's actively in use but fails to leave extra room for
the stack guard space. As a result, *if* the minimum stack size is
small enough or the guard large enough, it may shrink the stack and
leave less than enough room to run nosplit functions. If the next
function called after the stack shrink is a nosplit function, it may
overflow the stack without noticing and overwrite non-stack memory.
We don't think this is happening under normal conditions right now.
The minimum stack allocation is 2K and the guard is 640 bytes. The
"worst case" stack shrink is from 4K (4048 bytes after stack barrier
array reservation) to 2K (2016 bytes after stack barrier array
reservation), which means the largest "used" size that will qualify
for shrinking is 4048/4 - 8 = 1004 bytes. After copying, that leaves
2016 - 1004 = 1012 bytes of available stack, which is significantly
more than the guard space.
If we were to reduce the minimum stack size to 1K or raise the guard
space above 1012 bytes, the logic in shrinkstack would no longer leave
enough space.
It's also possible to trigger this problem by setting
firstStackBarrierOffset to 0, which puts stack barriers in a debug
mode that steals away *half* of the stack for the stack barrier array
reservation. Then, the largest "used" size that qualifies for
shrinking is (4096/2)/4 - 8 = 504 bytes. After copying, that leaves
(2096/2) - 504 = 8 bytes of available stack; much less than the
required guard space. This causes failures like those in issue #11027
because func gc() shrinks its own stack and then immediately calls
casgstatus (a nosplit function), which overflows the stack and
overwrites a free list pointer in the neighboring span. However, since
this seems to require the special debug mode, we don't think it's
responsible for issue #11027.
To forestall all of these subtle issues, this commit modifies
shrinkstack to correctly account for the guard space when considering
whether to halve the stack allocation.
Change-Id: I7312584addc63b5bfe55cc384a1012f6181f1b9d
Reviewed-on: https://go-review.googlesource.com/10714
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Issues #10240, #10541, #10941, #11023, #11027 and possibly others are
indicating memory corruption in the runtime. One of the easiest places
to both get corruption and detect it is in the allocator's free lists
since they appear throughout memory and follow strict invariants. This
commit adds a check when sweeping a span that its free list is sane
and, if not, it prints the corrupted free list and panics. Hopefully
this will help us collect more information on these failures.
Change-Id: I6d417bcaeedf654943a5e068bd76b58bb02d4a64
Reviewed-on: https://go-review.googlesource.com/10713
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
The motivation of TestLookupHost was to test codepaths on LookupHost,
LookupIP when we set CGO_ENABLED=1. Now we have serveral tests on those
APIs and their codepaths such as TestLookupGooglePublicDNSAddr,
TestCgoLookupIP, TestGoLookupIP, and the test using the ambiguous source
"localhost" is unnecessary.
Fixes#11182.
Change-Id: I397c823e1648114d91a229b316477bff2948b4f9
Reviewed-on: https://go-review.googlesource.com/11057
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Sadly examples cannot use the new internal/testenv, so this is
extends the crude build tag restriction in this file.
Change-Id: I49646ca71e45074a917813ae8e612cc715c78be8
Reviewed-on: https://go-review.googlesource.com/11086
Reviewed-by: Robert Griesemer <gri@golang.org>
Unfortunately there's no simple, easy way to make Dial{TCP,UDP} fail
consistently across all platforms. Fow now we skip the test on Solaris.
Change-Id: Ib3c55f670ac6a174fe9ea682dac7aab96b1e9dfb
Reviewed-on: https://go-review.googlesource.com/11058
Reviewed-by: Ian Lance Taylor <iant@golang.org>
dialSerial connects to a list of addresses in sequence. If a
timeout is specified, then each address gets an equal fraction of the
remaining time, with a magic constant (2 seconds) to prevent
"dial a million addresses" from allotting zero time to each.
Normally, net.Dial passes the DNS stub resolver's output to dialSerial.
If an error occurs (like destination/port unreachable), it quickly skips
to the next address, but a blackhole in the network will cause the
connection to hang until the timeout elapses. This is how UNIXy clients
traditionally behave, and is usually sufficient for non-broken networks.
The DualStack flag enables dialParallel, which implements Happy Eyeballs
by racing two dialSerial goroutines, giving the preferred family a
head start (300ms by default). This allows clients to avoid long
timeouts when the network blackholes IPv4 xor IPv6.
Fixes#8453Fixes#8455Fixes#8847
Change-Id: Ie415809c9226a1f7342b0217dcdd8f224ae19058
Reviewed-on: https://go-review.googlesource.com/8768
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: Id93b8ab42fa311ce32209734ec9a0813f8736e25
Reviewed-on: https://go-review.googlesource.com/9914
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
The main change is:
golang.org/cl/10800 add pos parameter to Eval; remove New, EvalNode
followed by several cleanups/follow-up fixes:
golang.org/cl/10992 remove global vars in test
golang.org/cl/10994 remove unused scope parameter from NewSignature
golang.org/cl/10995 provide full source file extent to file scope
golang.org/cl/10996 comment fix in resolver.go
golang.org/cl/11004 updated cmd/vet
golang.org/cl/11042 be robust in the presence of incorrect/missing position info
Fixes#9980.
Change-Id: Id4aff688f6a399f76bf92b84c7e793b8da8baa48
Reviewed-on: https://go-review.googlesource.com/11122
Reviewed-by: Alan Donovan <adonovan@google.com>
The problem was not the kernel version as I thought before, it was
that the test used the same number for both the UID and the GID.
Thanks to Chris Siebenmann for debugging this.
Fixes#11220.
Change-Id: Ib5077e182497155e84044683209590ee0f7c9dde
Reviewed-on: https://go-review.googlesource.com/11124
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This CL adds a very long comment explaining how isStale and
the new build IDs work. As part of writing the comment I realized:
// When the go command makes the wrong build decision and does not
// rebuild something it should, users fall back to adding the -a flag.
// Any common use of the -a flag should be considered prima facie evidence
// that isStale is returning an incorrect false result in some important case.
// Bugs reported in the behavior of -a itself should prompt the question
// ``Why is -a being used at all? What bug does that indicate?''
The two uses of -a that are most commonly mentioned in bugs filed
against the go command are:
go install -a ./...
go build -tags netgo -a myprog
Both of these commands now do the right thing without needing -a.
The -a exception we introduced in Go 1.4 was for the first form, and
it broke the second form. Again, neither needs -a anymore, so restore
the old, simpler, easier to explain, less surprising meaning used in Go 1.3:
if -a is given, rebuild EVERYTHING.
See the comment for more justification and history.
Summary of recent CLs (to link bugs to this one):
Fixes#3036. Now 'go install ./...' works.
Fixes#6534. Now 'go install ./...' works.
Fixes#8290. Now 'go install ./...' works.
Fixes#9369. Now 'go build -tags netgo myprog' works.
Fixes#10702. Now using one GOPATH with Go 1.5 and Go 1.6 works.
(Each time you switch, everything needed gets rebuilt.
Switching from Go 1.4 to Go 1.5 will rebuild properly.
Switching from Go 1.5 back to Go 1.4 still needs -a when
invoking the Go 1.4 go command.)
Change-Id: I19f9eb5286efaa50de7c8326602e94604ab572eb
Reviewed-on: https://go-review.googlesource.com/10761
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This causes packages and binaries built by Go 1.5 to look
out of date to Go 1.6 and vice versa, so that when you flip
between different Go versions but keep the same GOPATH,
the right rebuilding happens at each flip.
Go 1.4 binaries will also look out of date to Go 1.5,
but Go 1.5 binaries will not look out of date to Go 1.4
(since Go 1.4 doesn't have anything like this).
People flipping between Go 1.4 and Go 1.5 will still
need to use go install -a every time to flip to Go 1.4,
but not when they flip back to Go 1.5.
Fixes#6534.
Fixes#10702.
Change-Id: I0ae7f268f822d483059a938a4f22846ff9275b4c
Reviewed-on: https://go-review.googlesource.com/10760
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
A workaround for #10460.
Change-Id: I607a556561d509db6de047892f886fb565513895
Reviewed-on: https://go-review.googlesource.com/10819
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Fixes#11131
When running 'go install -buildmode=c-shared', under the circumstances
described in issue #11131, the install command would fail trying to
install cgo headers if they have already been installed (by a previous
call to 'go install -buildmode=c-shared').
Since it's safe to overwrite said headers (according to iant@), this CL
introduces a parameter to builder's 'copy' and 'move' functions that,
if set to 'true', would force the overwriting of already installed
files.
This parameter value is set to 'true' only when installing cgo headers,
for now.
Change-Id: I5bda17ee757066a8e5d2b39f2e8f3a389eb1e4a2
Reviewed-on: https://go-review.googlesource.com/10870
Run-TryBot: Srdjan Petrovic <spetrovic@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The number of CPUs is of value when benchmarking but mostly
noise when testing. The recent change to default to the number
of CPUs available has made the tests noisier and confusing.
Fixes#11200
Change-Id: Ifc87d9ccb4177d73e304fb7ffcef4367bd163c9e
Reviewed-on: https://go-review.googlesource.com/11121
Reviewed-by: Russ Cox <rsc@golang.org>
While we're here, update the documentation and delete variables with no effect.
Change-Id: I4df0d266dff880df61b488ed547c2870205862f0
Reviewed-on: https://go-review.googlesource.com/10790
Reviewed-by: Austin Clements <austin@google.com>
A send on an unbuffered channel to a blocked receiver is the only
case in the runtime where one goroutine writes directly to the stack
of another. The garbage collector assumes that if a goroutine is
blocked, its stack contains no new pointers since the last time it ran.
The send on an unbuffered channel violates this, so it needs an
explicit write barrier. It has an explicit write barrier, but not one that
can handle a write to another stack. Use one that can (based on type bitmap
instead of heap bitmap).
To make this work, raise the limit for type bitmaps so that they are
used for all types up to 64 kB in size (256 bytes of bitmap).
(The runtime already imposes a limit of 64 kB for a channel element size.)
I have been unable to reproduce this problem in a simple test program.
Could help #11035.
Change-Id: I06ad994032d8cff3438c9b3eaa8d853915128af5
Reviewed-on: https://go-review.googlesource.com/10815
Reviewed-by: Austin Clements <austin@google.com>
In generateTrace we check that event timestamp is within the interesting range.
Then later in traceContext.time we double check event time.
However, for some events (e.g. emitSlice) we convert time of ev.Link (slice end) rather than ev itself (slice begin).
Slice end can be outside of the interesting time range, and so traceContext.time crashes.
Remove the check in traceContext.time, check in generateTrace loop is sufficient.
Change-Id: If94e93b5653c5816c0a8dcdd920f15df97616835
Reviewed-on: https://go-review.googlesource.com/11100
Reviewed-by: Andrew Gerrand <adg@golang.org>
Update to tip to fix#11003 (not possible to select events in chromium).
Fixed#11003
Change-Id: Ibba5d39ca809cfd5cb79c9e6d152b00899d49e08
Reviewed-on: https://go-review.googlesource.com/11062
Reviewed-by: Andrew Gerrand <adg@golang.org>
Return io.ErrUnexpectedEOF instead of io.EOF when reading a truncated
data descriptor.
Fixes#11146.
Change-Id: Ia1905955165fd38af3c557d1fa1703ed8be893e2
Reviewed-on: https://go-review.googlesource.com/11070
Reviewed-by: Andrew Gerrand <adg@golang.org>
The previous code had a brain fart: it took one of the length prefixes
as an element count, not a length. This didn't actually affect anything
because the loop stops as soon as it finds a hostname element, and the
hostname element is always the first and only element. (No other element
types have ever been defined.)
This change fixes the parsing in case SNI is ever changed in the future.
Fixes#10793.
Change-Id: Iafdf3381942bc22b1f33595315c53dc6cc2e9f0f
Reviewed-on: https://go-review.googlesource.com/11059
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The test fails on Ubuntu Trusty for some reason, probably because of
some set of kernel patches.
Change-Id: I52f7ca50b96fea5725817c9e9198860d419f9313
Reviewed-on: https://go-review.googlesource.com/11055
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
This was found while fuzzing another program, triggering a panic in
x509.ParseECPrivateKey.
Fixes#11154
Change-Id: Ief35ead38adf14caec4d37b9eacf8a92e67cd1e6
Reviewed-on: https://go-review.googlesource.com/10712
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
When scanning with a width, as in %5s, C skips leading spaces
brefore counting the 5 characters. We should do the same.
Reword the documentation about widths to make this clear.
Fixes#9444
Change-Id: I443a6441adcf1c834057ef3977f9116a987a79cd
Reviewed-on: https://go-review.googlesource.com/10997
Reviewed-by: Andrew Gerrand <adg@golang.org>
Running -copylocks over a large corpus generates 1507 warnings.
Of those, only 3 are from the new anonymous function check,
but they are all bugs.
Fixes#10927.
Change-Id: I2672f6871036bed711beec5f88bc39aa8b3b6a94
Reviewed-on: https://go-review.googlesource.com/11051
Reviewed-by: Rob Pike <r@golang.org>
This is needed for code that relies on having the correct file set
when parsing an expression only. There's currently no other way to
get to the file set otherwise or to invoke the parser correctly to
work on an expression only with a given file set.
Change-Id: I325f174cb34b69284e627f59fe8334efa4eaa45c
Reviewed-on: https://go-review.googlesource.com/10998
Reviewed-by: Alan Donovan <adonovan@google.com>
Linux 3.19 made a change in the handling of setgroups and the 'gid_map' file to
address a security issue.
The upshot of the 3.19 changes is that in order to update the 'gid_maps' file,
use of the setgroups() system call in this user namespace must first be disabled
by writing "deny" to one of the /proc/PID/setgroups files for this namespace.
Also added tests for remapping uid_map and gid_map inside new user
namespace.
Fixes#10626
Change-Id: I4d2539acbab741a37092d277e10f31fc39a8feb7
Reviewed-on: https://go-review.googlesource.com/10670
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Sanity check the pax-header size field before using it.
Fixes#11167.
Change-Id: I9d5d0210c3990e6fb9434c3fe333be0d507d5962
Reviewed-on: https://go-review.googlesource.com/10954
Reviewed-by: David Symonds <dsymonds@golang.org>
The documentation says that newlines behave like this:
Scan etc.: newlines are spaces.
Scanln etc.: newlines terminate the scan.
Scanf etc.: newlines must match in input and format.
The code did not implement this behavior in all cases,
especially for Scanf. Make it behave:
- Fix the handling of spaces and newlines in ss.Advance.
The code is longer but now behaves as it should.
- Delete the reuse of the current ss in newScanState.
There is really no need, since it's only used in recursive
calls to Scan etc., and the flags are likely wrong. Simpler
just to allocate a new one every time, and likelier to
be correct.
Fixes#10862.
Change-Id: If060ac021017346723b0d62de4e5a305da898f68
Reviewed-on: https://go-review.googlesource.com/10991
Reviewed-by: Andrew Gerrand <adg@golang.org>
The command "go tool pprof help" does not work:
$ go tool pprof help
open help: no such file or directory
The right command is "go tool pprof -h".
Change-Id: Icef5d4ab76774905854e46665ac1166d26d35f46
Reviewed-on: https://go-review.googlesource.com/10970
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I would like to re-apply reverted http://golang.org/cl/8523.
Reverted tests still fail in some environments (see issue #10360).
It is easier to run tests selectively when in Go.
This CL prepares for the changes.
Updates #10360
Change-Id: Iefeb1d71cb3d1cfa653a6ccd9f6e35686c0c5b24
Reviewed-on: https://go-review.googlesource.com/10608
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL makes CL 10682 work on windows.
Fixes#9645 (again)
Change-Id: Ie9b9af8b041c483a236b46adad4a50aa6e598c92
Reviewed-on: https://go-review.googlesource.com/10930
Reviewed-by: Ian Lance Taylor <iant@golang.org>
As these tests were originally in bash, they are not designed to be
particularly hermetic. This CL adds various protective mechanisms to
try to catch cases where the tests can not run in parallel.
Change-Id: I983bf7b6ffba04eda58b4939eb89b0bdfcda8eff
Reviewed-on: https://go-review.googlesource.com/10911
Reviewed-by: Andrew Gerrand <adg@golang.org>
Examine the mtime of an existing file to guess a length of time to
sleep to ensure a different mtime.
Change-Id: I9e8b5c9486f5c3c8bd63125e3ed4763ce1ba767d
Reviewed-on: https://go-review.googlesource.com/10932
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This avoids a race with gcmarkwb_m that was leading to faults.
Fixes#10212.
Change-Id: I6fcf8d09f2692227063ce29152cb57366ea22487
Reviewed-on: https://go-review.googlesource.com/10816
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Forgot this one in my previous commit.
Change-Id: Ief089e99bdad24b3bcfb075497dc259d06cc727c
Reviewed-on: https://go-review.googlesource.com/10913
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Might get the Android build passing, or at least going further.
Change-Id: I08f97156a687abe5a3d95203922f4ffd84fbb212
Reviewed-on: https://go-review.googlesource.com/10924
Reviewed-by: David Crawshaw <crawshaw@golang.org>
These were found by grepping the comments from the go code and feeding
the output to aspell.
Change-Id: Id734d6c8d1938ec3c36bd94a4dbbad577e3ad395
Reviewed-on: https://go-review.googlesource.com/10941
Reviewed-by: Aamir Khan <syst3m.w0rm@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This issue was fixed in CL 10900.
Change-Id: I88f107cb73c8a515f39e02506ddd2ad1e286b1fb
Reviewed-on: https://go-review.googlesource.com/10940
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When the Stat or Fstat system calls return -1,
dirstat incorrectly returns ErrShortStat.
However, the error returned by Stat or Fstat
could be different. For example, when the
file doesn't exist, they return "does not exist".
Dirstat should return the error returned by
the system call.
Fixes#10911.
Fixes#11132.
Change-Id: Icf242d203d256f12366b1e277f99b1458385104a
Reviewed-on: https://go-review.googlesource.com/10900
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Process.handle was accessed without synchronization while wait() and
signal() could be called concurrently.
A first solution was to add a Mutex in Process but it was probably too
invasive given Process.handle is only used on Windows.
This version uses atomic operations to read the handle value. There is
still a race between isDone() and the value of the handle, but it only
leads to slightly incorrect error codes. The caller may get a:
errors.New("os: process already finished")
instead of:
syscall.EINVAL
which sounds harmless.
Fixes#9382
Change-Id: Iefcc687a1166d5961c8f27154647b9b15a0f748a
Reviewed-on: https://go-review.googlesource.com/9904
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This was a refactoring bug during
'go tool compile', CL 10289.
Change-Id: Ibfd333be39ec72bba331fdf352df619cc21851a9
Reviewed-on: https://go-review.googlesource.com/10849
Reviewed-by: Minux Ma <minux@golang.org>
GCM is traditionally used with a 96-bit nonce, but the standard allows
for nonces of any size. Non-standard nonce sizes are required in some
protocols, so add support for them in crypto/cipher's GCM
implementation.
Change-Id: I7feca7e903eeba557dcce370412b6ffabf1207ab
Reviewed-on: https://go-review.googlesource.com/8946
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Bool codegen was generating a temp for function calls
and other complex expressions, but was not using it.
This was a refactoring bug introduced by CL 7853.
The cmp code used to do (in short):
l, r := &n1, &n2
It was changed to:
l, r := nl, nr
But the requisite assignments:
nl, nr = &n1, &n2
were only introduced on one of two code paths.
Fixes#10654.
Change-Id: Ie8de0b3a333842a048d4308e02911bb10c6915ce
Reviewed-on: https://go-review.googlesource.com/10844
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previously we enforced both that the extended key usages of a client
certificate chain allowed for client authentication, and that the
client-auth EKU was in the leaf certificate.
This change removes the latter requirement. It's still the case that the
chain must be compatible with the client-auth EKU (i.e. that a parent
certificate isn't limited to another usage, like S/MIME), but we'll now
accept a leaf certificate with no EKUs for client-auth.
While it would be nice if all client certificates were explicit in their
intended purpose, I no longer feel that this battle is worthwhile.
Fixes#11087.
Change-Id: I777e695101cbeba069b730163533e2977f4dc1fc
Reviewed-on: https://go-review.googlesource.com/10806
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
After a little build coordinator change, this will get us sharding of
the race builder.
Update #11074
Change-Id: I4c55267563b6f5e213def7dd6707c837ae2106bf
Reviewed-on: https://go-review.googlesource.com/10845
Reviewed-by: Andrew Gerrand <adg@golang.org>
Change-Id: If11621985c0a5a1f2133cdc974f37fd944b93e5e
Reviewed-on: https://go-review.googlesource.com/10808
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The documentation for quick.Value says that it "returns an arbitrary
value of the given type." In spite of this, nil values for pointers were
never generated, which seems more like an oversight than an intentional
choice.
The lack of nil values meant that testing recursive type like
type Node struct {
Next *Node
}
with testing/quick would lead to a stack overflow since the data
structure would never terminate.
This change may break tests that don't check for nil with pointers
returned from quick.Value. Two such instances were found in the standard
library, one of which was in the testing/quick package itself.
Fixes#8818.
Change-Id: Id390dcce649d12fbbaa801ce6f58f5defed77e60
Reviewed-on: https://go-review.googlesource.com/10821
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
- remove TODO on non-existing fmt.Formatter type
(type exists now)
- guard uses of imported types against nil
Change-Id: I9ae8e5a448e73c84dec1606ea9d9ed5ddeee8dc6
Reviewed-on: https://go-review.googlesource.com/10777
Reviewed-by: Alan Donovan <adonovan@google.com>
Add .exe to exectable name, so it can be executed on windows.
Use proper windows paths when searching vet output.
Replace Skip with Skipf.
Fixes build
Change-Id: Ife40d8f5ab9d7093ca61c50683a358d4d6a3ba34
Reviewed-on: https://go-review.googlesource.com/10742
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Patrick Mézard <patrick@mezard.eu>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Commit 1303957 was supposed to enable write barriers during the
concurrent scan phase, but it only enabled *calls* to the write
barrier during this phase. It failed to update the redundant list of
write-barrier-enabled phases in gcmarkwb_m, so it still wasn't greying
objects during the scan phase.
This commit fixes this by replacing the redundant list of phases in
gcmarkwb_m with simply checking writeBarrierEnabled. This is almost
certainly redundant with checks already done in callers, but the last
time we tried to remove these redundant checks everything got much
slower, so I'm leaving it alone for now.
Fixes#11105.
Change-Id: I00230a3cb80a008e749553a8ae901b409097e4be
Reviewed-on: https://go-review.googlesource.com/10801
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Minux Ma <minux@golang.org>
Stack barriers assume that writes through pointers to frames above the
current frame will get write barriers, and hence these frames do not
need to be re-scanned to pick up these changes. For normal writes,
this is true. However, there are places in the runtime that use
typedmemmove to potentially write through pointers to higher frames
(such as mapassign1). Currently, typedmemmove does not execute write
barriers if the destination is on the stack. If there's a stack
barrier between the current frame and the frame being modified with
typedmemmove, and the stack barrier is not otherwise hit, it's
possible that the garbage collector will never see the updated pointer
and incorrectly reclaim the object.
Fix this by making heapBitsBulkBarrier (which lies behind typedmemmove
and its variants) detect when the destination is in the stack and
unwind stack barriers up to the point, forcing mark termination to
later rescan the effected frame and collect these pointers.
Fixes#11084. Might be related to #10240, #10541, #10941, #11023,
#11027 and possibly others.
Change-Id: I323d6cd0f1d29fa01f8fc946f4b90e04ef210efd
Reviewed-on: https://go-review.googlesource.com/10791
Reviewed-by: Russ Cox <rsc@golang.org>
Currently, write barriers are only enabled after completion of the
concurrent scan phase, as we enter the concurrent mark phase. However,
stack barriers are installed during the scan phase and assume that
write barriers will track changes to frames above the stack
barriers. Since write barriers aren't enabled until after stack
barriers are installed, we may miss modifications to the stack that
happen after installing the stack barriers and before enabling write
barriers.
Fix this by enabling write barriers during the scan phase.
This commit intentionally makes the minimal change to do this (there's
only one line of code change; the rest are comment changes). At the
very least, we should consider eliminating the ragged barrier that's
intended to synchronize the enabling of write barriers, but now just
wastes time. I've included a large comment about extensions and
alternative designs.
Change-Id: Ib20fede794e4fcb91ddf36f99bd97344d7f96421
Reviewed-on: https://go-review.googlesource.com/10795
Reviewed-by: Russ Cox <rsc@golang.org>
Currently checkmarks mode fails to rescan stacks because it sees the
leftover state bits indicating that the stacks haven't changed since
the last scan. As a result, it won't detect lost marks caused by
failing to scan stacks correctly during regular garbage collection.
Fix this by marking all stacks dirty before performing the checkmark
phase.
Change-Id: I1f06882bb8b20257120a4b8e7f95bb3ffc263895
Reviewed-on: https://go-review.googlesource.com/10794
Reviewed-by: Russ Cox <rsc@golang.org>
obj.ARET is the portable return mnemonic. ppc64.ARETURN is a legacy
alias.
This was done with
sed -i s/ppc64\.ARETURN/obj.ARET/ cmd/compile/**/*.go
sed -i s/ARETURN/obj.ARET/ cmd/internal/obj/ppc64/obj9.go
Change-Id: I4d8e83ff411cee764774a40ef4c7c34dcbca4e43
Reviewed-on: https://go-review.googlesource.com/10673
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
All of the architectures except ppc64 have only "RET" for the return
mnemonic. ppc64 used to have only "RETURN", but commit cf06ea6
introduced RET as a synonym for RETURN to make ppc64 consistent with
the other architectures. However, that commit was never followed up to
make the code itself consistent by eliminating uses of RETURN.
This commit replaces all uses of RETURN in the ppc64 assembly with
RET.
This was done with
sed -i 's/\<RETURN\>/RET/' **/*_ppc64x.s
plus one manual change to syscall/asm.s.
Change-Id: I3f6c8d2be157df8841d48de988ee43f3e3087995
Reviewed-on: https://go-review.googlesource.com/10672
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
gc should ideally consider this an error too; see golang/go#8560.
Change-Id: Ieee71c4ecaff493d7f83e15ba8c8a04ee90a4cf1
Reviewed-on: https://go-review.googlesource.com/10757
Reviewed-by: Robert Griesemer <gri@golang.org>
In x/tools, MethodSetCache was moved from x/tools/go/types to
x/tools/go/types/typeutil. Mirror that change.
Change-Id: Ib838a9518371473c83fa4abc2778d42f33947c98
Reviewed-on: https://go-review.googlesource.com/10771
Reviewed-by: Alan Donovan <adonovan@google.com>
Currently the stack barriers are installed at the next frame boundary
after gp.sched.sp + 1024*2^n for n=0,1,2,... However, when a G is in a
system call, we set gp.sched.sp to 0, which causes stack barriers to
be installed at *every* frame. This easily overflows the slice we've
reserved for storing the stack barrier information, and causes a
"slice bounds out of range" panic in gcInstallStackBarrier.
Fix this by using gp.syscallsp instead of gp.sched.sp if it's
non-zero. This is the same logic that gentraceback uses to determine
the current SP.
Fixes#11049.
Change-Id: Ie40eeee5bec59b7c1aa715a7c17aa63b1f1cf4e8
Reviewed-on: https://go-review.googlesource.com/10755
Reviewed-by: Russ Cox <rsc@golang.org>
ContinueOnError is particularly confusing, because it causes
FlagSet.Parse to return as soon as it sees an error. I gather that the
intent is "continue the program" rather than "continue parsing",
compared to exiting or panicking.
Change-Id: I27370ce1f321ea4debcee5b03faff3532495c71a
Reviewed-on: https://go-review.googlesource.com/10740
Reviewed-by: Rob Pike <r@golang.org>
Actually add all build flags, so we also get things like -race.
Fixes#10228.
Change-Id: I5f77dda9d1ee3208e1833702f12f68c2731c4b22
Reviewed-on: https://go-review.googlesource.com/10697
Reviewed-by: Russ Cox <rsc@golang.org>
Also fix the interaction between -buildmode and -shared.
It's okay for -shared to change the default build mode,
but it's not okay for it to silently override an explicit -buildmode=exe.
Change-Id: Id40f93d140cddf75b19e262b3ba4856ee09a07ba
Reviewed-on: https://go-review.googlesource.com/10315
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
People invoking the linker directly already have to change their scripts
to use the new "go tool link", so this is a good time to make the -X flag
behave like all other Go flags and take just a single argument.
The old syntax will continue to be accepted (it is rewritten into the new
syntax before flag parsing). Maybe some day we will be able to retire it.
Even if we never retire the old syntax, having the new syntax at least
makes the rewriting much less of a kludge.
Change-Id: I91e8df94f4c22b2186e81d7f1016b8767d777eac
Reviewed-on: https://go-review.googlesource.com/10310
Reviewed-by: Rob Pike <r@golang.org>
These are the Go 1.4 docs but refreshed for Go 1.5.
The most sigificant change is that all references to the Plan 9 toolchain are gone.
The tools no longer bear any meaningful resemblance.
Change-Id: I44f5cadb832a982323d7fee0b77673e55d761b35
Reviewed-on: https://go-review.googlesource.com/10298
Reviewed-by: Rob Pike <r@golang.org>
See golang.org/s/go15gomaxprocs for details.
Change-Id: I8de5df34fa01d31d78f0194ec78a2474c281243c
Reviewed-on: https://go-review.googlesource.com/10668
Reviewed-by: Rob Pike <r@golang.org>
The flag is available from the go test command as -count:
% go test -run XXX -bench . -count 3
PASS
BenchmarkSprintfEmpty 30000000 54.0 ns/op
BenchmarkSprintfEmpty 30000000 51.9 ns/op
BenchmarkSprintfEmpty 30000000 53.8 ns/op
BenchmarkSprintfString 10000000 238 ns/op
BenchmarkSprintfString 10000000 239 ns/op
BenchmarkSprintfString 10000000 234 ns/op
BenchmarkSprintfInt 10000000 232 ns/op
BenchmarkSprintfInt 10000000 226 ns/op
BenchmarkSprintfInt 10000000 225 ns/op
...
If -cpu is set, each test is run n times for each cpu value.
Original by r (CL 10663).
Change-Id: If3dfbdf21698952daac9249b5dbca66f5301e91b
Reviewed-on: https://go-review.googlesource.com/10669
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Non-ELF binary formats are much less flexible and typically do not
have a good place to store the build ID.
We store it as raw bytes at the beginning of the text segment.
The only system I know of that will be upset about this is NaCl,
and NaCl is an ELF system and does not use this.
For #11048.
Change-Id: Iaa7ace703c4cf36392e752eea9b55e2ce49e9826
Reviewed-on: https://go-review.googlesource.com/10708
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Other binary formats to follow.
For #11048.
Change-Id: Ia2d8b47c99c99d171c014b7cfd23c1c7ada5231c
Reviewed-on: https://go-review.googlesource.com/10707
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Other binary formats to follow.
Using our own note instead of the GNU build ID note because
we are not the GNU project, and I can't guarantee that the semantics
of our note and the semantics of the GNU note will match forever.
(Also they don't match today.)
For #11048.
Change-Id: Iec7e5a2e49d52b6d3a51b0aface2de7c77a45491
Reviewed-on: https://go-review.googlesource.com/10706
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The bootstrap restriction is to avoid needing cgo for package net.
There's no problem with building debug/elf and debug/dwarf,
so do that.
An upcoming CL is going to add more note processing code,
and it simplifies things not to have to think about the code being
missing half the time.
Change-Id: I0e2f120ac23f14db6ecfcec7bfe254a69abcf7b6
Reviewed-on: https://go-review.googlesource.com/10703
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The go/doc package doesn't remove unexported entries from const
and var blocks, so we must trim them ourselves.
Fixes#11008
Change-Id: Ibd60d87e09333964e2588340a2ca2b8804bbaa28
Reviewed-on: https://go-review.googlesource.com/10643
Reviewed-by: Russ Cox <rsc@golang.org>
- s|"golang.org/x/tools/go/exact"|"go/constant"|
- s|"golang.org/x/tools/go/types"|"go/types"|
- removed import of gcimporter
- import "go/importer" instead
- trivial adjustments to make use of go/importer
- adjusted import paths for whitelist.go
Change-Id: I43488ff44c329cd869c92dcc31193fb31bebfd29
Reviewed-on: https://go-review.googlesource.com/10695
Reviewed-by: Rob Pike <r@golang.org>
cp -r x/tools/cmd/vet cmd/vet without any changes.
The next change will adjust the source to use std
repo go/types and friends.
This may (temporarily) break the build; the next
commit (immediately following) will fix it. We do
it in two commits so that we can see the manual
changes.
Change-Id: Ic45dab7066f13923e21f8c61200c8c3fd447b171
Reviewed-on: https://go-review.googlesource.com/10694
Reviewed-by: Rob Pike <r@golang.org>
As of golang.org/cl/9154, running go test will override a previous
go install -a -tags=lldb std with the tag-less version of stdlib. So
we pass -tags=lldb into the relevant go test commands.
Change-Id: I1c718289d7212373a9383eff53a643f06598f5ed
Reviewed-on: https://go-review.googlesource.com/10701
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Also modifies 'dist test' to use that sharding, and removes some old
temporary stuff from dist test which are no longer required.
'dist test' now also supports running a list of tests given in
arguments, mutually exclusive with the existing -run=REGEXP flag. The
hacky fast paths for avoiding the 1 second "go list" latency are now
removed and only apply to the case where partial tests are run via
args, instead of regex. The build coordinator will use both styles
for awhile. (the statically-sharded ARM builders on scaleway will
continue to use regexps, but the dynamically-shared builders on GCE
will use the list of tests)
Updates #10029
Change-Id: I557800a54dfa6f3b5100ef4c26fe397ba5189813
Reviewed-on: https://go-review.googlesource.com/10688
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL resets the parent stack when printing a character or comment field struct.
In the case of XML elements, the previous parents stack must be considered. However,
charadata or comment fields can't be printed in other fields so it seems required to reset
the parent stack each time a chardata or comment field is printed.
Fixes#5072
Change-Id: I84f61c9bfce94133cd0c076c11211b9be5b4b1ac
Reviewed-on: https://go-review.googlesource.com/9910
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Reviewed-by: roger peppe <rogpeppe@gmail.com>
If 'go install' (with no arguments, meaning the current directory)
succeeds, remove the executable written by 'go build', if present.
This avoids leaving a stale binary behind during a sequence like:
go build
<test, mostly works, make small change>
go install
Before this CL, the current directory still has the stale binary
from 'go build'. If $PATH contains dot, running the name of
the program will find this stale binary instead of the new,
installed one.
Remove the 'go build' target during 'go install', both to clean
up the directory and to avoid accidentally running the stale binary.
Another way to view this CL is that it makes the go command
behave as if 'go install' is implemented by 'go build' followed by
moving the resulting binary to the install location.
See #9645 for discussion and objections.
Fixes#9645.
Change-Id: Ide109572f96bbb5a35be45dda17738317462a7d4
Reviewed-on: https://go-review.googlesource.com/10682
Reviewed-by: Rob Pike <r@golang.org>
We used to put a rebuilding barrier between GOPATHs, so that if
you had GOPATH=dir1:dir2 and you had "p" in dir1/src/p
and "q" in dir2/src/q, with "p" importing "q", then when you
ran 'go install p', it would see that it was working in dir1
and (since nothing from dir2 was explicitly mentioned)
would assume that everything in dir2 is up-to-date, provided
it is built at all.
This has the confusing behavior that if "q" hasn't been built ever,
then if you update sources in q and run 'go install p', the right
thing happens (q is rebuilt and then p), but after that, if you update
sources in q and run 'go install p', nothing happens: the installed
q is assumed up-to-date.
People using code conventions with multiple GOPATH entries
(for example, with commands in one place and libraries in another,
or vendoring conventions that try to avoid rewriting import paths)
run into this without realizing it and end up with incorrect build
results.
The original motivation here was to avoid rebuild standard packages
since a system-installed GOROOT might be unwritable.
The change introduced to separate GOROOT also separated
individual GOPATH entries. Later changes added a different, more
aggressive earlier shortcut for GOROOT in release settings,
so the code here is now only applying to (and confusing)
multiple GOPATH entries. Remove it.
Fixes#10509.
Change-Id: I687a3baa81eff4073b0d67f9acbc5a3ab192eda5
Reviewed-on: https://go-review.googlesource.com/9155
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The go command uses file modification times to decide when a
package is out of date: if the .a file is older than a source file,
the .a file needs to be rebuilt. This scheme breaks down when
multiple source files compile into a single .a file: if one source file
is removed but no other changes are made, there is no indication
that the .a file is out of date.
The fix is to store a value called a build ID in the package archive itself.
The build ID is a hash of the names of all source files compiled into the package.
A later go command can read the build ID out of the package archive
and compare to the build ID derived from the list of source files it now
sees in the directory. If the build IDs differ, the file list has changed,
and the package must be rebuilt.
There is a cost here: when scanning a package directory, in addition
to reading the beginning of every source file for build tags and imports,
the go command now also reads the beginning of the associated
package archive, for the build ID. This is at most a doubling in the
number of files read. On my 2012 MacBook Pro, the time for
'go list std' increases from about 0.215 seconds to about 0.23 seconds.
For executable binaries, the approach is the same except that the
build ID information is stored in a trailer at the end of the executable file.
It remains to be seen if anything objects to the trailer.
I don't expect problems except maybe on Plan 9.
Fixes#3895.
Change-Id: I21b4ebf5890c1a39e4a013eabe1ddbb5f3510c04
Reviewed-on: https://go-review.googlesource.com/9154
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Suggested during code reviews of last 15 CLs (or so).
Change-Id: If780f6eb47a7a31df133c64d5dcf0eaf04d8447b
Reviewed-on: https://go-review.googlesource.com/10675
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
stkcheck is flow-insensitive: It processes calls in PC order.
Since morestack was always the first call in a function,
it was a safe, conservative approximation to simply adjust stack
space as we went, recognizing morestack when it showed up.
Subsequent CLS will rearrange the function prologue;
morestack may no longer be the first call in a function.
Introducing flow-sensitivity to stkcheck would allow this,
and possibly allow a smaller stackguard.
It is also a high risk change and possibly expensive.
Instead, assume that all calls to morestack occur as
part of the function prologue, no matter where they
are located in the program text.
Updates #10587.
Change-Id: I4dcdd4256a980fc4bc433a68a10989ff57f7034f
Reviewed-on: https://go-review.googlesource.com/10496
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Otherwise subsequent tests won't see any modified GOROOT.
With this CL I can move my GOROOT, set GOROOT to the new location, and
the runtime tests pass. Previously the crash_tests would instead look
for the GOROOT baked into the binary, instead of the env var:
--- FAIL: TestGcSys (0.01s)
crash_test.go:92: building source: exit status 2
go: cannot find GOROOT directory: /home/bradfitz/go
--- FAIL: TestGCFairness (0.01s)
crash_test.go:92: building source: exit status 2
go: cannot find GOROOT directory: /home/bradfitz/go
--- FAIL: TestGdbPython (0.07s)
runtime-gdb_test.go:64: building source exit status 2
go: cannot find GOROOT directory: /home/bradfitz/go
--- FAIL: TestLargeStringConcat (0.01s)
crash_test.go:92: building source: exit status 2
go: cannot find GOROOT directory: /home/bradfitz/go
Update #10029
Change-Id: If91be0f04d3acdcf39a9e773a4e7905a446bc477
Reviewed-on: https://go-review.googlesource.com/10685
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
The only unreviewed change is in mparith3.go.
Change-Id: Iec0885e7688981cbaed04c152dc9b1c7032677e6
Reviewed-on: https://go-review.googlesource.com/10665
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
The build ID is an opaque token supplied by the build system.
The compiler writes it out early in the Go export metadata
(the second line), in a way that does not bother existing readers.
The intent is that the go command can use this to store information
about the sources for the generated code, so that it can detect
stale packages even in cases (like removed files) where mtimes fail.
Change-Id: Ib5082515d6cde8a07a8d4b5c69d1e8e4190cb5e1
Reviewed-on: https://go-review.googlesource.com/9153
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This one didn't get written out.
Change-Id: Iee173861fb4dc7cafa64ba5f601f4664b6e8da4e
Reviewed-on: https://go-review.googlesource.com/10681
Reviewed-by: Russ Cox <rsc@golang.org>
In particular, this avoids moving the mtime on runtime/zversion.go
forward unless the file is out of date. In turn, this makes cross compiles
that run dist multiple times coexist nicely.
(It's no longer necessary to run dist multiple times to set up cross compiles,
but people still might, and it's easy to fix regardless.)
Fixes#4749.
Change-Id: Id430525f168f106bc4b821ca74b2ca498a748f14
Reviewed-on: https://go-review.googlesource.com/9152
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It was mishandling conjunctions containing negations.
Change-Id: Ife571b28416870ba2ceadbdac5ecb4670432bba1
Reviewed-on: https://go-review.googlesource.com/9151
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is follow-up to CL10607
- Refactor AddParseTree() to use t.associate()
- Refactor Parse() to use AddParseTree() to put entries into common structure
- Clone() should not put entry in t.tmpl for undefined template
- Clarify documentation for Templates()
- Clarify documentation for AddParseTree() to include the error case
Updates #10910
Uodates #10926
Includes test cases for most of the above changes
Change-Id: I25b2fce6f9651272866f881acf44e4dbca04a4a8
Reviewed-on: https://go-review.googlesource.com/10622
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also add a reference to the strings blog post.
Fixes#11045.
Change-Id: Ic0a8908cbd7b51a36d104849fa0e8abfd54de2b9
Reviewed-on: https://go-review.googlesource.com/10662
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Sending out the conversion of a single test to get comments on the
overall approach. Converting more tests will follow.
Change-Id: I4755442d08aeb6f74c46856ae406fec41cf8d5dc
Reviewed-on: https://go-review.googlesource.com/10464
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
It was an oversight (but as linux/arm64 doesn't support internal
linking and always use external linking with cgo, no harm is done.)
Change-Id: Ie5f2b445cb67a8e63d6b868e63379c68847554f9
Reviewed-on: https://go-review.googlesource.com/10636
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently the GODEBUG=gctrace=1 trace line includes "@n.nnns" to
indicate the time that the GC cycle ended relative to the time the
program started. This was meant to be consistent with the utilization
as of the end of the cycle, which is printed next on the trace line,
but it winds up just being confusing and unexpected.
Change the trace line to include the time that the GC cycle started
relative to the time the program started.
Change-Id: I7d64580cd696eb17540716d3e8a74a9d6ae50650
Reviewed-on: https://go-review.googlesource.com/10634
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Due to the requirements of parsing template definitions that mention
other templates that are not yet defined, a Template can be in two states:
defined and undefined. Thus, although one calls New, the resulting
template has no definition even though it exists as a data structure.
Thus, for example, will return nil for a template that is named but not
yet defined.
Fixes#10910Fixes#10926
Clarify the documentation a little to explain this,
Also tidy up the code a little and remove a spurious call to init.
Change-Id: I22cc083291500bca424e83dc12807e0de7b00b7a
Reviewed-on: https://go-review.googlesource.com/10641
Reviewed-by: Andrew Gerrand <adg@golang.org>
This commit implements stack barriers to minimize the amount of
stack re-scanning that must be done during mark termination.
Currently the GC scans stacks of active goroutines twice during every
GC cycle: once at the beginning during root discovery and once at the
end during mark termination. The second scan happens while the world
is stopped and guarantees that we've seen all of the roots (since
there are no write barriers on writes to local stack
variables). However, this means pause time is proportional to stack
size. In particularly recursive programs, this can drive pause time up
past our 10ms goal (e.g., it takes about 150ms to scan a 50MB heap).
Re-scanning the entire stack is rarely necessary, especially for large
stacks, because usually most of the frames on the stack were not
active between the first and second scans and hence any changes to
these frames (via non-escaping pointers passed down the stack) were
tracked by write barriers.
To efficiently track how far a stack has been unwound since the first
scan (and, hence, how much needs to be re-scanned), this commit
introduces stack barriers. During the first scan, at exponentially
spaced points in each stack, the scan overwrites return PCs with the
PC of the stack barrier function. When "returned" to, the stack
barrier function records how far the stack has unwound and jumps to
the original return PC for that point in the stack. Then the second
scan only needs to proceed as far as the lowest barrier that hasn't
been hit.
For deeply recursive programs, this substantially reduces mark
termination time (and hence pause time). For the goscheme example
linked in issue #10898, prior to this change, mark termination times
were typically between 100 and 500ms; with this change, mark
termination times are typically between 10 and 20ms. As a result of
the reduced stack scanning work, this reduces overall execution time
of the goscheme example by 20%.
Fixes#10898.
The effect of this on programs that are not deeply recursive is
minimal:
name old time/op new time/op delta
BinaryTree17 3.16s ± 2% 3.26s ± 1% +3.31% (p=0.000 n=19+19)
Fannkuch11 2.42s ± 1% 2.48s ± 1% +2.24% (p=0.000 n=17+19)
FmtFprintfEmpty 50.0ns ± 3% 49.8ns ± 1% ~ (p=0.534 n=20+19)
FmtFprintfString 173ns ± 0% 175ns ± 0% +1.49% (p=0.000 n=16+19)
FmtFprintfInt 170ns ± 1% 175ns ± 1% +2.97% (p=0.000 n=20+19)
FmtFprintfIntInt 288ns ± 0% 295ns ± 0% +2.73% (p=0.000 n=16+19)
FmtFprintfPrefixedInt 242ns ± 1% 252ns ± 1% +4.13% (p=0.000 n=18+18)
FmtFprintfFloat 324ns ± 0% 323ns ± 0% -0.36% (p=0.000 n=20+19)
FmtManyArgs 1.14µs ± 0% 1.12µs ± 1% -1.01% (p=0.000 n=18+19)
GobDecode 8.88ms ± 1% 8.87ms ± 0% ~ (p=0.480 n=19+18)
GobEncode 6.80ms ± 1% 6.85ms ± 0% +0.82% (p=0.000 n=20+18)
Gzip 363ms ± 1% 363ms ± 1% ~ (p=0.077 n=18+20)
Gunzip 90.6ms ± 0% 90.0ms ± 1% -0.71% (p=0.000 n=17+18)
HTTPClientServer 51.5µs ± 1% 50.8µs ± 1% -1.32% (p=0.000 n=18+18)
JSONEncode 17.0ms ± 0% 17.1ms ± 0% +0.40% (p=0.000 n=18+17)
JSONDecode 61.8ms ± 0% 63.8ms ± 1% +3.11% (p=0.000 n=18+17)
Mandelbrot200 3.84ms ± 0% 3.84ms ± 1% ~ (p=0.583 n=19+19)
GoParse 3.71ms ± 1% 3.72ms ± 1% ~ (p=0.159 n=18+19)
RegexpMatchEasy0_32 100ns ± 0% 100ns ± 1% -0.19% (p=0.033 n=17+19)
RegexpMatchEasy0_1K 342ns ± 1% 331ns ± 0% -3.41% (p=0.000 n=19+19)
RegexpMatchEasy1_32 82.5ns ± 0% 81.7ns ± 0% -0.98% (p=0.000 n=18+18)
RegexpMatchEasy1_1K 505ns ± 0% 494ns ± 1% -2.16% (p=0.000 n=18+18)
RegexpMatchMedium_32 137ns ± 1% 137ns ± 1% -0.24% (p=0.048 n=20+18)
RegexpMatchMedium_1K 41.6µs ± 0% 41.3µs ± 1% -0.57% (p=0.004 n=18+20)
RegexpMatchHard_32 2.11µs ± 0% 2.11µs ± 1% +0.20% (p=0.037 n=17+19)
RegexpMatchHard_1K 63.9µs ± 2% 63.3µs ± 0% -0.99% (p=0.000 n=20+17)
Revcomp 560ms ± 1% 522ms ± 0% -6.87% (p=0.000 n=18+16)
Template 75.0ms ± 0% 75.1ms ± 1% +0.18% (p=0.013 n=18+19)
TimeParse 358ns ± 1% 364ns ± 0% +1.74% (p=0.000 n=20+15)
TimeFormat 360ns ± 0% 372ns ± 0% +3.55% (p=0.000 n=20+18)
Change-Id: If8a9bfae6c128d15a4f405e02bcfa50129df82a2
Reviewed-on: https://go-review.googlesource.com/10314
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently there's a race between stopg scanning another G's stack and
the G reaching a preemption point and scanning its own stack. When
this race occurs, the G's stack is scanned twice. Currently this is
okay, so this race is benign.
However, we will shortly be adding stack barriers during the first
stack scan, so scanning will no longer be idempotent. To prepare for
this, this change ensures that each stack is scanned only once during
each GC phase by checking the flag that indicates that the stack has
been scanned in this phase before scanning the stack.
Change-Id: Id9f4d5e2e5b839bc3f200ec1723a4a12dd677ab4
Reviewed-on: https://go-review.googlesource.com/10458
Reviewed-by: Rick Hudson <rlh@golang.org>
