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

tablerow: Avoid accidental special case for constant nil cols #1644

Merged
merged 1 commit into from Oct 25, 2022

Conversation

dylanahsmith
Copy link
Contributor

Problem

#1633 recently introduced a weird special case behaviour for a nil literal for the tablerow columns, which differs from an expression that evaluates to nil. This is because @attributes['cols'].nil? would match a nil literal expression, but wouldn't match an expression that dynamically evaluates to nil.

The included regression test demonstrates the problem, where {% tablerow i in (1..2) cols:nil %}{{ tablerowloop.col_last }}{% endtablerow %} doesn't produces the same output as {% tablerow i in (1..2) cols:var %}{{ tablerowloop.col_last }}{% endtablerow %} when var is nil.

Solution

It seems like the intended behaviour is to default 'cols' to the length of the slice being iterated over, as @attributes.key? does for the 'offset' and 'limit' attributes. So I updated the expression to default 'cols' to also use @attributes.key?.

It should behave the same as an expression that evaluates to nil
Copy link
Contributor

@ggmichaelgo ggmichaelgo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

eeek! Thank you for catching this and fixing this @dylanahsmith !

@dylanahsmith dylanahsmith merged commit 6ce4ec1 into master Oct 25, 2022
@dylanahsmith dylanahsmith deleted the tablerow-avoid-const-nil-cols-special-case branch October 25, 2022 14:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants