Russ Cox [Thu, 4 Jun 2015 18:41:02 +0000 (14:41 -0400)]
cmd/go: use ELF note instead of binary stamp on ELF systems
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>
Russ Cox [Thu, 4 Jun 2015 18:31:05 +0000 (14:31 -0400)]
cmd/link: add -buildid flag to write Go build ID to ELF output, same as cmd/compile
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>
Russ Cox [Thu, 4 Jun 2015 18:30:30 +0000 (14:30 -0400)]
cmd/link: add -h flag, for debugging, same as cmd/compile
Change-Id: I3c9b05879fe0b6e94b63e9b65e4411ba2a917134
Reviewed-on: https://go-review.googlesource.com/10705 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Thu, 4 Jun 2015 18:27:39 +0000 (14:27 -0400)]
cmd/go, cmd/link: use "Go" not "GO" as ELF note identifier
Change-Id: I038e892725836ab7718f7638e8ad5712953f2cb5
Reviewed-on: https://go-review.googlesource.com/10704 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Thu, 4 Jun 2015 18:17:51 +0000 (14:17 -0400)]
cmd/go: simplify ELF note reading and enable during bootstrap
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>
Robert Griesemer [Thu, 4 Jun 2015 20:07:22 +0000 (13:07 -0700)]
cmd/vet: adjust vet to use go/types and friends from std repo
- 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>
Robert Griesemer [Thu, 4 Jun 2015 19:54:58 +0000 (12:54 -0700)]
cmd/vet: move cmd/vet into std repo
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>
David Crawshaw [Thu, 4 Jun 2015 19:03:38 +0000 (15:03 -0400)]
cmd/dist: use -tags=lldb for iOS tests
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.
Brad Fitzpatrick [Thu, 4 Jun 2015 06:21:30 +0000 (23:21 -0700)]
test: make test/run.go support sharding
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)
runtime, cmd/internal/obj/arm: improve arm function prologue
When stack growth is not needed, as it usually is not,
execute only a single conditional branch
rather than three conditional instructions.
This adds 4 bytes to every function,
but might speed up execution in the common case.
Hajime Hoshi [Sat, 9 May 2015 19:22:11 +0000 (04:22 +0900)]
encoding/xml: Reset the parent stack before printing a chardata or comment field in a struct
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>
cmd/go: clean up after 'go build' during 'go install'
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>
cmd/go: always rebuild GOPATH code that looks out of date
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>
cmd/go: detect when package or binary is stale due to removed source file
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>
Change-Id: I688e3790964fe42f48c19f697ec38094a92fe1c1
Reviewed-on: https://go-review.googlesource.com/10531 Reviewed-by: Ian Lance Taylor <iant@golang.org>
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.
Russ Cox [Tue, 19 May 2015 20:49:47 +0000 (16:49 -0400)]
cmd/internal/gc: accept map literals with omitted key type
Fixes #10209.
Change-Id: I248434f9195c868befd1ed8a6000a9cac72d1df8
Reviewed-on: https://go-review.googlesource.com/10263 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Brad Fitzpatrick [Wed, 3 Jun 2015 23:16:32 +0000 (16:16 -0700)]
runtime: fix TestFixedGOROOT to properly restore the GOROOT env var after test
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
cmd/internal/gc: add -buildid flag to write build ID into object file
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>
cmd/dist: do not rewrite files that already have the correct content
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.)
Change-Id: Id443fd406e9c611d5dfabc71a98eb71d1cc0972c
Reviewed-on: https://go-review.googlesource.com/9150 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Aamir Khan [Wed, 3 Jun 2015 03:51:56 +0000 (12:51 +0900)]
text/template: refactor code to accomodate bi-state requirement for templates
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>
Change-Id: If624a2d72ec04ef30a1bc7ce76c0d61a526d8a37
Reviewed-on: https://go-review.googlesource.com/10532 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Tue, 2 Jun 2015 18:48:12 +0000 (14:48 -0400)]
runtime: print start of GC cycle in gctrace, rather than end
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.
Rob Pike [Tue, 2 Jun 2015 18:49:24 +0000 (11:49 -0700)]
text/template: clarify the documentation around template definitions
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 #10910
Fixes #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>
Austin Clements [Wed, 20 May 2015 20:30:49 +0000 (16:30 -0400)]
runtime: implement GC stack barriers
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:
Austin Clements [Thu, 28 May 2015 16:37:12 +0000 (12:37 -0400)]
runtime: avoid double-scanning of stacks
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>
Austin Clements [Wed, 20 May 2015 20:16:04 +0000 (16:16 -0400)]
runtime: steal space for stack barrier tracking from stack
The stack barrier code will need a bookkeeping structure to keep track
of the overwritten return PCs. This commit introduces and allocates
this structure, but does not yet use the structure.
We don't want to allocate space for this structure during garbage
collection, so this commit allocates it along with the allocation of
the corresponding stack. However, we can't do a regular allocation in
newstack because mallocgc may itself grow the stack (which would lead
to a recursive allocation). Hence, this commit makes the bookkeeping
structure part of the stack allocation itself by stealing the
necessary space from the top of the stack allocation. Since the size
of this bookkeeping structure is logarithmic in the size of the stack,
this has minimal impact on stack behavior.
Austin Clements [Wed, 20 May 2015 19:29:53 +0000 (15:29 -0400)]
runtime: decouple stack bounds and stack allocation size
Currently the runtime assumes that the allocation for the stack is
exactly [stack.lo, stack.hi). We're about to steal a small part of
this allocation for per-stack GC metadata. To prepare for this, this
commit adds a field to the G for the allocated size of the stack.
With this change, stack.lo and stack.hi continue to act as the true
bounds on the stack, but are no longer also used as the bounds on the
stack allocation.
(I also tried this the other way around, where stack.lo and stack.hi
remained the allocation bounds and I introduced a new top of stack.
However, there are far more places that assume stack.hi is the true
top of the stack than there are places that assume it's the top of the
allocation.)
Austin Clements [Thu, 21 May 2015 18:12:29 +0000 (14:12 -0400)]
runtime: clean up signalstack API
Currently signalstack takes a lower limit and a length and all calls
hard-code the passed length. Change the API to take a *stack and
compute the lower limit and length from the passed stack.
This will make it easier for the runtime to steal some space from the
top of the stack since it eliminates the hard-coded stack sizes.
Austin Clements [Sun, 31 May 2015 01:47:00 +0000 (21:47 -0400)]
runtime: increase precision of gctrace times
Currently we truncate gctrace clock and CPU times to millisecond
precision. As a result, many phases are typically printed as 0, which
is fine for user consumption, but makes gathering statistics and
reports over GC traces difficult.
In 1.4, the gctrace line printed times in microseconds. This was
better for statistics, but not as easy for users to read or interpret,
and it generally made the trace lines longer.
This change strikes a balance between these extremes by printing
milliseconds, but including the decimal part to two significant
figures down to microsecond precision. This remains easy to read and
interpret, but includes more precision when it's useful.
For example, where the code currently prints,
gc #29 @1.629s 0%: 0+2+0+12+0 ms clock, 0+2+0+0/12/0+0 ms cpu, 4->4->2 MB, 4 MB goal, 1 P
this prints,
gc #29 @1.629s 0%: 0.005+2.1+0+12+0.29 ms clock, 0.005+2.1+0+0/12/0+0.29 ms cpu, 4->4->2 MB, 4 MB goal, 1 P
Andrew Gerrand [Tue, 2 Jun 2015 18:01:56 +0000 (11:01 -0700)]
net/http: set nosniff header when serving Error
The Error function is a potential XSS vector if a user can control the
error message.
For example, an http.FileServer when given a request for this path
/<script>alert("xss!")</script>
may return a response with a body like this
open <script>alert("xss!")</script>: no such file or directory
Browsers that sniff the content may interpret this as HTML and execute
the script. The nosniff header added by this CL should help, but we
should also try santizing the output entirely.
Mikio Hara [Wed, 20 May 2015 14:20:43 +0000 (23:20 +0900)]
net: fix parsing literal IP addresses in local database
This change fixes incorrect parsing of literal IP addresses in local
database when the addresses contain IPv6 zone identifiers, are in
dotted-decimal notation or in colon-hexadecimal notation with leading
zeros.
https://golang.org/cl/5851 already fixed the code path using getaddrinfo
via cgo. This change fixes the remaining non-cgo code path.
Dave Cheney [Tue, 2 Jun 2015 01:04:45 +0000 (11:04 +1000)]
net: fix undetected set and not used error
Fixes an error where the compiler did not spot that the shadowed err
value was set again after being read. That second assignment was lost
as the value was redeclared in an inner scope.
Spotted by Gordon Klass, https://groups.google.com/forum/#!topic/golang-nuts/MdDLbvOjb4o
Didier Spezia [Wed, 27 May 2015 11:44:19 +0000 (11:44 +0000)]
text/template: fix variadic function call corner case
Executing a template involving variadic functions featuring
a []interface{} slice (such as printf) could result in a
panic in reflect.Value.Call, due to incorrect type checking.
The following expressions failed (with a panic):
{{true|printf}}
{{1|printf}}
{{1.1|printf}}
{{'x'|printf}}
{{1+2i|printf}}
Implemented proper type checks for the fixed parameters of the
variadic functions.
Fixes #10946
Change-Id: Ia75333f651f73b3d2e024cb0c47cc30d90cb6852
Reviewed-on: https://go-review.googlesource.com/10403 Reviewed-by: Rob Pike <r@golang.org>
Didier Spezia [Thu, 21 May 2015 21:35:49 +0000 (21:35 +0000)]
html/template: prevent panic when escaping actions involving chain nodes
The current escape code panics when an action involves chain nodes.
Such nodes can be seen in the following situation:
{{ . | AAA.B }} - AAA being a registered function
The above expression is actually valid, because AAA could return a
map containing a B key. The tests in text/template explicitly
demonstrate this case.
Fix allIdents to cover also chain nodes.
While I was investigating this issue, I realized that the tests
introduced in similar CL 9621 were incorrect. Parse errors were
caught as expected, but for the wrong reason. Fixed them as well.
No changes in text/template code itself.
Fixes #10801
Change-Id: Ic9fe43b63669298ca52c3f499e2725dd2bb818a8
Reviewed-on: https://go-review.googlesource.com/10340 Reviewed-by: Rob Pike <r@golang.org>
Konstantin Shaposhnikov [Sun, 17 May 2015 04:07:04 +0000 (12:07 +0800)]
cmd/doc: try better when looking for package dir
When go doc is invoked with a single package name argument (e.g. go doc pkgname)
it needs to find the directory of the requested package sources in GOPATH.
GOPATH might contain directories with the same name as the requested package
that do no contain any *.go files. This change makes "go doc" ignore such
directories when looking for possible package directories.
This fixes #10882
Change-Id: Ib3d4ea69a25801c34cbe7b044de9870ba12f9aa8
Reviewed-on: https://go-review.googlesource.com/10190 Reviewed-by: Rob Pike <r@golang.org>
Austin Clements [Fri, 29 May 2015 16:13:50 +0000 (12:13 -0400)]
runtime: document that runtime.GC() blocks until GC is complete
runtime.GC() is intentionally very weakly specified. However, it is so
weakly specified that it's difficult to know that it's being used
correctly for its one intended use case: to ensure garbage collection
has run in a test that is garbage-sensitive. In particular, it is
unclear whether it is synchronous or asynchronous. In the old STW
collector this was essentially self-evident; short of queuing up a
garbage collection to run later, it had to be synchronous. However,
with the concurrent collector, there's evidence that people are
inferring that it may be asynchronous (e.g., issue #10986), as this is
both unclear in the documentation and possible in the implementation.
In fact, runtime.GC() runs a fully synchronous STW collection. We
probably don't want to commit to this exact behavior. But we can
commit to the essential property that tests rely on: that runtime.GC()
does not return until the GC has finished.
Change-Id: Ifc3045a505e1898ecdbe32c1f7e80e2e9ffacb5b
Reviewed-on: https://go-review.googlesource.com/10488 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
Adam Langley [Sat, 30 May 2015 16:40:17 +0000 (09:40 -0700)]
encoding/pem: be more permissive about decoding empty blocks.
As noted in bug #10980, an empty PEM block is encoded as
-----BEGIN foo-----
-----END foo-----
However, Decode failed to process this.
RFC 1421 doesn't answer what the encoding of the empty block should be
because PEM messages always contain at least one header. However, PEM
these days is just the encoding format – nobody uses the rest of PEM any
longer.
Having the empty block not contain a newline seems most correct because
https://tools.ietf.org/html/rfc1421#section-9 clearly says that the
optional “pemtext” carries the leading new-line with it. So if omitted,
the new-line should be omitted too.
None the less, this changes makes encoding/pem permissive, accepting any
number of blank lines in an empty PEM block.
Memory usage has been reduced.
The tests are still slow,
but that is issue #10571.
/usr/bin/time shows significant variation
in the peak memory usage compiling with tip.
This is unsurprising, given GC.
Using Go 1.4.2, memory is stable at 410mb.
Using tip at d2ee09298,
memory ranges from 470mb (+15%) to 534mb (+30%),
with a mean of 504mb (+23%), with n=50.
David Chase [Wed, 27 May 2015 21:33:46 +0000 (17:33 -0400)]
cmd/compile: reject p-notation floats in Go source files
Use pkgimport == nil (or not) to distinguish between
parsing .go source files where "p" exponent specifier
is not allowed and parsing .a or .o export data where
it is. Use that to control error when p-exponent is
seen.
Austin Clements [Tue, 26 May 2015 18:32:24 +0000 (14:32 -0400)]
runtime: disable GC around TestGoroutineParallelism
TestGoroutineParallelism can deadlock if the GC runs during the
test. Currently it tries to prevent this by forcing a GC before the
test, but this is best effort and fails completely if GOGC is very low
for testing.
This change replaces this best-effort fix with simply setting GOGC to
off for the duration of the test.
Austin Clements [Wed, 27 May 2015 19:20:49 +0000 (15:20 -0400)]
cmd/compile: avoid temporary in race mode with slice and append
Currently when the race detector is enabled, orderexpr always creates
a temporary for slice and append operations. This used to be necessary
because the race detector had a different code path for slice
assignment that required this temporary. Unfortunately, creating this
temporary inhibits the optimization that eliminates write barriers
when a slice is assigned only to change its length or cap. For most
code, this is bad for performance, and in go:nowritebarrier functions
in the runtime, this can mean the difference between compiling and not
compiling.
Now the race detector uses the regular slice assignment code, so
creating this temporary is no longer necessary.