https://golang.org/cl/153770043/ tried to fix the case where a
implicitly tagged Time, that happened to have the same tag as
GENERALIZEDTIME, shouldn't be parsed as a GENERALIZEDTIME.

It did so, mistakenly, by testing whether params.tag != nil. But
explicitly tagged values also have a non-nil tag and there the inner
tag actually does encode the type of the value.

This change instead tests whether the tag class is UNIVERSAL before
assuming that the tag contains type information.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/152380044

TBR=0intro
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/157820043

Fixes #5834.

LGTM=alex.brainman
R=golang-codereviews, bradfitz, alex.brainman, mikioh.mikioh, in60jp, iant
CC=golang-codereviews
https://golang.org/cl/149510043

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/155190043

Missed that comment in CL 153990043.

LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/156010043

LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews, iant
https://golang.org/cl/150690043

LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/151620043

LGTM=bradfitz
R=rsc, bradfitz
CC=aram, golang-codereviews
https://golang.org/cl/154140043

That was complete failure - builders are broken,
but original cl worked fine on my system.
I will need access to builders
to test this change properly.

««« original CL description
runtime: handle all windows exception

Fixes #8006.

LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/145150043
»»»

TBR=rsc
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/154180043

Fixes #8006.

LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/145150043

CL 145890044 did not provide test. Rectify that.

Update #8517

LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/148790043

In channels, zeroing of gp.waiting is missed on a closed channel panic.
m.morebuf.g is not zeroed.

I don't expect the latter causes any problems, but just in case.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/151610043

This makes dwardump --verify happy.

Update #8846

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/150370043

TestMakeFuncVariadic only called the variadic function via Call and
CallSlice, not via a direct function call.

I thought these tests would fail under gccgo tip, but they don't.  Still seems worth having though.

LGTM=iant
R=golang-codereviews, gobot, iant
CC=golang-codereviews
https://golang.org/cl/152060043

This change prevents confusion in the garbage collector.
The collector wants to make sure that every pointer it finds
isn't junk.  Its criteria for junk is (among others) points
to a "free" span.

Because the stack shrinker modifies pointers in the heap,
there is a race condition between the GC scanner and the
shrinker.  The GC scanner can see old pointers (pointers to
freed stacks).  In particular this happens with SudoG.elem
pointers.

Normally this is not a problem, as pointers into stack spans
are ok.  But if the freed stack is the last one in its span,
the span is marked as "free" instead of "contains stacks".

This change makes sure that even if the GC scanner sees
an old pointer, the span into which it points is still
marked as "contains stacks", and thus the GC doesn't
complain about it.

This change will make the GC pause a tiny bit slower, as
the stack freeing now happens in serial with the mark pause.
We could delay the freeing until the mutators start back up,
but this is the simplest change for now.

TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/158750043

These tests fail when using gccgo.  In gccgo using Interface
on the value of a method function is implemented using a
variant of MakeFunc.  That approach did not correctly handle
variadic functions.

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/151280043

Generated by a+c.

R=gobot
CC=golang-codereviews
https://golang.org/cl/153240043

The change contains 3 spot optimizations to scan loop:
1. Don't use byte vars, use uintptr's instead.
This seems to alleviate some codegen issue,
and alone accounts to a half of speedup.
2. Remove bitmap cache. Currently we cache only 1 byte,
so caching is not particularly effective anyway.
Removal of the cache simplifies code and positively affects regalloc.
3. Replace BitsMultiword switch with if and
do debug checks only in Debug mode.
I've benchmarked changes separately and ensured that
each of them provides speedup on top of the previous one.
This change as a whole fixes the unintentional regressions
of scan loop that were introduced during development cycle.
Fixes #8625.
Fixes #8565.

On go.benchmarks/garbage benchmark:
GOMAXPROCS=1
time:		-3.13%
cputime:	-3.22%
gc-pause-one:	-15.71%
gc-pause-total:	-15.71%

GOMAXPROCS=32
time:		-1.96%
cputime:	-4.43%
gc-pause-one:	-6.22%
gc-pause-total:	-6.22%

LGTM=khr, rsc
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/153990043

Should fix the remaining 'invalid heap pointer' build failures.

TBR=khr
CC=golang-codereviews
https://golang.org/cl/152360043

Out of stack space due to new 2-word call in freedefer.
Go back to smaller function calls.

TBR=brainman
CC=golang-codereviews
https://golang.org/cl/152340043

It appears to be an opaque bit pattern more than a pointer.
The Go garbage collector has discovered that for m0
it is set to 0x4c.

Should fix Windows build.

TBR=brainman
CC=golang-codereviews
https://golang.org/cl/149640043

Another dangling stack pointer in a cached structure.
Same as SudoG.elem and SudoG.selectdone.

Definitely a fix, and the new test in freedefer makes the
crash reproducible, but probably not a complete fix.
I have seen one dangling pointer in a Defer.panic even
after this fix; I cannot see where it could be coming from.

I think this will fix the solaris build.
I do not think this will fix the occasional failure on the darwin build.

TBR=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/155080043

This avoids a pop-up box on OS X and it avoids
a test failure if something is using 5555.
I apologize for not noticing this during the review.

TBR=r
CC=golang-codereviews
https://golang.org/cl/152320044

LGTM=bradfitz, r
R=r, bradfitz
CC=golang-codereviews
https://golang.org/cl/156730043

It seems reasonable that people might want to look up the
ImportComment with "go list".

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/143600043

I have a CL which at every gc looks through data and bss
sections for nonpointer data (according to gc maps) that
looks like a pointer.  These are potential missing roots.

The only thing it finds are begnign, storing stack pointers
into m0.scalararg[1] and never cleaning them up.  Let's
clean them up now so the test CL passes all.bash cleanly.

The test CL can't be checked in because we might store
pointer-looking things in nonpointer data by accident.

LGTM=iant
R=golang-codereviews, iant, khr
CC=golang-codereviews
https://golang.org/cl/153210043

We no longer have full type information in the heap, so
we can't dump that any more.  Instead we dump ptr/noptr
maps so at least we can compute graph connectivity.

In addition, we still dump Iface/Eface types so together
with dwarf type info we might be able to reconstruct
types of most things in the heap.

LGTM=dvyukov
R=golang-codereviews, dvyukov, rsc, khr
CC=golang-codereviews
https://golang.org/cl/155940043

Fixes a SWIG bug reported off-list.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/155990043

Fixes #8904.

TBR=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/148650043

Helpfully supplied by tommi.virtanen in issue 8173.

LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/151370043

LGTM=bradfitz, dave, r
R=r, bradfitz, dave
CC=golang-codereviews
https://golang.org/cl/152250044

Fixes 386 build.

TBR=r
CC=golang-codereviews
https://golang.org/cl/149620043

This will help find bugs during the release freeze.
It's not clear it should be kept for the release itself.
That's issue 8861.

The most likely thing that would trigger this is stale
pointers that previously were ignored or caused memory
leaks. These were allowed due to the use of conservative
collection. Now that everything is precise, we should not
see them anymore.

The small number check reinforces what the stack copier
is already doing, catching the storage of integers in pointers.
It caught issue 8864.

The check is disabled if _cgo_allocate is linked into the binary,
which is to say if the binary is using SWIG to allocate untyped
Go memory. In that case, there are invalid pointers and there's
nothing we can do about it.

LGTM=rlh
R=golang-codereviews, dvyukov, rlh
CC=golang-codereviews, iant, khr, r
https://golang.org/cl/148470043

Fixes #8587.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews, iant, r
https://golang.org/cl/152270044

Depending on flags&KindGCProg,
gc[0] and gc[1] are either pointers or inlined bitmap bits.
That's not compatible with a precise garbage collector:
it needs to be always pointers or never pointers.

Change the inlined bitmap case to store a pointer to an
out-of-line bitmap in gc[0]. The out-of-line bitmaps are
dedup'ed, so that for example all pointer types share the
same out-of-line bitmap.

Fixes #8864.

LGTM=r
R=golang-codereviews, dvyukov, r
CC=golang-codereviews, iant, khr, rlh
https://golang.org/cl/155820043

http.Client calls URL.String() to fill in the Referer header, which may
contain authentication info. This patch removes authentication info from
the Referer header without introducing any API changes.

A new test for net/http is also provided.

This is the polished version of Alberto García Hierro's
https://golang.org/cl/9766046/

It should handle https Referer right.

Fixes #8417

LGTM=bradfitz
R=golang-codereviews, gobot, bradfitz, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/151430043

Debugging the builders and need a commit to make them run.

R=adg
CC=golang-codereviews
https://golang.org/cl/149600043

http://build.golang.org/log/c7a91b6eac8f8daa2bd17801be273e58403a15f2

# cmd/pprof
/linux-386-clang-9115aad1dc4a/go/pkg/linux_386/net.a(_all.o): sym#16: ignoring .Linfo_string0 in section 16 (type 0)
/linux-386-clang-9115aad1dc4a/go/pkg/linux_386/net.a(_all.o): sym#17: ignoring .Linfo_string1 in section 16 (type 0)
/linux-386-clang-9115aad1dc4a/go/pkg/linux_386/net.a(_all.o): sym#18: ignoring .Linfo_string2 in section 16 (type 0)
/linux-386-clang-9115aad1dc4a/go/pkg/linux_386/net.a(_all.o): sym#20: ignoring .Linfo_string0 in section 16 (type 0)
/linux-386-clang-9115aad1dc4a/go/pkg/linux_386/net.a(_all.o): sym#21: ignoring .Linfo_string1 in section 16 (type 0)
...

I don't know what these are. Let's ignore them and see if we get any further.

TBR=iant
CC=golang-codereviews
https://golang.org/cl/155030043

Fixes #8090.

LGTM=alex.brainman
R=alex.brainman
CC=golang-codereviews
https://golang.org/cl/154020043

Noticed while reviewing https://golang.org/cl/147690043/

I'd never seen anybody use IndexRune before, and
unsurprisingly it doesn't use the other fast paths in the
strings/bytes packages. IndexByte uses assembly.

Also, less code this way.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/147700043