html/template: Execute panics on custom function errors after Clone

[gopherbot]

by pavadeli:

Normally, when I use custom functions inside an html/template template, errors returned
by my custom functions will be returned to the caller of template.Execute. Unfortunately
this stops working when you clone templates. It will then panic on any error with a
"slice bounds out of range".

What steps will reproduce the problem?
See: http://play.golang.org/p/dvleW7dxE9

What is the expected output?
template: :1:2: executing "" at <myFunc>: error calling myFunc: My error!

What do you see instead?
panic: runtime error: slice bounds out of range [recovered]
    panic: runtime error: slice bounds out of range


Which compiler are you using (5g, 6g, 8g, gccgo)?
- reproducible in go playground -

Which operating system are you using?
- reproducible in go playground -

Which version are you using?  (run 'go version')
- reproducible in go playground -

Please provide any additional information below.

[gopherbot]

Comment 1 by pavadeli:

By the way, it works correctly for text/template.

[gopherbot]

Comment 2 by pavadeli:

It turns out that all errors that occur during template execution suffer from this bug.
For example, if you add an argument to the myFunc function call in the playground
example you also get the same problem:
const tmplString = `{{myFunc "arg1"}}`
I am currently considering, as a partial workaround, to create wrappers for all custom
functions that start panicking on any returned errors. For example, if you rewrite
myFunc in the go playground example as follows, then the error is returned:
func myFunc() (string, error) {
    panic(fmt.Errorf("My error!"))
}
Anyone a better idea? This works for custom functions, but of course not for errors that
occur in the template itself.

[rsc]

Comment 3:

Labels changed: added priority-later, go1.2, removed priority-triage.

Status changed to Accepted.

[josharian]

Comment 4:

The problem is that text/template/parse's Tree.text wasn't getting copied during the
clone. Unfortunately, I don't see any way to fix this without adding to the public API.
Proposed fix in https://golang.org/cl/12420044

[robpike]

Comment 5:

This issue was closed by revision eeb7585.

Status changed to Fixed.