Invalidly escaped selectors get silently swallowed

[BPScott]

In Libsass 3.3 when you have invalidly escaped selectors they can get silently swallowed and never output without throwing a compilation exception. Consider the following scss:

$key: 'bar';
.test11#{'\@#{$key}'} { content: '1.1'; }

.test12#{'\\@#{$key}'} { content: '1.2'; }

//---

$suffix1: '\@#{$key}';
.test21#{$suffix1} { content: '2.1'; }

$suffix2: '\\@#{$key}';
.test22#{$suffix2} { content: '2.2'; }

//---

.test31#{'\@baz'} { content: '3.1'; }

.test32#{'\\@baz'} { content: '3.2'; }

In libsass 3.3.1 (I'm using node-sass 3.4.1 as a wrapper) the above compiles to:

.test11\@bar {
  content: '1.1'; }

.test22\@bar {
  content: '2.2'; }

.test32\@baz {
  content: '3.2'; }

Note that the output for tests 1.2, 2.1 and 3.1 are all absent. Running this against Ruby Sass 3.4.14 (using sassmeister.com) gives compile errors that those tests have invalid CSS. Commenting out those test cases allows the scss to compile.

This is particularly an issue as libsass 3.2 (again, tested using sassmeister.com) treats cases 1.1, 2.1 and 3.2 as valid scss, but refuses to compile 1.2, 2.2 and 3.1 which means that when upgrading from libsass 3.2 to 3.3 there are no compile-time errors but parts of your CSS file go missing.

I would expect that the three cases 1.2, 2.1 and 3.1 would raise an exception when compiling in libsass 3.3 so that bad selectors issues are obviously highlighted rather than being glossed over.

[xzyfer]

Thanks for the report @BPScott

[saper]

I have tested this against 3.3.2 and I see two issues:

One is that '\@baz' is accepted by libsass as valid (1.1, 2.1, 3.1)

Another is that 1.2 generates empty output on libsass, I have filed #1734 for that.

[mgreter]

Closing this as we should only differ in the error message text now.
There are currently more important error messages that we should get right first.