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

Regression: Call function does not destructure variables #2034

Closed
TxHawks opened this issue Apr 22, 2016 · 4 comments
Closed

Regression: Call function does not destructure variables #2034

TxHawks opened this issue Apr 22, 2016 · 4 comments

Comments

@TxHawks
Copy link

TxHawks commented Apr 22, 2016

When doing:

$args: mix, #fff, #000, 20%;

.foo {
  color: call($args...);
}

Ruby Sass will output:

.foo {
  color: #333333; 
}

But Libsass will output:

.foo {
  color: mix, #fff, #000, 20%...(); 
}

This is happening with: node-sass 3.5.3 wrapping libsass 3.3.5.

TxHawks added a commit to TxHawks/jigsass-tools-color that referenced this issue Apr 22, 2016
TxHawks added a commit to TxHawks/jigsass-tools-color that referenced this issue Apr 22, 2016
@mgreter mgreter added this to the 3.3.7 milestone Apr 23, 2016
@mgreter
Copy link
Contributor

mgreter commented Apr 23, 2016

This is because an early check was added in function call evaluation, since it was needed to avoid the evaluation of the arguments for calc functions (call(calc, ...)). The normal function evaluation has a very messed up logic to deduct the arguments for the ast node (Argument_List, restargs, etc). It probably makes sense to refactor the whole list handling including #1930 (comment), instead of reimplementig the whole argument deduction logic for call invokations.

@xzyfer
Copy link
Contributor

xzyfer commented Apr 23, 2016

I refactored the argument logic to match Ruby Sass in 3.3.3. It should be correct. The issue is more likely which how we're evaling call.

@mgreter
Copy link
Contributor

mgreter commented Apr 23, 2016

@mgreter
Copy link
Contributor

mgreter commented Apr 23, 2016

This is a more complete spec test:

$args: mix, #fff, #000, 20%;
$params: #fff, #000, 20%;

.foo {
  test: call($args...);
  test: mix(#fff, #000, 20%);
  test: call(mix, #fff, #000, 20%);
  test: call(mix, $params...);
}

Currently yields:

.foo {
  test: mix, #fff, #000, 20%...();
  test: #333333;
  test: #333333;
  test: #333333; }

Expected is:

.foo {
  test: #333333;
  test: #333333;
  test: #333333;
  test: #333333; }

So we can probably get away here with one additional check. @xzyfer I also do not like to add such patches, but I see it as a legit way to add the needed behavior until someone (mostly me) gets around to do the actual refactoring. And it has proven to help to have these patches in place, specially if they are documented accordingly. The only small thing that worries me a little is that this pattern may break lazy evaluation as fixed in #1986. To put it short we tend to get away with those patches quite far (and I do keep cleaning up after them).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants