Marshalling of []byte in attributes and the general
marshalling of named []byte types was fixed.
A []byte field also won't be nil if an XML element
was mapped to it, even if the element is empty.
Tests were introduced to make sure that *struct{}
fields works correctly for element presence testing.
No changes to the logic made in that regard.
R=rsc
CC=golang-dev
https://golang.org/cl/5539070
It was 2^31, but that could cause overflow and trouble.
Reduce it to 2^30 and add a TODO.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/5562049
I haven't looked at the source, but the gc compiler appears to
omit "not used" errors when there is an error in the
initializer. This is harder to do in gccgo, and frankly I
think the "not used" error is still useful even if the
initializer has a problem. This CL tweaks some tests to avoid
the error, which is not the point of these tests in any case.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5561059
It takes too much memory to be reliable and causes
trouble on 32-bit machines.
Sigh.
Fixes#2756.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5567043
Make the panic detectable, and use that in ioutil.ReadFile to
give an error if the file is too big.
R=golang-dev, minux.ma, bradfitz
CC=golang-dev
https://golang.org/cl/5563045
This fixes the bug Rob ran into when editing package bytes.
Regexp imports regexp/syntax, which imports bytes, and
regexp/syntax was not being properly recompiled during a
test of a change to package bytes.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5555065
This should make it easier to add the zillion little changes coming.
No content change here beyond a couple of introductory sentences.
Sections have been moved wholesale without editing them.
R=golang-dev, rsc, gri
CC=golang-dev
https://golang.org/cl/5557074
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
