Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No proper return from partials with 0 as arg #7528

Closed
malcom opened this issue Jul 31, 2020 · 2 comments · Fixed by #9298
Closed

No proper return from partials with 0 as arg #7528

malcom opened this issue Jul 31, 2020 · 2 comments · Fixed by #9298
Assignees
Labels
Milestone

Comments

@malcom
Copy link

malcom commented Jul 31, 2020

Passing 0 integer as an argument to partial template func with return statement (as a function substitute) prevents this "function" from returning the correct value. It looks like the 0 as partial argument is treated as nil context.

Template:

add42: 50: {{ partial "add42.tpl" 8 }}
add42: 42: {{ partial "add42.tpl" 0 }}

Output:

add42: 50: 50
add42: 42: 

File partials/add42.tpl

{{ $v := add . 42 }}
{{ return $v }}

This issue is reproducable with the latest release.

@bep bep self-assigned this Aug 19, 2020
@bep bep added the Bug label Aug 19, 2020
@bep bep added this to the v0.75 milestone Aug 19, 2020
bep added a commit that referenced this issue Aug 19, 2020
We need to make a proper fix for this, but it is better with an error than just silently continue.

Fixes #7572
Updates #7528
@igorburago
Copy link

igorburago commented Sep 9, 2020

I just ran into this problem (in version 0.74.3), as well. In fact, the
bug manifests itself not only when the passed context argument
is zero, but also when it is any empty value: nil; false; string, slice,
or dictionary of zero length. Hugo shows no warnings or errors
pertaining such partial call.

A minimal failing test is as follows:

X{{ partial "retval" dict }}X
{{ define "partials/retval" }}
  {{ return 123 }}
{{ end }}

It incorrectly renders to XX instead of the expected X123X.

The same thing happens when dict is replaced with slice, "",
false, 0, or nil via, say, $.Site.Params.nonexistentparameter.
The erroneous behavior does not depend on the body of the partial
nor the value given in the return statement, as long as the latter is
present in the partial.

A practical example of when this behavior is problematic is the
following partial returning a slice of key-value records from the
dictionary given in the context argument. When the dictionary is
empty, due to the bug, it returns nil instead of the empty slice.

{{ define "partials/itemize" }}
  {{- $items := slice -}}
  {{- range $i, $x := . -}}
    {{- $items = $items | append (dict "index" $i "item" $x) -}}
  {{- end -}}
  {{- return $items -}}
{{ end }}

@bep bep modified the milestones: v0.75, v0.76 Sep 14, 2020
@bep bep modified the milestones: v0.76, v0.77 Oct 6, 2020
@bep bep modified the milestones: v0.77, v0.78 Oct 30, 2020
@bep bep modified the milestones: v0.78, v0.83 Apr 23, 2021
@bep bep modified the milestones: v0.83, v0.84 May 3, 2021
@bep bep modified the milestones: v0.84, v0.85 Jun 18, 2021
@bep bep modified the milestones: v0.85, v0.86 Jul 5, 2021
@bep bep modified the milestones: v0.86, v0.87, v0.88 Jul 26, 2021
@bep bep modified the milestones: v0.88, v0.89 Sep 2, 2021
@bep bep modified the milestones: v0.89, v0.90 Nov 2, 2021
@bep bep modified the milestones: v0.90, v0.91.0 Dec 13, 2021
ptgott added a commit to ptgott/hugo that referenced this issue Dec 16, 2021
Partial with returns values are parsed, then inserted into a
partial return wrapper via wrapInPartialReturnWrapper in order
to assign the return value via *contextWrapper.Set. The
predefined wrapper template for partials inserts a partial's nodes
into a "with" template action in order to set dot to a
contextWrapper within the partial. However, because "with" is
skipped if its argument is falsy, partials with falsy arguments
would not be evaluated.

This replaces the "with" action in the partial wrapper with a
"range" action that isn't skipped if .Arg is falsy.

Fixes gohugoio#7528
ptgott added a commit to ptgott/hugo that referenced this issue Dec 16, 2021
Partials with returns values are parsed, then inserted into a
partial return wrapper via wrapInPartialReturnWrapper in order
to assign the return value via *contextWrapper.Set. The
predefined wrapper template for partials inserts a partial's nodes
into a "with" template action in order to set dot to a
*contextWrapper within the partial. However, because "with" is
skipped if its argument is falsy, partials with falsy arguments
were not being evaluated.

This replaces the "with" action in the partial wrapper with a
"range" action that isn't skipped if .Arg is falsy.

Fixes gohugoio#7528
ptgott added a commit to ptgott/hugo that referenced this issue Dec 17, 2021
Partials with returns values are parsed, then inserted into a
partial return wrapper via wrapInPartialReturnWrapper in order
to assign the return value via *contextWrapper.Set. The
predefined wrapper template for partials inserts a partial's nodes
into a "with" template action in order to set dot to a
*contextWrapper within the partial. However, because "with" is
skipped if its argument is falsy, partials with falsy arguments
were not being evaluated.

This replaces the "with" action in the partial wrapper with a
"range" action that isn't skipped if .Arg is falsy.

Fixes gohugoio#7528
@bep bep closed this as completed in #9298 Dec 17, 2021
bep pushed a commit that referenced this issue Dec 17, 2021
Partials with returns values are parsed, then inserted into a
partial return wrapper via wrapInPartialReturnWrapper in order
to assign the return value via *contextWrapper.Set. The
predefined wrapper template for partials inserts a partial's nodes
into a "with" template action in order to set dot to a
*contextWrapper within the partial. However, because "with" is
skipped if its argument is falsy, partials with falsy arguments
were not being evaluated.

This replaces the "with" action in the partial wrapper with a
"range" action that isn't skipped if .Arg is falsy.

Fixes #7528
@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants