Preserve test.
changeset: 11593:f1deaf35e1d1
user: Luuk van Dijk <lvd@golang.org>
date: Tue Jan 17 10:00:57 2012 +0100
summary: gc: fix infinite recursion for embedded interfaces
This is causing 'interface type loop' errors during compilation
of a complex program. I don't understand what's happening
well enough to boil it down to a simple test case, but undoing
this change fixes the problem.
The change being undone is fixing a corner case (uses of
pointer to interface in an interface definition) that basically
only comes up in erroneous Go programs. Let's not try to
fix this again until after Go 1.
Unfixes issue 1909.
TBR=lvd
CC=golang-dev
https://golang.org/cl/5555063
We already use GOHOSTOS to represent the host OS that the toolchain
will be run on, so no need to resort to uname(1) to get that (and
use uname(1) will make cross-compiling for another host impossible).
R=rsc, golang-dev
CC=golang-dev
https://golang.org/cl/5530050
- use proper Win64 gcc calling convention when
calling initcgo on amd64
- increase g0 stack size to 64K on amd64 to make
it the same as 386
- implement C.sleep
- do not use C.stat, since it is renamed to C._stat by mingw
- use fopen to implement TestErrno, since C.strtol
always succeeds on windows
- skip TestSetEnv on windows, because os.Setenv
sets windows process environment, while C.getenv
inspects internal C runtime variable instead
R=golang-dev, vcc.163, rsc
CC=golang-dev
https://golang.org/cl/5500094
instead of the origin.
This makes YCbCr match the other image types (e.g. RGBA, Gray) in
that an image's bounds is not restricted to the positive quadrant.
Also optimize the YCbCr draw code by hoisting some computation
outside of the loop.
benchmark old ns/op new ns/op delta
draw.BenchmarkYCbCr 2544418 2373558 -6.72%
Like https://golang.org/cl/4681044/ I don't think a gofix is
feasible. People will have to make manual changes. On the other hand,
directly manipulating YCbCr images is relatively rare, compared to
RGBA images, and if other code just uses the jpeg and draw packages
instead of messing directly with a YCbCr's []byte representations,
then things should just continue to work.
R=r
CC=golang-dev
https://golang.org/cl/5558048
Remove NewMD5, NewSHA1 and NewSHA256 in favor of using New and
explicitly importing the used hash-function. This way when using, for
example, HMAC with RIPEMD there's no md5, sha1 and sha256 linked in
through the hmac package.
A gofix rule is included, and applied to the standard library (3 files
altered).
This change is the result of a discussion at
https://golang.org/cl/5550043/ to pull the discussion about
deprecating these functions out of that issue.
R=golang-dev, agl
CC=golang-dev, r, rsc
https://golang.org/cl/5556058
Fix originally from rogpeppe in 5414048 but was rolled
back due to test breakage.
This CL makes the test more robust to order of operations.
Fixes#2480 again.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5536072
The previous version of all the node.String methods printed the parse
tree and was useful for developing the parse tree code. Now that that's done,
we might as well print the nodes using the standard template syntax.
It's much easier to read and makes error reporting look more natural.
Helps issue 2644.
R=rsc, n13m3y3r
CC=golang-dev
https://golang.org/cl/5553066
So as to give out stack trace for panic in examples.
This behavior also matches the tests'.
Fixes#2691.
R=golang-dev
CC=golang-dev
https://golang.org/cl/5554061
(Sending to r because of the API change.)
Over time we might want to add support for other key types.
While I was in the code, I also made the use of RawSubject the same
between Subject and Issuer when creating certificates.
R=r, rsc
CC=golang-dev
https://golang.org/cl/5554049
(Sending to r because of the API change.)
This change alters the API for crypto/elliptic to permit different
implementations in the future. This will allow us to add faster,
constant-time implementations of the standard curves without any more
API changes.
As a demonstration, it also adds a constant-time implementation of
P224. Since it's only 32-bit, it's actually only about 40% the speed
of the generic code on a 64-bit system.
R=r, rsc
CC=golang-dev
https://golang.org/cl/5528088
TestNonStandardNormalValues runs 1.5s,
the change reduces it to 0.2s in short mode.
The problem is with slow machines, emulators and dynamic tools.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5540065
Also, disable server-side generation of TOC for commands as they would
only ever show Overview. The JS does a better job (for now).
Fixes#2732.
R=gri, dsymonds
CC=golang-dev
https://golang.org/cl/5558046
