Bugfixes for source maps

[mgreter]

Fixes #2204
Replaces #2208

• Fixes parent selector mappings
• Fixes media block/query mappings
• Fixes range over binary expressions
• Don't include semicolon for statics
• Fixes variable assignment mappings

I have already deployed the changes to my source map inspector!

Parent selector mappings

SourceMap Inspector (click [inspect] and use keyboard arrows to navigate)

.foo {
  background: red;
  &-bar {
    background: green;
  }
}

Media Block expressions

SourceMap Inspector (click [inspect] and use keyboard arrows to navigate)

.foo {
  background: red;
  @media only screen {
    background: green;
  }
}

Binary expressions

SourceMap Inspector (click [inspect] and use keyboard arrows to navigate)

.foo {
  bar: (1px+3px);
}

Static values

SourceMap Inspector (click [inspect] and use keyboard arrows to navigate)

.foo {
  bar: green   ;
}

Variables (last assignment)

SourceMap Inspector (click [inspect] and use keyboard arrows to navigate)

$var: bar;
$var: (foo + $var);
test { val: $var; }

[nschonni]

FYI, this is a decent resource beyond the spec https://github.com/mozilla/source-map

[nschonni]

valuse -> values

[nschonni]

Indent

[mgreter]

thx @nschonni. Fixed the formatting and typo!

[xzyfer]

Thank you @mgreter. Please try to keep PRs focused. This PR is address 4 different issues of differing merit.

I would prefer not merge the makefile change. The existing order is obvious and self documenting.

[xzyfer]

@mgreter I have cherry picked 314360e and 51ff53f on to master. Please back out f8d9dec, then feel free to ship this.

I'll be feature freezing master after this merge so I release a 3.4 RC this weekend.

[mgreter]

Hmm, f8d9dec saves me 1 minute compile time. But whatever ...

[xzyfer]

I understand as a power user this is of benefit to us. My reasoning is

• it's something that we can't guarantee the correctness of, so it will regress
• it's unclear what to do when adding new files

Given the opportunity I'd prefer to optimise for making life easier for new contributors.

[mgreter]

@xzyfer the order is not really important as long as all files are listed. If a file is missing it will fail in CI as functions will be missing in the executable. I don't see any danger at all here!

[mgreter]

And it was as unclear where to add files before as it is now. The order is now even a bit more logic as I grouped the related stuff together where possible. I just needed to move the bigger files more to the top, so I don't end up with one as the last compile unit.

[xzyfer]

Currently they're listed alphabetically so it is no brainer where a new file belongs in the list.

I'm happy to comprise. Maintain alphabetical ordering, but move the problematic large files to the top, preferably with a comment for why it's out of order.

[mgreter]

I'm ok with adding a comment, but the order is the best as it is now. It is a compromise between having the biggest compile units on top without generating a too heavy memory peak (it's distributed more evenly).

[xzyfer]

This is good. Thank you.