A field in a structure is sometimes protected by Mutex, but sometimes unprotected.

[BurtonQin]

What version of Hugo are you using (hugo version)?

master branch, commit c03ea2b66010d2996d652903cb8fa41e983e787f

What happened: A field in a structure is sometimes protected by Mutex, but sometimes unprotected. This may lead to data race. There are 2 such cases:

• [ ] templateStateMap.templates is not protected by t.mu on L754. But for all the other 3 places, it is protected by t.mu. https://github.com/gohugoio/hugo/blob/c03ea2b66010d2996d652903cb8fa41e983e787f/tpl/tplimpl/template.go#L722-L723
• [ ] t.text is not protected by t.nameSpace.mu on L35. But for all the other 3 places (https://github.com/gohugoio/hugo/blob/master/tpl/internal/go_templates/htmltemplate/template.go), it is protected by t.nameSpace.mu. https://github.com/gohugoio/hugo/blob/c03ea2b66010d2996d652903cb8fa41e983e787f/tpl/internal/go_templates/htmltemplate/hugo_template.go#L31-L35

What you expected to happen: Data race

[paskal]

The only way to properly protect t.text (as it's used elsewhere after return) is to make a deep copy of it and return the pointer to that copy instead of the original: that's a cure worse than the disease, in my opinion, as it will complicate code for no clear benefit.

[bep]

This may lead to data race.

Only if it's read/write from multiple go routines at the same time.

1. postTransform is, to my knowledge, always done in 1 thread and before the templates gets used.
2. Any concurrency issue with t.text should be addressed in the source (Go stdlib).

Also, note that we have a fair amount of tests that run this code successfully with the -race flag enabled.