A struct or interface type node is marked incomplete if fields or
methods have been removed through any kind of filtering, not just
because entries are not exported.
The current message was misleading in some cases (for instance:
"godoc -src reflect Implements").
This CL requires CL 4527050 .
R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/4529054
Partially revert CL 4518050. In go/doc.go, instead of calling the go/ast filter
functions, implement the corresponding match functions that do no remove
declaration elements.
Fixes#1803.
R=rsc
CC=golang-dev
https://golang.org/cl/4517055
This was causing a panic in the reflect package
since type.* pointers with their low bits set are
assumed to have certain flags set that disallow
the use of reflection.
Thanks to Pavel and Taru for help tracking down
this bug.
R=rsc, paulzhol, taruti
CC=golang-dev
https://golang.org/cl/4511041
There were a couple issues:
-- HEAD requests were attempting to be ungzipped,
despite having no content. That was fixed in
the previous patch version, but ultimately was
fixed as a result of other refactoring:
-- persist.go's ClientConn "lastbody" field was
remembering the wrong body, since we were
mucking with it later. Instead, ditch
ClientConn's readRes func field and add a new
method passing it in, so we can use a closure
and do all our bodyEOFSignal + gunzip stuff
in one place, simplifying a lot of code and
not requiring messing with ClientConn's innards.
-- closing the gzip reader didn't consume its
contents. if the caller wasn't done reading
all the response body and ClientConn closed it
(thinking it'd move past those bytes in the
TCP stream), it actually wouldn't. so introduce
a new wrapper just for gzip reader to have its
Close method do an ioutil.Discard on its body
first, before the close.
Fixes#1725Fixes#1804
R=rsc, eivind
CC=golang-dev
https://golang.org/cl/4523058
RFC 6265 requires that user agents MUST NOT send more than
one Cookie header in a request.
Note, this change also fixes an issue when sending requests
with more than one cookie header line to a php script served
by an apache web server. Apache concatenates the cookies
with ", ", but php tries to split them only at ";". E.g.
two cookies: "a=b, c=d" are seen by php as one cookie "a"
with the value "b, c=d".
Fixes#1801
R=bradfitz
CC=golang-dev
https://golang.org/cl/4535048
An optimization in Transport which re-uses TCP
connections early in the case where there is
no response body interacted poorly with
ErrBodyReadAfterClose. Upon recycling the TCP
connection early we would Close the Response.Body
(in case the user forgot to), but in the case
of a zero-lengthed body, the user's handler might
not have run yet.
This CL makes sure the Transport doesn't try
to Close requests when we're about to immediately
re-use the TCP connection.
This also includes additional tests I wrote
while debugging.
R=rsc, bradfitzgoog
CC=golang-dev
https://golang.org/cl/4529050
crl parses CRLs and exposes their details. In the future, Verify
should be able to use this for revocation checking.
R=bradfitz
CC=golang-dev
https://golang.org/cl/4485045
So far, only top-level names where considered when trimming ASTs
using a filter function. For instance, "godoc reflect Implements"
didn't show the "Implements" method of the type Interface because
the local method name was not considered (on the other hand, "top-
level" declared methods associated with types were considered).
With this CL, AST filter functions look also at struct fields
and interface methods.
R=rsc, r
CC=golang-dev
https://golang.org/cl/4518050
writing the idct result directly to the image buffer instead of
storing it in an intermediate d.blocks field.
Writing to d.blocks was necessary when decoding to an image.RGBA image,
but now that we decode to a ycbcr.YCbCr we can write each component
directly to the image buffer.
Crude "time ./6.out" scores to decode a specific 2592x1944 JPEG 20
times show a 16% speed-up:
BEFORE
user 0m10.410s
user 0m10.400s
user 0m10.480s
user 0m10.480s
user 0m10.460s
AFTER
user 0m9.050s
user 0m9.050s
user 0m9.050s
user 0m9.070s
user 0m9.020s
R=r
CC=golang-dev
https://golang.org/cl/4523052
When traversing parameter lists (e.g. for type checking), we want the
invariant that all identifers have associated objects (even _ idents),
so that we can associate a type with each object.
R=rsc
CC=golang-dev
https://golang.org/cl/4490042
At least, as I understand it. The spec is unclear about what happens
with a local color map.
R=nigeltao, r2
CC=golang-dev
https://golang.org/cl/4515045
This change fixes generation of "shadow" variables for bool parameters.
Before the change, it was naming all bool variables with the same name of _p0.
Now it calls them _p0, _p1, ... So the code could compile.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4479047
It's incomplete but sufficient to decode 8-bit GIFs without interlacing
or transparency. More to come.
I'll put in more tests as the feature set grows.
R=nigeltao, r2
CC=golang-dev
https://golang.org/cl/4522041
This means that the -x flag can work, which could enable
support for other languages (e.g. objective-C).
R=iant, rsc
CC=golang-dev
https://golang.org/cl/4476049
The current iteration can decode 8-bit images in
grayscale, paletted, RGB, RGBA and NRGBA mode. LZW compression
is implemented but does not work on my test images.
Deflate (i.e. zlib) compression with or without a horizontal
predictor is supported.
R=nigeltao, nigeltao_gnome
CC=golang-dev, mpl
https://golang.org/cl/4240051
Encoder now writes tRNS chunk for non-opaque paletted images.
CL includes new test images (basn3a08-trns.[ps]ng).
R=nigeltao, rsc, r
CC=golang-dev
https://golang.org/cl/4432078
On my laptop, I had an 800x600 jpeg and an 800x600 png (with
transparency). I timed how long it took to draw each image onto an
equivalently sized, zeroed RGBA image.
Previously, the jpeg took 75ms and the png took 70ms, going through
the medium-fast path, i.e. func drawRGBA in draw.go.
After this CL, the jpeg took 14ms, and the png took 21ms with the
Over operator and 12ms with the Src operator.
It's only a rough estimate basd on one image file, but it should
give an idea of the order of magnitude of improvement.
R=rsc, r
CC=adg, golang-dev
https://golang.org/cl/4468044
- added a cache for last file looked up: avoids binary
search if the file matches
- don't look up extra line info if not present
(it is almost never present)
- inline one critical binary search call (inlining
provides almost 30% improvement in this case)
Together, these changes make the go/printer benchmark
more than twice as fast (53% improvement). gofmt also
sped up by about the same amount.
Also: removed an unused internal field from FileSet.
Measurements (always best of 5 runs):
* original:
printer.BenchmarkPrint 5 238354200 ns/op (100%)
* using last file cache:
printer.BenchmarkPrint 10 201796600 ns/op (85%)
* avoiding lookup of extra line info:
printer.BenchmarkPrint 10 157072700 ns/op (66%)
* inlining a critical binary search call:
printer.BenchmarkPrint 10 111523500 ns/op (47%)
gofmt (always best of 3 runs):
* before:
time gofmt -l src misc
real 0m33.316s
user 0m31.298s
sys 0m0.319s
* after:
time gofmt -l src misc
real 0m15.889s
user 0m14.596s
sys 0m0.224s
R=r, dfc, bradfitz, rsc1
CC=golang-dev
https://golang.org/cl/4433086
Uses of $INCLUDE and $NPROC are left over from Plan 9.
Remove them to avoid causing confusion.
R=golang-dev, r2
CC=golang-dev
https://golang.org/cl/4445079
Works around bug in kernel implementation on old ARM5 kernels.
Bug was fixed on 26 Nov 2007 (between 2.6.23 and 2.6.24) but
old kernels persist.
Fixes#1750.
R=dfc, golang-dev
CC=golang-dev
https://golang.org/cl/4436072
Avoids image.At(), color.RGBA(), opposing 8 bit shifts,
and min function calls in a loop. Not as pretty as before,
but the pure version is still there to revert back to
later if/when the compiler gets better.
before (best of 5)
jpeg.BenchmarkEncodeRGBOpaque 50 64781360 ns/op 18.97 MB/s
after (best of 5)
jpeg.BenchmarkEncodeRGBOpaque 50 42044300 ns/op 29.23 MB/s
(benchmarked on an HP z600; 16 core Xeon E5520 @ 2.27Ghz)
R=r, r2, nigeltao
CC=golang-dev
https://golang.org/cl/4433088
Previously, whether declaring a type which copied the structure of a type it was referenced in via a pointer field would work depended on whether you declared it before or after the type it copied, e.g. type T2 T1; type T1 struct { F *T2 } would work, however type T1 struct { F *T2 }; type T2 T1 wouldn't.
Fixes#667.
R=rsc
CC=golang-dev
https://golang.org/cl/4313064
The g->sched.sp saved stack pointer and the
g->stackbase and g->stackguard stack bounds
can change even while "the world is stopped",
because a goroutine has to call functions (and
therefore might split its stack) when exiting a
system call to check whether the world is stopped
(and if so, wait until the world continues).
That means the garbage collector cannot access
those values safely (without a race) for goroutines
executing system calls. Instead, save a consistent
triple in g->gcsp, g->gcstack, g->gcguard during
entersyscall and have the garbage collector refer
to those.
The old code was occasionally seeing (because of
the race) an sp and stk that did not correspond to
each other, so that stk - sp was not the number of
stack bytes following sp. In that case, if sp < stk
then the call scanblock(sp, stk - sp) scanned too
many bytes (anything between the two pointers,
which pointed into different allocation blocks).
If sp > stk then stk - sp wrapped around.
On 32-bit, stk - sp is a uintptr (uint32) converted
to int64 in the call to scanblock, so a large (~4G)
but positive number. Scanblock would try to scan
that many bytes and eventually fault accessing
unmapped memory. On 64-bit, stk - sp is a uintptr (uint64)
promoted to int64 in the call to scanblock, so a negative
number. Scanblock would not scan anything, possibly
causing in-use blocks to be freed.
In short, 32-bit platforms would have seen either
ineffective garbage collection or crashes during garbage
collection, while 64-bit platforms would have seen
either ineffective or incorrect garbage collection.
You can see the invalid arguments to scanblock in the
stack traces in issue 1620.
Fixes#1620.
Fixes#1746.
R=iant, r
CC=golang-dev
https://golang.org/cl/4437075
runtime: memory allocated by OS not in usable range
runtime: out of memory: cannot allocate 1114112-byte block (2138832896 in use)
throw: out of memory
runtime.throw+0x40 /Users/rsc/g/go/src/pkg/runtime/runtime.c:102
runtime.throw(0x1fffd, 0x101)
runtime.mallocgc+0x2af /Users/rsc/g/go/src/pkg/runtime/malloc.c:60
runtime.mallocgc(0x100004, 0x0, 0x1, 0x1, 0xc093, ...)
runtime.mal+0x40 /Users/rsc/g/go/src/pkg/runtime/malloc.c:289
runtime.mal(0x100004, 0x20bc4)
runtime.new+0x26 /Users/rsc/g/go/src/pkg/runtime/malloc.c:296
runtime.new(0x100004, 0x8fe84000, 0x20bc4)
main.main+0x29 /Users/rsc/x.go:11
main.main()
runtime.mainstart+0xf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:93
runtime.mainstart()
runtime.goexit /Users/rsc/g/go/src/pkg/runtime/proc.c:178
runtime.goexit()
----- goroutine created by -----
_rt0_386+0xbf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:80
R=iant, r
CC=golang-dev
https://golang.org/cl/4444073
