Credit to jp for proof of concept.

R=alex.brainman, jp, rsc, dvyukov
CC=golang-dev
https://golang.org/cl/4960057

filepath.Glob is documented to return nil if no files match
and an error only if the pattern is invalid.  This change
fixes it to work as documented and adds a regression test.

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

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

bug330.go:11:6: error: expected numeric type
bug330.go:12:6: error: expected numeric type

R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5031050

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

clean up duplicate environment for CGI.
overriding former by latter.
On windows, When there are duplicated environments like following,

SCRIPT_FILENAME=c:/progra~1/php/php-cgi.exe
SCRIPT_FILENAME=/foo.php

CreateProcess use first entry.

If make cgi.Handle like following,

        cgih = cgi.Handler{
                Path: "c:/strawberry/perl/bin/perl.exe",
                Dir:  "c:/path/to/webroot",
                Root: "c:/path/to/webroot",
                Args: []string{"foo.php"},
                Env:  []string{"SCRIPT_FILENAME=foo.php"},
        }

http/cgi should behave "SCRIPT_FILENAME is foo.php".
But currently, http/cgi is set duplicate environment entries.
So, browser show binary dump of "php-cgi.exe" that is specified indented
SCRIPT_FILENAME in first entry.
This change clean up duplicates, and use latters.

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

is going to support returning multiple matches for a single repeated group.

R=r, rsc, mpvl
CC=golang-dev
https://golang.org/cl/5014045

Trie now uses sparse block when this makes sense.

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

I found a simple test case that does require doing the fixed point TODO
in computeOutCtx.

I found a way though to do this and simplify away the escapeRange
hackiness that was added in https://golang.org/cl/5012044/

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

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

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

R=golang-dev, bsiegert, rsc, hectorchu
CC=golang-dev
https://golang.org/cl/5016043

This replaces the errStr & errLine members of context with a single err
*Error, and introduces a number of const error codes, one per
escape-time failure mode, that can be separately documented.

The changes to the error documentation moved from doc.go to error.go
are cosmetic.

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

On app-engine, we cannot import syscall.
The respective constants are already defined
elsewhere for the same reason.

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

When saving/restoring the fulltext index, the entire
respective suffixarray is now saved/restored (as opposed
to the indexed data only, and the suffixarray recreated).
This saves significant start-up time for large indexes,
at the cost of significantly larger index files.

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

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

Fixes #2218

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

Comments from rsc after 4921049 was submitted.

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

Fixes #2208

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

This makes it possible to use a FlagSet as a
field in a larger struct.

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

Fixes #1156.
Fixes #2172.

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

The go/build package already recognizes
system-specific file names like

        mycode_darwin.go
        mycode_darwin_386.go
        mycode_386.s

However, it is also common to write files that
apply to multiple architectures, so a recent CL added
to go/build the ability to process comments
listing a set of conditions for building.  For example:

        // +build darwin freebsd openbsd/386

says that this file should be compiled only on
OS X, FreeBSD, or 32-bit x86 OpenBSD systems.

These conventions are not yet documented
(hence this long CL description).

This CL adds build comments to the multi-system
files in the core library, a step toward making it
possible to use go/build to build them.

With this change go/build can handle crypto/rand,
exec, net, path/filepath, os/user, and time.

os and syscall need additional adjustments.

R=golang-dev, r, gri, r, gustavo
CC=golang-dev
https://golang.org/cl/5011046

New rules as discussed on CL 5011046.
Also apply to C and assembly files, not just Go files.

R=r, rogpeppe
CC=golang-dev
https://golang.org/cl/5015051

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

Fixes #2258

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

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

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

Not all content is plain text.  Sometimes content comes from a trusted
source, such as another template invocation, an HTML tag whitelister,
etc.

Template authors can deal with over-escaping in two ways.

1) They can encapsulate known-safe content via
   type HTML, type CSS, type URL, and friends in content.go.
2) If they know that the for a particular action never needs escaping
   then they can add |noescape to the pipeline.
   {{.KnownSafeContent | noescape}}
   which will prevent any escaping directives from being added.

This CL defines string type aliases: HTML, CSS, JS, URI, ...
It then modifies stringify to unpack the content type.
Finally it modifies the escaping functions to use the content type and
decline to escape content that does not require it.

There are minor changes to escapeAction and helpers to treat as
equivalent explicit escaping directives such as "html" and "urlquery"
and the escaping directives defined in the contextual autoescape module
and to recognize the special "noescape" directive.

The html escaping functions are rearranged.  Instead of having one
escaping function used in each {{.}} in

    {{.}} : <textarea title="{{.}}">{{.}}</textarea>

a slightly different escaping function is used for each.
When {{.}} binds to a pre-sanitized string of HTML

    `one < <i>two</i> &amp; two < "3"`

we produces something like

     one < <i>two</i> &amp; two < "3" :
     <textarea title="one &lt; two &amp; two &lt; &#34;3&#34;">
       one &lt; &lt;i&gt;two&lt;/i&gt; &amp; two &lt; "3"
     </textarea>

Although escaping is not required in <textarea> normally, if the
substring </textarea> is injected, then it breaks, so we normalize
special characters in RCDATA and do the same to preserve attribute
boundaries.  We also strip tags since developers never intend
typed HTML injected in an attribute to contain tags escaped, but
do occasionally confuse pre-escaped HTML with HTML from a
tag-whitelister.

R=golang-dev, nigeltao
CC=golang-dev
https://golang.org/cl/4962067

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

- now fulltext index information is saved/restored
- minor updates to appinit.go

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

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

This moots a caveat in the proposed package documentation by
rendering useless any template that could not be escaped.

From https://golang.org/cl/4969078/
> If EscapeSet returns an error, do not Execute the set; it is not
> safe against injection.
r: [but isn't the returned set nil? i guess you don't overwrite the
r: original if there's a problem, but i think you're in your rights to
r: do so]

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

The Windows implementation of the net package churns through a couple of channels for every read/write operation.  This translates into a lot of time spent in the kernel creating and deleting event objects.

R=rsc, dvyukov, alex.brainman, jp
CC=golang-dev
https://golang.org/cl/4997044

Lets test pass when using gccgo.

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

R=adg, r, edsrzf, rsc, r
CC=golang-dev
https://golang.org/cl/4962052

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

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

It would be nice not to have to support this since all the clients
that we care about support TLSv1 by now. However, due to buggy
implementations of SSLv3 on the Internet which can't do version
negotiation correctly, browsers will sometimes switch to SSLv3. Since
there's no good way for a browser tell a network problem from a buggy
server, this downgrade can occur even if the server in question is
actually working correctly.

So we need to support SSLv3 for robustness :(

Fixes #1703.

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

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

R=golang-dev, cw
CC=golang-dev
https://golang.org/cl/5004045