Bug: extend compiled incorrectly (leaks through nested &)

[infendory]

The following LESS source is compiled incorrectly:

.bordered {
    border: solid 1px black;
}

.somepage {
    .content:extend(.bordered) {
        &>span {
            margin-bottom: 10px;
        }
    }
}

Produced CSS file:

.bordered,
.somepage .content,
.somepage .content > span {
  border: solid 1px black;
}
.somepage .content > span {
  margin-bottom: 10px;
}

border rule for .somepage .content > span is incorrect.

The simpler following source will be compiled correctly:

.bordered {
    border: solid 1px black;
}

.content:extend(.bordered) {
    &>span {
        margin-bottom: 10px;
    }
}

[seven-phases-max]

Confirmed.

---

Workaround: you don't need & there, use:

.bordered {
    border: solid 1px black;
}

.somepage {
    .content:extend(.bordered) {
        > span {
            margin-bottom: 10px;
        }
    }
}

instead.

Alternatively use nested &:extend, i.e.:

.bordered {
    border: solid 1px black;
}

.somepage {
    .content {
        &:extend(.bordered);
        & > span {
            margin-bottom: 10px;
        }
    }
}

[seven-phases-max]

(selfnote) It looks like :extend is considered to be a part of "parent selectors" (hence it copied with &) but it obviously should not be.

[matthew-dean]

It looks like :extend is considered to be a part of "parent selectors" (hence it copied with &) but it obviously should not be.

I think you're right. The extend should "target" the preceding selector to be added to the declaration(s) for .bordered. Unless..... by using & someone is implying that it is a "part of" the preceding selector? I wonder if that should be changed, because it's possible someone is relying on this behavior to inherit extend? I can't think of a use case, but as you just pointed out two different ways to write it to get the intended result, I might lean towards leaving the behavior as is. That is: in the category of "undefined behavior".

[seven-phases-max]

I wonder if that should be changed, because it's possible someone is relying on this behavior to inherit extend?

But this clearly a bug. All three snippets in my answer should produce the same result just by definition.

x:extend(y) {
    // something ...
}

and

x {
    &:extend(y);
    // something ...
}

should produce equal CSS regardless of something.
Same way notice in the last OP example the compiler already does skip :extend for the first level nesting selector (so the error is most likely just in first-level-check-only instead of all the way through).

[SomMeri]

Fixed by #2759