Improve resources.Copy to prevent nil pointer when using unusual construct

[jmooring]

Reference: https://discourse.gohugo.io/t/nil-pointer-evaluating-resource-resource-relpermalink-when-using-resources-copy/49030/14

Error:

Error: error building site: render: failed to render pages: render of "page" failed: "/home/jmooring/code/hugo-testing/layouts/_default/single.html:4:5": execute of template failed: template: _default/single.html:4:5: executing "_default/single.html" at <$r.RelPermalink>: nil pointer evaluating resource.Resource.RelPermalink

Notes:

1. I have no idea if this a bug or an enhancement.
2. If it's a bug, it's been there forever; this isn't anything new.
3. The construct below is unusual. The example reported in the forum topic makes sense, while the test case below is simply a minimal reproducer.
4. The OP has at least two ways to get around this.

Minimal reproducible example:

git clone --single-branch -b hugo-forum-topic-49030 https://github.com/jmooring/hugo-testing hugo-forum-topic-49030
cd hugo-forum-topic-49030
hugo

Test case:

func TestFoo(t *testing.T) {
	t.Parallel()

	files := `
-- hugo.toml --
disableKinds = ['home','section','rss','sitemap','taxonomy','term']
-- assets/a.txt --
This was assets/a.txt
-- content/p1.md --
---
title: p1
---
{{< sc >}}
-- layouts/shortcodes/sc.html --
{{ $noop := resources.Get "/p1/b.txt" }}
-- layouts/_default/single.html --
{{ $noop := .Content }}
{{ $r := resources.Get "a.txt" }}
{{ $r = resources.Copy "/p1/b.txt" $r }}
{{ $r.RelPermalink }}
{{/* In the above, no errors you remove line 1. */}}
`

	b, err := hugolib.TestE(t, files)

	b.Assert(err, qt.IsNil)
	b.AssertFileContent("public/p1/b.txt", "This was assets/a.txt")
}

In the above, resources.Get "/p1/b.txt" is not a typographical error. Again, the example reported in the forum topic makes sense; the above is a minimal reproducer.

My best guess is that we cache a nil resource when calling the shortcode, and resources.Copy doesn't overwrite it because... it's cached.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.