I realize I didn't send the tests in last time. Anyway, I added
a test that knows too much about the package's internal structure,
and I'm not sure whether it's the right thing to do.
Vadik.
R=bradfitz, rsc, go.peter.90
CC=golang-dev
https://golang.org/cl/5450073
This redefinition means that the public signature of html/template
does not refer to text/template.
Fixes#2546.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5487083
We only want to attempt to un-gzip if there's a body (not in
response to a HEAD)
This was accidentally passing before, but revealed to be broken
when c3c6e72d7cc went in.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5477093
The obvious fix is breaking the build in non-obvious ways.
Reverting while waiting for the correct fix, if any is needed.
««« original CL description
net/http: fix bug in error checking
Thanks to josef86@gmail.com for pointing this out.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/5477092
»»»
R=iant
CC=golang-dev
https://golang.org/cl/5488085
Cross- and intra package inlining of single assignments or return <expression>.
Minus some hairy cases, currently including other calls, expressions with closures and ... arguments.
R=rsc, rogpeppe, adg, gri
CC=golang-dev
https://golang.org/cl/5400043
breaks 64-bit build
««« original CL description
8c: handle 64-bit switch value
Cases must still be 32-bit values, but one thing at a time.
R=ality, ken2, ken
CC=golang-dev
https://golang.org/cl/5485063
»»»
R=ken2
CC=golang-dev
https://golang.org/cl/5488075
The transmitter must encode an interface value if it is to be decoded
into an interface value, but it's a common and confusing error to
encode a concrete value and attempt to decode it into an interface,
particularly *interface{}. This CL attempts to explain things better.
Fixes#2367.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5485072
Testing total space fails for gccgo when not using split
stacks, because then each goroutine has a large stack, and so
the total memory usage is large.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5487068
I was confused by the existence of two portable Hypot
routines in the tree when I cleaned things up, and I made
ARM use the wrong (imprecise) one. Use the right one,
and delete the wrong one.
Fixes arm build.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5485065
breaks build
««« original CL description
http: close connection after printing panic stack trace
In a testing situation, it's possible for a local http
server to panic and the test exit without the stack trace
ever being printed.
Fixes#2480.
R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/5414048
»»»
R=bradfitz
CC=golang-dev
https://golang.org/cl/5482061
In a testing situation, it's possible for a local http
server to panic and the test exit without the stack trace
ever being printed.
Fixes#2480.
R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/5414048
This will be nicer to the automatic tools.
It requires a few more assembly stubs
but fewer Go files.
There are a few instances where it looks like
there are new blobs of code, but they are just
being copied out of deleted files.
There is no new code here.
Suppose you have a portable implementation for Sin
and a 386-specific assembly one. The old way to
do this was to write three files
sin_decl.go
func Sin(x float64) float64 // declaration only
sin_386.s
assembly implementation
sin_port.go
func Sin(x float64) float64 { ... } // pure-Go impl
and then link in either sin_decl.go+sin_386.s or
just sin_port.go. The Makefile actually did the magic
of linking in only the _port.go files for those without
assembly and only the _decl.go files for those with
assembly, or at least some of that magic.
The biggest problem with this, beyond being hard
to explain to the build system, is that once you do
explain it to the build system, godoc knows which
of sin_port.go or sin_decl.go are involved on a given
architecture, and it (correctly) ignores the other.
That means you have to put identical doc comments
in both files.
The new approach, which is more like what we did
in the later packages math/big and sync/atomic,
is to have
sin.go
func Sin(x float64) float64 // decl only
func sin(x float64) float64 {...} // pure-Go impl
sin_386.s
// assembly for Sin (ignores sin)
sin_amd64.s
// assembly for Sin: jmp sin
sin_arm.s
// assembly for Sin: jmp sin
Once we abandon Makefiles we can put all the assembly
stubs in one source file, so the number of files will
actually go down.
Chris asked whether the branches cost anything.
Given that they are branching to pure-Go implementations
that are not typically known for their speed, the single
direct branch is not going to be noticeable. That is,
it's on the slow path.
An alternative would have been to preserve the old
"only write assembly files when there's an implementation"
and still have just one copy of the declaration of Sin
(and thus one doc comment) by doing:
sin.go
func Sin(x float64) float64 { return sin(x) }
sin_decl.go
func sin(x float64) float64 // declaration only
sin_386.s
// assembly for sin
sin_port.go
func sin(x float64) float64 { portable code }
In this version everyone would link in sin.go and
then either sin_decl.go+sin_386.s or sin_port.go.
This has an extra function call on all paths, including
the "fast path" to get to assembly, and it triples the
number of Go files involved compared to what I did
in this CL. On the other hand you don't have to
write assembly stubs. After starting down this path
I decided that the assembly stubs were the easier
approach.
As for generating the assembly stubs on the fly, much
of the goal here is to eliminate magic from the build
process, so that zero-configuration tools like goinstall
or the new go tool can handle this package.
R=golang-dev, r, cw, iant, r
CC=golang-dev
https://golang.org/cl/5488057
This CL is concerned with the basic Package structure
and applies it to the (trivial) implementations of the
doc, fmt, fix, list, and vet commands.
The command as a whole is still very much a work in progress.
In particular, work making the error messages look nice
is deferred to a future CL.
R=golang-dev, adg, dsymonds, r
CC=golang-dev
https://golang.org/cl/5482048
