proposal: text/template,html/template: Template.ExecuteLite skip resolution to methods to allow DCE

[seankhliao]

Proposal Details

Use of reflect.Value.Method or reflect.Value.MethodByName disables dead code elimination in the linker as it cannot know needs to kept around vs what can be dropped.

text/template and by extension html/template are perhaps the main paths through which these methods become reachable in programs written in Go.
This leads to issues like:

• x/net/trace: dependency on html/template inhibits dead code elimination #62024: x/net/trace: dependency on html/template inhibits dead code elimination
• Allow linker to perform deadcode elimination for program using Cobra spf13/cobra#1956 cobra using text/template disable DCE

I assert that many using of text/template only need to operate on static data (precomputed struct fields, maps, slices).
A new method for template execution that skips attempting to resolve arguments to methods could work for a majority of users while still enabling DCE.

package template

// ExecuteLite executes the named template like [Template.ExecuteTemplate]
// except that arguments are not resolved to methods. For example:
//
//   {{ .Foo }}
//
// Would resolve to a struct field named "Foo", or a map with the key "Foo", 
// but not a method named "Foo".
//
// Exclusive use of [Template.ExecuteLite] in rendering templates allows the compiler
// to perform dead code elimination.
func (t *Template) ExecuteLite(w io.Writer, name string, data any) error

[seankhliao]

cc @robpike

[gabyhelp]

Related Issues

• x/net/trace: dependency on html/template inhibits dead code elimination #62024
• proposal: cmd/link: option to force DCE when reflect Method is present #72888
• x/text: usage of text/template or html/template disables compiler DCE #72787
• text/template: builtins global map impacts dead code elimination #36021 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[robpike]

I never liked APIs designed to work around toolchain problems. They are a category error.

[seankhliao]

It can also be considered as a safe API which won't have any unexpected side effects from executing code.

maybe naming it ExecuteStatic

[ikonst]

1. Do we have other examples of such 'category errors'? Especially APIs which have been there for a while, so we can see if we've grown to regret them or whether the rationale seems moot now.

2. To draw a parallel, consider APIs which make an RPC. They have a cost that we routinely acknowledge, and sometimes work around by providing a local alternative. How is this different from acknowledging toolchain limitations? (RPC cost is localized while DCE suppression is "use anywhere, pay everywhere", ostensibly worse, but my parallel isn't about the cost but about acknowledging cost.)

3. To @seankhliao 's point there's silver lining to a template that's safe from code execution. I'd be surprised this didn't come up before.

[ianlancetaylor]

Do we have other examples of such 'category errors'?

We try to avoid such APIs so I don't know that there are many examples in the standard library.

I don't see the comparison to RPCs as particularly relevant. RPCs have an inherent cost, as you say. That cost doesn't have anything to do with tooling, it's part of the definition of RPCs.

What we're talking about here is that the linker has a particular optimization in which it removes unreferenced methods. When some standard library calls are used, that optimization is invalid, so it isn't performed. None of this is inherent to the way that methods are used in Go. It's just a specific implementation of a specific optimization in the linker.

The argument that you are making is in some ways an argument against making this kind of optimization at all. Optimizations that have a surprising performance cliff are confusing for users. In the discussion of the CL that added this linker optimization, https://go.dev/cl/20483, text/template came up and it seems that people decided that the optimization was worth doing anyhow for small utility programs. It seems unfortunate to use that to say that now the optimization applies to large programs so we have to figure out a way to complicate templates. It seems like a valid alternative is to say that the optimization only applies to small utility programs.

[ianlancetaylor]

By the way, I don't think the security argument is all that strong, because in my experience most code passes a customized type to text/template. That type has whatever methods are needed, and generally nothing else. Also, of course, most code does not use user input as a template.

That said, that does point the way to a different approach. The compiler/linker can record calls to text/template.(*Template).Execute and record the type being passed in. Then the linker could ensure that all methods of that type are retained, but not require that all methods of all types be retained.

This is, of course, a significant special case for the standard library. But all of this code is already a special case.

From a quick look, text/template is the only standard library package that calls MethodByName. The net/rpc package does call Method, but that package is not nearly as widely used.

[seankhliao]

It's hard to show with just a github search but quite often I see Template.Execute used with map[string]any or similar, though I agree it isn't great practice working with unclear data, https://github.com/search?q=language%3AGo+%2Ft.*m%3Fp%3Fl%3F.*Execute%28Template%29%3F%5C%28.*%2C%2F&type=code

I think that nested any would defeat analysis by the compiler as different types can be passed inside?

but maybe that's better if method use in templates are really common. Also hard to search for, and we don't encourage getters but: https://github.com/search?q=%2F%5C%7B%5C%7B.*+%5C.Get.*%5C%7D%5C%7D%2F&type=code&p=1

I did propose this as I also saw this was the only stdlib api that used MethodByName

[ikonst]

Then the linker could ensure that all methods of that type are retained, but not require that all methods of all types be retained.

Since you can chain field invocations, then also (recursively)

• methods of field types
• methods of method return types (if you want to double-down on special casing, you can cull methods which accept arguments as those will fail with "wrong number of args" ;)

[ianlancetaylor]

We don't have to solve every existing case, we just have to provide a clear path forward for people who actually care about this. After all, ExecuteLite doesn't solve every case either.