delta/go-git.git/src/text, branch dev.boringcrypto.go1.12

[release-branch.go1.12] text/template: error on method calls on nil interfaces

2019-03-13T21:00:26+00:00

Trying to call a method on a nil interface is a panic in Go. For
example:

	var stringer fmt.Stringer
	println(stringer.String()) // nil pointer dereference

In https://golang.org/cl/143097 we started recovering panics encountered
during function and method calls. However, we didn't handle this case,
as text/template panics before evalCall is ever run.

In particular, reflect's MethodByName will panic if the receiver is of
interface kind and nil:

	panic: reflect: Method on nil interface value

Simply add a check for that edge case, and have Template.Execute return
a helpful error. Note that Execute shouldn't just error if the interface
contains a typed nil, since we're able to find a method to call in that
case.

Finally, add regression tests for both the nil and typed nil interface
cases.

Fixes #30464.

Change-Id: Iffb21b40e14ba5fea0fcdd179cd80d1f23cabbab
Reviewed-on: https://go-review.googlesource.com/c/161761
Run-TryBot: Daniel Martí 
TryBot-Result: Gobot Gobot 
Reviewed-by: Emmanuel Odeke 
(cherry picked from commit 15b4c71a912846530315c3e854feaaa9d0d54220)
Reviewed-on: https://go-review.googlesource.com/c/go/+/164457
Reviewed-by: Brad Fitzpatrick

text/template/parse: simplify Tree.pipeline

2018-10-29T12:20:11+00:00

The pipeline parsing code was unnecessarily complex. It used a for loop
with a trailing break, a complex switch, and up to seven levels of
indentation.

Instead, drop the loop in favor of a single named goto with a comment,
and flatten out the complex switch to be easier to follow. Two lines of
code are now duplicated, but they're simple and only three lines apart.

While at it, move the pipe initialization further up to remove the need
for three variables.

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

text/template/parse: error on bad range variables

2018-10-28T20:20:00+00:00

The package used to accept invalid range pipelines, such as:

	{{range $k, .}}
	{{range $k, 123 := .}}

This is because the logic that allowed a range pipeline to declare
multiple variables was broken. When encountering a single comma inside a
range pipeline, it would happily continue parsing a second variable,
even if we didn't have a variable token at all.

Then, the loop would immediately break, and we'd parse the pipeline we'd
be ranging over. That is, we'd parse {{range $k, .}} as if it were
{{range $k = .}}.

To fix this, only allow the loop to continue if we know we're going to
parse another variable or a token that would end the pipeline. Also add
a few test cases for these error edge cases.

While at it, make use of T.Run, which was useful in debugging
Tree.pipeline via print statements.

Fixes #28437.

Change-Id: Idc9966bf643f0f3bc1b052620357e5b0aa2022ea
Reviewed-on: https://go-review.googlesource.com/c/145282
Run-TryBot: Daniel Martí 
TryBot-Result: Gobot Gobot 
Reviewed-by: Bjørn Erik Pedersen 
Reviewed-by: Rob Pike

text/template: recover panics during function calls

2018-10-24T09:09:21+00:00

There's precedent in handling panics that happen in functions called
from the standard library. For example, if a fmt.Formatter
implementation fails, fmt will absorb the panic into the output text.

Recovering panics is useful, because otherwise one would have to wrap
some Template.Execute calls with a recover. For example, if there's a
chance that the callbacks may panic, or if part of the input data is nil
when it shouldn't be.

In particular, it's a common confusion amongst new Go developers that
one can call a method on a nil receiver. Expecting text/template to
error on such a call, they encounter a long and confusing panic if the
method expects the receiver to be non-nil.

To achieve this, introduce safeCall, which takes care of handling error
returns as well as recovering panics. Handling panics in the "call"
function isn't strictly necessary, as that func itself is run via
evalCall. However, this makes the code more consistent, and can allow
for better context in panics via the "call" function.

Finally, add some test cases with a mix of funcs, methods, and func
fields that panic.

Fixes #28242.

Change-Id: Id67be22cc9ebaedeb4b17fa84e677b4b6e09ec67
Reviewed-on: https://go-review.googlesource.com/c/143097
Run-TryBot: Daniel Martí 
TryBot-Result: Gobot Gobot 
Reviewed-by: Rob Pike

text/template: removed truncation of context in error message

2018-10-23T00:28:36+00:00

Fixes #27930

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

text/template: drop unused sortKeys function

2018-10-19T05:17:57+00:00

Recent change golang.org/cl/142737 drops the only call site for the
sortKeys function. If it's not in use, it should probably not be there in
the code, lurking and preparing to bite us when someone calls that instead
of the new key sorter in fmtsort, resulting in strange inconsistencies.

Since the function isn't called, this should have no impact.
Related to, but does not fix, #21095.

Change-Id: I4695503ef4d5ce90d989ec952f01ea00cc15c79d
Reviewed-on: https://go-review.googlesource.com/c/143178
Reviewed-by: Brad Fitzpatrick 
Run-TryBot: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot

fmt: print maps in key-sorted order

2018-10-18T21:12:24+00:00

For easier testing, change the way maps are printed so they
appear in a consistent order between runs. Do this by printing
them in key-sorted order.

To do this, we add a package at the root, internal/fmtsort,
that implements a general mechanism for sorting map keys
regardless of their type. This is a little messy and probably
slow, but formatted printing of maps has never been fast and
is already always reflection-driven.

The rules are:

The ordering rules are more general than with Go's < operator:

 - when applicable, nil compares low
 - ints, floats, and strings order by <
 - NaN compares less than non-NaN floats
 - bool compares false before true
 - complex compares real, then imag
 - pointers compare by machine address
 - channel values compare by machine address
 - structs compare each field in turn
 - arrays compare each element in turn.
 - interface values compare first by reflect.Type describing the concrete type
   and then by concrete value as described in the previous rules.

The new package is internal because we really do not want
everyone using this to sort things. It is slow, not general, and
only suitable for the subset of types that can be map keys.

Also use the package in text/template, which already had a
weaker version of this mechanism.

This change requires adding a dependency on sort to the fmt
package, but that isn't disruptive to the dependency tree.

Fixes #21095

Change-Id: Ia602115c7de5d95993dbd609611d8bd96e054157
Reviewed-on: https://go-review.googlesource.com/c/142737
Reviewed-by: Brad Fitzpatrick 
Reviewed-by: Russ Cox

text/template: explain that integer constants can overflow

2018-10-11T02:32:47+00:00

This behavior is the same as in Go: constants can be coerced to int
and whether overflow occurs depends on how big an int is, but
this surprises people sometimes, so document it again here.

Fixes #25833.

Change-Id: I557995f1a1e8e871b21004953923d16f36cb9037
Reviewed-on: https://go-review.googlesource.com/c/141378
Reviewed-by: Brad Fitzpatrick

all: use strings.ReplaceAll and bytes.ReplaceAll where applicable

2018-09-26T22:14:25+00:00

I omitted vendor directories and anything necessary for bootstrapping.
(Tested by bootstrapping with Go 1.4)

Updates #27864

Change-Id: I7d9b68d0372d3a34dee22966cca323513ece7e8a
Reviewed-on: https://go-review.googlesource.com/137856
Run-TryBot: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor

text/template: simplify line tracking in the lexer

2018-09-05T21:27:04+00:00

First, move the strings.Count logic out of emit, since only itemText
requires that. Use it in those call sites. itemLeftDelim and
itemRightDelim cannot contain newlines, as they're the "{{" and "}}"
tokens.

Secondly, introduce a startLine lexer field so that we don't have to
keep track of it elsewhere. That's also a requirement to move the
strings.Count out of emit, as emit modifies the start position field.

Change-Id: I69175f403487607a8e5b561b3f1916ee9dc3c0c6
Reviewed-on: https://go-review.googlesource.com/132275
Run-TryBot: Daniel Martí 
TryBot-Result: Gobot Gobot 
Reviewed-by: Rob Pike