Generated code triggers CodeQL go/useless-assignment-to-local for GetChildren fallback

[andreas-ekman-wcar]

What happened?

Generated *_templ.go files contain a child-component fallback assignment that CodeQL reports as go/useless-assignment-to-local:

ctx = templ.InitializeContext(ctx)
templ_7745c5c3_Var1 := templ.GetChildren(ctx)
if templ_7745c5c3_Var1 == nil {
    templ_7745c5c3_Var1 = templ.NopComponent
}
ctx = templ.ClearChildren(ctx)

CodeQL reports the assignment to templ_7745c5c3_Var1 as useless when the generated component does not read the children variable later. This creates noisy code scanning alerts for generated templ output.

This seems related to #1295, but the scanner here is GitHub CodeQL rather than Staticcheck.

Why it looks removable

templ.GetChildren(ctx) already appears to return templ.NopComponent when no children are present:

func GetChildren(ctx context.Context) Component {
    _, v := getContext(ctx)
    if v.children == nil {
        return NopComponent
    }
    return *v.children
}

So the generated nil check/fallback appears redundant, and when the children variable is not subsequently used, it triggers a dead-store warning.

Reproduction

Generate a templ component that does not use children, then scan the generated Go with CodeQL security-and-quality queries. In our case the generated file header is currently from v0.3.977, with the module pinned to github.com/a-h/templ v0.3.1001.

I also tested generation with v0.3.1020; the same GetChildren/NopComponent pattern is still emitted.

Expected behavior

Ideally generated code should avoid the redundant nil fallback, or avoid declaring the children variable when the component body does not use children, so generated files do not trigger go/useless-assignment-to-local.

templ version

Observed with generated output from v0.3.977; still reproducible when generating with v0.3.1001 and v0.3.1020.

CodeQL rule

go/useless-assignment-to-local

https://codeql.github.com/codeql-query-help/go/go-useless-assignment-to-local/

[joerdav]

Hi, thanks for the suggestion. I'm not sure how much value this would add, historically we haven't made changes to accommodate linters. I wouldn't recommend running tools like this on generated code, besides security scans, generated code is not meant for human consumption.

@a-h may think otherwise?

[andreas-ekman-wcar]

Thanks, I understand the general position for linters.

The challenge for us is that this is not just a discretionary local lint check. In some production repositories, CodeQL/code scanning is centrally enforced as part of the security posture, and application teams may not have permission to exclude generated files or tune the query set. From that scanner’s point of view, committed *_templ.go files are production source.

That means avoidable quality findings in generated code can show up alongside real security findings. Even when the specific rule is not a vulnerability, it still creates noise in the same workflow people use for security review, and that can make it harder to maintain a clean signal-to-noise ratio.

I agree generated code is not meant for human consumption, but generated output that follows the same “no obvious dead stores / no redundant assignments” expectations as handwritten code helps downstream teams keep mandatory code scanning useful.

Since GetChildren(ctx) already falls back to NopComponent, removing the redundant nil assignment, or avoiding the unused children variable when children are not rendered, would make the generated output cleaner without changing behavior.

[a-h]

I wonder if there was an issue that caused us to solve the issue in both places, e.g. we found a bug and needed to fix it when the templ version in the go.mod was older than the generator.

I'd have to check the old behaviour, but if there was an issue, it was probably a few years ago. If we can remove a useless assignment in the generated code, I don't see why we wouldn't do it.

It may be that there's some old combination of templ in the go.mod with generated code, that pre-dates the go.mod check we added to the templ generate command.

[joerdav]

Ah, we're just proposing removing the nil check, apologies I think I got my wires crossed on what this is about, I wrongly thought we were talking about the initial assignment when children aren't used in the component. Yeah that makes sense to do.