html/template: behaviour of HTML templates changed between 1.7.5 and 1.8

[seehuhn]

What did you do?

When I use the html/template package I get non-deterministic output with Go version 1.8. The same program, when run with Go version 1.7.5 always gives the same output.

A minimal "working" example is here:
https://play.golang.org/p/2vVYZkiTFx

The program parses and executes the same template 100 times and counts how often it gets which output. On Go 1.8 I get results like

89

--- 11 ---

What did you expect to see?

On Go 1.7.5 I always get the same output, namely the following:

100

---

What did you see instead?

see above

System details

go version go1.8 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/voss/go-external:/Users/voss/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="/usr/bin/gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/var/folders/2g/mfxxbx6d3yl_hqdh8b9j1wmm0000gn/T/go-build654454144=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="/usr/bin/clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
GOROOT/bin/go version: go version go1.8 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.8 X:framepointer
uname -v: Darwin Kernel Version 16.4.0: Thu Dec 22 22:53:21 PST 2016; root:xnu-3789.41.3~3/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.12.3
BuildVersion:	16D32
lldb --version: lldb-360.1.70
gdb --version: GNU gdb (GDB) 7.12.1

[seehuhn]

If I change {{block "stylesheets" .}}{{end -}} to {{template "stylesheets" . -}} in my example, the problem goes away. Thanks to Владимир Мулько on golang-nuts for this suggestion!

[bradfitz]

/cc @rsc @robpike ... who owns templates these days?

[robpike]

This is almost certainly a bug, and a mysterious one at that. Since it's a bug in text/template (the example uses html/template but the problem exists in the lower-level library) I can look at it.

[robpike]

Reports on the mailing list say this one broke it:

commit 2b583a190eb14c69bffe5d488d2d6d3862fe76ea
Author: Jess Frazelle <me@jessfraz.com>
Date:   Wed Jun 22 21:57:52 2016 -0700

    text/template: fix Parse when called twice with empty text
    
    Fixes #16156
    
    Change-Id: I6989db4fd392583a2d490339cefc525b07c11b90
    Reviewed-on: https://go-review.googlesource.com/24380
    Reviewed-by: Andrew Gerrand <adg@golang.org>
    Run-TryBot: Andrew Gerrand <adg@golang.org>

[seehuhn]

I just run "git bisect" and it also came out with 2b583a1 as the first bad commit.

[rsc]

In the breaking CL, it looks to me like

if t.tmpl[new.name] != nil && parse.IsEmptyTree(tree.Root) && t.Tree != nil {

is checking the wrong thing tree. t.tmpl[new.name] is the interesting template, not t itself. Should probably be:

if old := t.tmpl[new.name]; old != nil && parse.IsEmptyTree(tree.Root) && old.Tree != nil {

The non-determinacy of the example is likely due to html/template walking a map and making calls a variety of orders (that should all behave the same).

[robpike]

Yes, I think that's the fix.

[robpike]

@rsc's change fixes the test here but breaks the TestEmptyTemplate test. Working on it.

[gopherbot]

CL https://golang.org/cl/38420 mentions this issue.

[rsc]

Reopening for backport.