Sourcemaps have wrong line numbers for rules with parent selectors

[squidfunk]

Wrong line numbers break tests relying on sourcemap information

We are trying to integrate Gemini screenshot testing with coverage information which itself relies on the generated sourcemaps. The coverage report is not generated correctly because of wrong line numbers, which we traced back to libsass's sourcemap generation. The behavior differs from Ruby Sass, which generates the correct sourcemaps line numbers and offsets.

When compiling the SCSS source with line number information, the line numbers inserted in the generated source are correct, whereas the line numbers included in the sourcemap are wrong. Both rules point to line number 1:

input.scss

.foo { // line 1
  background: red;

  &-bar { // line 4
    background: green;
  }
}

libsass 3.3.6

sassc -l --sourcemap test.scss test.css

/* line 1, [...]/test.scss */
.foo {
  background: red; }
  /* line 4, [...]/test.scss */
  .foo-bar {
    background: green; }

/*# sourceMappingURL=test.css.map */

ruby sass 3.4.22

sass -l --sourcemap=file test.scss test.css

/* line 1, test.scss */
.foo {
  background: red; }
  /* line 4, test.scss */
  .foo-bar {
    background: green; }

/*# sourceMappingURL=test.css.map */

version info:

$ sassc --version
sassc: 3.3.6-24-geee6
libsass: 3.3.6-144-g50a6-dirty
sass2scss: 1.1.0
sass: 3.4

Help needed?

I'm currently debugging libsass trying to find the source of the problem. Is this issue already known? If not, I would investigate and try to fix the bug.

[squidfunk]

Digging into the code, in my view, sourcemap support can be nothing else but entirely broken. I'm currently trying to fix it in my fork and will submit a PR when done. Sourcemaps in Chrome are already working correctly (the case stated above), but still some way to go to make it adhere to the specs.

[mgreter]

I wrote a lengthy response for your pull request in #2208.
Agree that this is a valid issue as it is probably more usefull to point inner scope and not the outer here. As mentioned in the linked response I could imagine even more detailed mappings as wrapping the whole selector first and then have mappings for each part (parent and postfix). The possibilites would be nearly endless. But for now libsass cannot handle this anyway, as each token can only hold one start and end mapping (via ParserState). Once the final selector .foo-bar is created we have to decide which mapping we want to keep around. Which is also the place where to fix this issue.

[squidfunk]

This is fixed in the commit I linked in the linked PR. Would be awesome to get this into 3.4 (if I understood you correctly)