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

@at-root regression with nested mixin #2198

Closed
eoneill opened this issue Sep 30, 2016 · 1 comment · Fixed by #2199
Closed

@at-root regression with nested mixin #2198

eoneill opened this issue Sep 30, 2016 · 1 comment · Fixed by #2199

Comments

@eoneill
Copy link

eoneill commented Sep 30, 2016

Testing against latest libsass/master, we encountered an odd issue when a selector is generated by a mixin nested within an @at-root directive. Possibly related to #2187

test case:

@mixin test() {
  @at-root {
    @include foo();
  }
}

@mixin foo() {
  #{'.foo'} {
    bar: baz;
  }
}

.test {
  @include test();
}

expected (ruby Sass 3.4, libsass 3.3.6):

.foo {
  bar: baz; }

actual (libsass/master (3.4rc)):

.test .foo {
  bar: baz; }

Spec added sass/sass-spec#935

xzyfer added a commit to xzyfer/sass-spec that referenced this issue Oct 1, 2016
@xzyfer
Copy link
Contributor

xzyfer commented Oct 1, 2016

Looks like the regression was caused by a new feature in #2089. Hopefully this means it should be a straight forward fix.

@xzyfer xzyfer added this to the 3.4 milestone Oct 1, 2016
@xzyfer xzyfer self-assigned this Oct 1, 2016
This was referenced Oct 1, 2016
xzyfer added a commit to xzyfer/sass-spec that referenced this issue Oct 3, 2016
xzyfer added a commit to xzyfer/libsass that referenced this issue Oct 4, 2016
LibSass fully parses selectors during the parsing stage. This is
different from Ruby Sass which parse selectors and string during
the parsing stage, and lazily eval'ing when required. This
difference causes some pathological selector issues. Our eager
parsing of selectors has resulted in us hacking in fake
`Parent_Selector` into `Sequence_Selector` during parsing.

These fake `Parent_Selector` play havoc with `resolve_parent_refs`
when within `@at-root` blocks. I spent a couple weeks going down
the rabbit whole of refactoring our selector parsing to be lazy before
bailing.

Explicitly marking which `Parent_Selector` are fake during parsing
allows us faithfully implement the `implicit_parent` flag in
`resolve_parent_refs`.

Fixes sass#2006
Fixes sass#2198
Spec sass/sass-spec#936
xzyfer added a commit to xzyfer/libsass that referenced this issue Oct 4, 2016
LibSass fully parses selectors during the parsing stage. This is
different from Ruby Sass which parse selectors and string during
the parsing stage, and lazily eval'ing when required. This
difference causes some pathological selector issues. Our eager
parsing of selectors has resulted in us hacking in fake
`Parent_Selector` into `Sequence_Selector` during parsing.

These fake `Parent_Selector` play havoc with `resolve_parent_refs`
when within `@at-root` blocks. I spent a couple weeks going down
the rabbit whole of refactoring our selector parsing to be lazy before
bailing.

Explicitly marking which `Parent_Selector` are fake during parsing
allows us faithfully implement the `implicit_parent` flag in
`resolve_parent_refs`.

Fixes sass#2006
Fixes sass#2198
Spec sass/sass-spec#936
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants