delta/go-git.git/src/text, branch dev.inline

text/template: handle option missingkey=error consistently

2016-11-18T15:56:02+00:00

The existing implementation of text/template handles the option
"missingkey=error" in an inconsitent manner:  If the provided data is
a nil-interface, no error is returned (despite the fact that no key
can be found in it).

This patch makes text/template return an error if "missingkey=error"
is set and the provided data is a not a valid reflect.Value.

Fixes #15356

Change-Id: Ia0a83da48652ecfaf31f18bdbd78cb21dbca1164
Reviewed-on: https://go-review.googlesource.com/31638
Reviewed-by: Rob Pike 
Run-TryBot: Rob Pike 
TryBot-Result: Gobot Gobot

text/template: efficient reporting of line numbers

2016-11-15T00:42:33+00:00

Instead of scanning the text to count newlines, which is n², keep track as we go
and store the line number in the token.

benchmark                 old ns/op      new ns/op     delta
BenchmarkParseLarge-4     1589721293     38783310      -97.56%

Fixes #17851

Change-Id: I231225c61e667535e2ce55cd2facea6d279cc59d
Reviewed-on: https://go-review.googlesource.com/33234
Run-TryBot: Rob Pike 
TryBot-Result: Gobot Gobot 
Reviewed-by: Brad Fitzpatrick

Revert "text/template: efficient reporting of line numbers"

2016-11-14T22:23:24+00:00

This reverts commit 794fb71d9c1018c4beae1657baca5229e6a02ad0.

Reason for revert: submitted without TryBots and it broke all three race builders.

Change-Id: I80a1e566616f0ee8fa3529d4eeee04268f8a713b
Reviewed-on: https://go-review.googlesource.com/33232
Reviewed-by: Brad Fitzpatrick

text/template: efficient reporting of line numbers

2016-11-14T18:42:48+00:00

Instead of scanning the text to count newlines, which is n², keep track as we go
and store the line number in the token.

benchmark                 old ns/op      new ns/op     delta
BenchmarkParseLarge-4     1589721293     38783310      -97.56%

Fixes #17851

Change-Id: Ieaf89a35e371b405ad92e38baa1e3fa98d18cfb4
Reviewed-on: https://go-review.googlesource.com/32923
Reviewed-by: Robert Griesemer

text/template: reintroduce implicit indirect of interface values in builtin funcs

2016-11-11T19:46:17+00:00

CL 31462 made it possible to operate directly on reflect.Values
instead of always forcing a round trip to interface{} and back.
The round trip was losing addressability, which hurt users.

The round trip was also losing "interface-ness", which helped users.
That is, using reflect.ValueOf(v.Interface()) instead of v was doing
an implicit indirect any time v was itself an interface{} value: the result
was the reflect.Value for the underlying concrete value contained in the
interface, not the interface itself.

CL 31462 eliminated some "unnecessary" reflect.Value round trips
in order to preserve addressability, but in doing so it lost this implicit
indirection. This CL adds the indirection back.

It may help to compare the changes in this CL against funcs.go from CL 31462:
https://go-review.googlesource.com/#/c/31462/4/src/text/template/funcs.go

Everywhere CL 31462 changed 'v := reflect.ValueOf(x)' to 'v := x',
this CL changes 'v := x' to 'v := indirectInterface(x)'.

Fixes #17714.

Change-Id: I67cec4eb41fed1d56e1c19f12b0abbd0e59d35a2
Reviewed-on: https://go-review.googlesource.com/33139
Run-TryBot: Russ Cox 
Reviewed-by: Rob Pike

html/template, text/template: drop defined template list from errors

2016-10-28T17:10:55+00:00

The report in #17414 points out that if you have many many templates,
then this is an overwhelming list and just hurts the signal-to-noise ratio of the error.

Even the test of the old behavior also supports the idea that this is noise:

	template: empty: "empty" is an incomplete or empty template; defined templates are: "secondary"

The chance that someone mistyped "secondary" as "empty" is slim at best.

Similarly, the compiler does not augment an error like 'unknown variable x'
by dumping the full list of all the known variables.

For all these reasons, drop the list.

Fixes #17414.

Change-Id: I78f92d2c591df7218385fe723a4abc497913acf8
Reviewed-on: https://go-review.googlesource.com/32116
Run-TryBot: Russ Cox 
TryBot-Result: Gobot Gobot 
Reviewed-by: Rob Pike

all: freeze net/rpc and reword the 'frozen' message in other frozen packages

2016-10-26T16:11:07+00:00

Make the messages grammatically korrect and consistent.

Fixes #16844

Change-Id: I7c137b4dc25c0c875ed07b0c64c67ae984c39cbc
Reviewed-on: https://go-review.googlesource.com/32112
Reviewed-by: Brad Fitzpatrick

testing/quick, text/tabwriter: freeze packages

2016-10-24T23:31:50+00:00

Fixes #15557

Change-Id: I02ad98068894e75d4e08e271fdd16cb420519460
Reviewed-on: https://go-review.googlesource.com/31910
Reviewed-by: Andrew Gerrand

all: minor vet fixes

2016-10-24T17:27:37+00:00

Change-Id: I22f0f3e792052762499f632571155768b4052bc9
Reviewed-on: https://go-review.googlesource.com/31759
Run-TryBot: Josh Bleecher Snyder 
TryBot-Result: Gobot Gobot 
Reviewed-by: Brad Fitzpatrick

html/template, text/template: docs and fixes for template redefinition

2016-10-24T15:43:24+00:00

All prior versions of Go have allowed redefining empty templates
to become non-empty. Unfortunately, that has never consistently
taken effect in html/template after the first execution:

	// define and execute
	t := template.New("root")
	t.Parse(`{{define "T"}}{{end}}`)
	t.Execute(w, nil) // 

	// redefine
	t.Parse(`{{define "T"}}my.url{{end}}`) // succeeds, but ignored
	t.Execute(w, nil) // 

When Go 1.6 added {{block...}} to text/template, that loosened the
redefinition rules to allow redefinition at any time. The loosening was
undone a bit in html/template, although inconsistently:

	// define and execute
	t := template.New("root")
	t.Parse(`{{define "T"}}body{{end}}`)
	t.Lookup("T").Execute(ioutil.Discard, nil)

	// attempt to redefine
	t.Parse(`{{define "T"}}body{{end}}`) // rejected in all Go versions
	t.Lookup("T").Parse("body") // OK as of Go 1.6, likely unintentionally

Like in the empty->non-empty case, whether future execution takes
notice of a redefinition basically can't be explained without going into
the details of the template escape analysis.

Address both the original inconsistencies in whether a redefinition
would have any effect and the new inconsistencies about whether a
redefinition is allowed by adopting a new rule: no parsing or modifying
any templates after the first execution of any template in the same set.
Template analysis begins at first execution, and once template analysis
has begun, we simply don't have the right logic to update the analysis
for incremental modifications (and never have).

If this new rule breaks existing uses of templates that we decide need
to be supported, we can try to invalidate all escape analysis for the
entire set after any modifications. But let's wait on that until we know
we need to and why.

Also fix documentation of text/template redefinition policy
(redefinition is always OK).

Fixes #15761.

Change-Id: I7d58d7c08a7d9df2440ee0d651a5b2ecaff3006c
Reviewed-on: https://go-review.googlesource.com/31464
Run-TryBot: Russ Cox 
TryBot-Result: Gobot Gobot 
Reviewed-by: Andrew Gerrand