html/template: add break and continue

[dgryski]

#20531 added break and continue to text/template, but these keywords are not available in html/template.

Running a simple template (https://github.com/campoy/gotalks/blob/master/go1.10/template/main.go) with html/template fails at runtime with

panic: escaping {{continue}} is unimplemented

[ghost]

I'll send a CL.

https://golang.org/cl/91815

[ALTree]

Why do the 1.10 release notes say that html/template supports {{break}} and {{continue}}? Either we add them to html/template before the release, or we need to delete that paragraph from the 1.10 release notes.

I've sent a CL in case we decide to go with the latter.

[dgryski]

html/template is a wrapper around text/template that adds context-senstive escaping. The oversight in the original patch as that the html escaping logic needs to be updated to deal with the new template commands.

[ALTree]

The fix looks small but it's not up to me so labelling this as NeedsDecision for 1.10.

[gopherbot]

Change https://golang.org/cl/91815 mentions this issue: html/template: add support for {{break}}, {{continue}}

[andybons]

/cc @ianlancetaylor

[rsc]

It sure is unfortunate that we never tested that break and continue work in html templates.

I don't believe CL 91815 is sufficient to add them. Break and continue stop the control flow midway through a range loop iteration. The flow-sensitive analysis of HTML context assumes that the loop body runs in full. It would need to be updated to take the early stop into account. I don't see an easy way to do that in the code. Go 1.10 was supposed to have shipped already. It seems to me far too late to add a change this subtle.

It seems like the safest course of action is to remove break and continue from both text/template and html/template for Go 1.10, and then add them back in Go 1.11, with appropriate attention spent on html/template.

Thoughts?

/cc @robpike @mikesamuel @stjj89

[robpike]

I agree, the change to text/template should be rolled back.

[stjj89]

CL 91815 actually looks fine to me. I don't think that html/template assumes that the loop body will run in full; it escapes the range loop so that it will always produce safe output, no matter how it is executed at run-time. Specifically, it unconditionally escapes the nodes in the if and else branches of a range loop, and checks that executing the body of the range loop multiple times does not change its escaping context.

I can't come up with an edge case involving continue or break that the current escaping logic will not handle. I might be missing something, though. It probably makes sense to delay this change to Go 1.11 so we have more time to consider and test this change.

[gopherbot]

Change https://golang.org/cl/92155 mentions this issue: text/template: revert CL 66410 "add break, continue actions in ranges"

[mikesamuel]

On Feb 5, 2018 2:29 PM, "Samuel Tan" ***@***.***> wrote: CL 91815 actually looks fine to me. I don't html/template assumes that the loop body will run in full; it escapes the range loop so that it will always produce safe output, no matter how many times the body is executed, if any at all. Specifically, it unconditionally escapes the nodes in the if <https://github.com/golang/go/blob/master/src/html/template/escape.go#L477> and else <https://github.com/golang/go/blob/master/src/html/template/escape.go#L493> branches of a range loop, and checks <https://github.com/golang/go/blob/master/src/html/template/escape.go#L479> that executing the body of the range loop multiple times does not change its escaping context. I can't come up with an edge case involving continue or break that the current escaping logic will not handle. I might be missing something, though. It probably makes sense to delay this change to Go 1.11 so we have more time to consider and test this change. So it's not a problem where a loop body does something like

<script>{{if .C}}{{..}}{{else}}{{break}}{{end}}</script>

[rsc]

Exactly. This is why we're rolling it back.

[stjj89]

<script>{{if .C}}{{..}}{{else}}{{break}}{{end}}</script>

Ah, that makes sense. We can probably fix this by storing the context whenever we see break or continue, and comparing that context with the end-of-loop context when we get there.

[mikesamuel]

On Wed, Feb 7, 2018 at 1:25 PM, Samuel Tan ***@***.***> wrote: <script>{{if .C}}{{..}}{{else}}{{break}}{{end}}</script> Ah, that makes sense. We can probably fix this by storing the context whenever we see break or continue, and comparing that context with the end-of-loop context when we get there. Yep. I think just treating both break and continue as a jump to end of

body would do it since the loop increment does nothing to the output buffer, and we already reconcile the loop body end context with the loop start context.

[seankhliao]

This was added in 1.18