Detached ruleset unlocked from namespaced mixin does not see its namespace scope

[SomMeri]

I defined a detached ruleset inside a namespaced mixin. The ruleset is unable to see variables defined in its outer namespace.

Less:

#namespace {
  @variable: in-namespace;
  .unlocker {
    @detached-ruleset: { property: @variable; };
  }
}
#namespace > .unlocker();

#detached-ruleset {
  @detached-ruleset();
}

actual output:

NameError: variable @variable is undefined in test.less on line 4, column 36:
3   .unlocker {
4     @detached-ruleset: { property: @variable; };
5   }

expected output:

#detached-ruleset {
  property: in-namespace;
}

Edit: I use node.js with lessc 1.7.0 (LESS Compiler) [JavaScript]
Edit 2: this issue is probably related to #2039

[SomMeri]

I re-tested it with lessc 1.7.3. The above does not work. However if the unlocking call is moved into caller scope, the example starts to work:

Works:

#namespace {
  @variable: in-namespace;
  .unlocker {
    @detached-ruleset: { property: @variable; };
  }
}

#detached-ruleset {
  #namespace > .unlocker(); //change is here
  @detached-ruleset();
}

[seven-phases-max]

This seems like a general variable scoping bogus rather than a DR specific issue.
Notice this also works:

#namespace {
    @variable: in-namespace;
    .unlocker {
        @unlocker-variable: @variable;
    }
}

#in-scope {
    #namespace > .unlocker();
    property: @unlocker-variable;
}

But this fails:

#namespace {
    @variable: in-namespace;
    .unlocker {
        @unlocker-variable: @variable;
    }
}

#namespace > .unlocker(); // Error: variable @variable is undefined

I.e. it does not work with the original example only because the namespaced mixin expansion works differently in global scope for some reason (i.e. it does not expose the namespace scope at all - I'm not sure if we have a related issue ticked already).

P.S. Ah, it's #921.(Hmm, that's interesting, I knew it works this way in the global scope but I did not know it actually works the other way around anywhere else (unless covered by #1316))

[SomMeri]

@seven-phases-max I think that #1316 is something else - examples there do not use unlocking. I never tried this with variables as far as I remember.

[seven-phases-max]

I think that #1316 is something else

Yes. I mean that it just gets even more complicated to know what to expect when using #namespace > .mixin() pattern, i.e. the result depends not only on how it was defined but also on where it is used.
(Unlocking just inherits the mixin scope itself, i.e. if a variable is not visible in the mixin itself then it can't be expanded into the caller as well (and vice-versa)).

[SomMeri]

If I understood you right, I would expect that:

• variables and mixins defined in mixin itself (and imported there) would be expanded into caller,
• those defined in namespace would not be expanded,
• mixin itself could use everything defined in namespace.

[seven-phases-max]

Consider merging this to #921 (thus to #996) as it definitely looks like the same issue.
(As the error is in #namespace > .unlocker(); statement not exposing the @variable to .unlocker(), thus it's not DR specific).