- 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

No language change.

- added a few examples with parentheses
- added a corresponding sentence to assignments
  (this explicitly permits: (_) = 0, currently allowed by 6g,
  gofmt, but marked as an error by gccgo).

R=rsc, r, iant
CC=golang-dev
https://golang.org/cl/4446071

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

R=rsc, adg
CC=golang-dev
https://golang.org/cl/4426074

Fixes #1694.

R=golang-dev, rsc1, rsc
CC=golang-dev
https://golang.org/cl/4445067

Fixes #1767.

R=rsc
CC=golang-dev
https://golang.org/cl/4436073

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

With Linux/8g on a 2006 Mac Mini (1.66 GHz Intel Core Duo,
2KB L1, 2MB L2, 2G main memory), GOMAXPROCS unset:

start:
png.BenchmarkEncodePaletted	      50	  44772820 ns/op
png.BenchmarkEncodeRGBOpaque	      10	 208395900 ns/op
png.BenchmarkEncodeRGBA		       5	 331088000 ns/op

remove interface method calls:
png.BenchmarkEncodePaletted	      50	  44722880 ns/op
png.BenchmarkEncodeRGBOpaque	      10	 139042600 ns/op
png.BenchmarkEncodeRGBA		       5	 334033600 ns/op

flate inline min/max():
png.BenchmarkEncodePaletted	      50	  40631180 ns/op
png.BenchmarkEncodeRGBOpaque	      10	 124894900 ns/op
png.BenchmarkEncodeRGBA		       5	 312099000 ns/op

after adler change:
png.BenchmarkEncodePaletted	      50	  40181760 ns/op
png.BenchmarkEncodeRGBOpaque	      20	 121781950 ns/op
png.BenchmarkEncodeRGBA		       5	 313890800 ns/op

In comparison to 121 ms on this 2006 machine, on my
Core2 Duo 2.66 GHz laptop, the final BenchmarkEncodeRGBOpaque
runs in 27 ms. (these are all for 640x480 images)

R=nigeltao, rsc, r
CC=golang-dev
https://golang.org/cl/4432077

R=rsc, adg
CC=golang-dev
https://golang.org/cl/4430074

R=brainman, rsc1, rsc
CC=golang-dev
https://golang.org/cl/4375046

R=bradfitz, dsymonds
CC=golang-dev
https://golang.org/cl/4432085

The previous change to make multipart use ReadSlice out of
paranoia broke multipart to not deal with large lines in
the bodies.

We should only be paranoid about long lines in the header
sections.

Fixes http://code.google.com/p/camlistore/issues/detail?id=4

R=adg
CC=golang-dev
https://golang.org/cl/4432083

R=adg
CC=golang-dev
https://golang.org/cl/4433094

R=rsc
CC=golang-dev
https://golang.org/cl/4439082

The CL introduces inconsistencies with respect to
the use of parentheses/grouping of receive operations.

««« original CL description
spec: narrow syntax for expression and select statements

This is not a language change, it simply expresses the
accepted cases explicitly in the respective productions.

R=rsc, r, iant
CC=golang-dev
https://golang.org/cl/4428057
»»»

R=golang-dev, rsc1
CC=golang-dev
https://golang.org/cl/4444080

No code changes in this CL.

R=r
CC=golang-dev
https://golang.org/cl/4445074

Used by gccgo.

R=bradfitz
CC=golang-dev
https://golang.org/cl/4435080

This is not a language change, it simply expresses the
accepted cases explicitly in the respective productions.

R=rsc, r, iant
CC=golang-dev
https://golang.org/cl/4428057

R=bradfitz
CC=golang-dev
https://golang.org/cl/4433087

R=r, dfc, bradfitzwork, bradfitz
CC=golang-dev
https://golang.org/cl/4441078

R=agl, eds, rsc1, rsc
CC=golang-dev
https://golang.org/cl/4432079

R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/4452056

R=bradfitz, agl1, rsc
CC=golang-dev
https://golang.org/cl/4435055

Fixes #1749.

R=bradfitz
CC=golang-dev
https://golang.org/cl/4431075

R=rsc, r2
CC=golang-dev
https://golang.org/cl/4442100

Also remove some left over copy & paste
in the test of reflect.Copy for arrays.

R=golang-dev, rsc1
CC=golang-dev
https://golang.org/cl/4431074

Fixes #1722.

R=ken2
CC=golang-dev
https://golang.org/cl/4442099

R=golang-dev, bradfitz, dsymonds
CC=golang-dev
https://golang.org/cl/4426069

R=golang-dev
CC=golang-dev
https://golang.org/cl/4439081

R=rsc
CC=golang-dev
https://golang.org/cl/4437077

R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/4431068

before & after:
adler32.BenchmarkGolden	  100000	     14747 ns/op
adler32.BenchmarkGolden	  200000	      8761 ns/op

Found by profiling PNG encoding.

R=rsc, bradfitzwork, eds
CC=golang-dev
https://golang.org/cl/4441073

This time for sure.

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/4437078

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

Fixes #1397.

R=iant
CC=golang-dev
https://golang.org/cl/4444064

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

R=brad_danga_com, rsc, dfc, r, dchest, bradfitz
CC=golang-dev
https://golang.org/cl/4439075

This one didn't come up in previous greps.

R=adg
CC=golang-dev
https://golang.org/cl/4430071