Pulling function calls out to happen before the
expression being evaluated was causing illegal
reorderings even without inlining; with inlining
it got worse. This CL adds a separate ordering pass
to move things with a fixed order out of expressions
and into the statement sequence, where they will
not be reordered by walk.
Replaces lvd's CL 5534079.
Fixes#2740.
R=lvd
CC=golang-dev
https://golang.org/cl/5569062
Added a cache to compensate for extra call overhead.
go test -bench=Print marginally faster (in the noise).
R=r
CC=golang-dev
https://golang.org/cl/5574061
The implementation is divided into 4 phases:
1) export filtering of an incoming AST if necessary (exports.go)
2) reading of a possibly filtered AST (reader.go: type reader)
3) method set computation (reader.go)
4) sorting and creation of final documentation (reader.go)
In contrast to the old implementation, the presentation data
(Names, Docs, Decls, etc.) are created immediately upon reading
the respective AST node. Also, all types are collected (embedded
or not) in a uniform way.
Once the entire AST has been processed, all methods and types
have been collected and the method sets for each type can be
computed (phase 3).
To produce the final documentation, the method sets and value
maps are sorted.
There are no API changes. Passes the existing test suite unchanged.
R=rsc, rogpeppe
CC=golang-dev
https://golang.org/cl/5554044
Reimplement the test based on code from adg@golang.org.
The previous version has a race since the file is closed via defer
rather than in the go routine. This meant that the file could be
closed before the go routine has actually received io.EOF. It then
receives EBADF and continues to do zero-byte writes to the pipe.
This addresses an issue seen on FreeBSD and OpenBSD, where the test
passes but exits with a SIGPIPE, resulting in a failure.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/5554083
Without this change it's possible to launch godoc,
immediately GET /, and see a directory listing instead of root.html
R=gri
CC=golang-dev
https://golang.org/cl/5575054
work in progress, and we are not ready to freeze its API for Go 1.
Package html still exists, containing just two functions: EscapeString
and UnescapeString.
Both the packages at exp/html and html are "package html". The former
is a superset of the latter.
At some point in the future, the exp/html code will move back into
html, once we have finalized the parser API.
R=rsc, dsymonds
CC=golang-dev
https://golang.org/cl/5571059
Marshaler has a number of open areas that need
further thought (e.g. it doesn't handle attributes,
it's supposed to handle tag names internally but has
no information to do so, etc).
We're removing it now and will bring it back with an
interface that covers these aspects, after Go 1.
Related to issue 2771, but doesn't fix it.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5574057
In order to allow buildscript.sh to generate buildscripts for all
$GOOS/$GOARCH combinations, we have to generate dummy files for cmd/go.
Fixes#2586.
R=rsc, golang-dev
CC=golang-dev
https://golang.org/cl/5557050
Also, add an explicit error type when the right hand side is an unexported
function.
R=golang-dev, gri, rogpeppe, agl, rsc
CC=golang-dev
https://golang.org/cl/5564048
Includes gofix module. The only case not covered should be
xml.Unmarshal, since it remains with a similar interface, and
would require introspecting the type of its first argument
better.
Fixes#2626.
R=golang-dev, rsc, gustavo
CC=golang-dev
https://golang.org/cl/5574053
CL 5572043 removed the last uses of this field.
The information is readily available from Type.Decl.
R=rsc, golang-dev
CC=golang-dev
https://golang.org/cl/5570049
The bitLen function currently shifts out blocks of 8 bits at a time.
This change replaces this sorta-linear algorithm with a log(N)
one (shift out 16 bits, then 8, then 4, then 2, then 1).
I left the start of it linear at 16 bits at a time so that
the function continues to work with 32 or 64 bit values
without any funkiness.
The algorithm is similar to several of the nlz ("number of
leading zeros") algorithms from "Hacker's Delight" or the
"bit twiddling hacks" pages.
Doesn't make a big difference to the existing benchmarks, but
I'm using the code in a different context that calls bitLen
much more often, so it seemed worthwhile making the existing
codebase faster so that it's a better building block.
Microbenchmark results on a 64-bit Macbook Pro using 6g from weekly.2012-01-20:
benchmark old ns/op new ns/op delta
big.BenchmarkBitLen0 4 6 +50.12%
big.BenchmarkBitLen1 4 6 +33.91%
big.BenchmarkBitLen2 6 6 +3.05%
big.BenchmarkBitLen3 7 6 -19.05%
big.BenchmarkBitLen4 9 6 -30.19%
big.BenchmarkBitLen5 11 6 -42.23%
big.BenchmarkBitLen8 16 6 -61.78%
big.BenchmarkBitLen9 5 6 +18.29%
big.BenchmarkBitLen16 18 7 -60.99%
big.BenchmarkBitLen17 7 6 -4.64%
big.BenchmarkBitLen31 19 7 -62.49%
On an ARM machine (with the previous weekly):
benchmark old ns/op new ns/op delta
big.BenchmarkBitLen0 37 50 +36.56%
big.BenchmarkBitLen1 59 51 -13.69%
big.BenchmarkBitLen2 74 59 -20.40%
big.BenchmarkBitLen3 92 60 -34.89%
big.BenchmarkBitLen4 110 59 -46.09%
big.BenchmarkBitLen5 127 60 -52.68%
big.BenchmarkBitLen8 181 59 -67.24%
big.BenchmarkBitLen9 78 60 -23.05%
big.BenchmarkBitLen16 199 69 -65.13%
big.BenchmarkBitLen17 91 70 -23.17%
big.BenchmarkBitLen31 210 95 -54.43%
R=golang-dev, dave, edsrzf, gri
CC=golang-dev
https://golang.org/cl/5570044
