Maintenance release
This release fixes regressions introduced due to dart-sass code back-ports. Additionally a lot
of edge-case crashes have been addressed and we now ensure that compound selectors are
always printed in the correct order to form valid css selectors. Some improvements from the
ongoing LibSass refactoring have been back-ported and new optimized memory allocator
has been added, although for the time being it is disabled by default (compile time option).
Finally loaded sources are now handled by reference counted objects, so we can more easily
guarantee the lifetime of this information for error reporting purposes without making copies.
Moving toward dart-sass
First I hope this version finally fixes all regressions I introduced previously and I apologize for the
disturbance it may have brought to anybody. The compound selector extend changes may still
make your build very slow. The emitted warning should be correct now and if you get one,
chances are high that LibSass will output "unnecessary" big selectors. I will look into a solution for
next maintenance release to at least be able to detect this situation to avoid "endless" compilations.
New deprecation warning
This version will emit a warning if you declare a global variable for the first time inside a nested
scope via the !global option, e.g. the variable doesn't yet exist on the global scope. Sass will
enforce you to declare your global variables explicitly on the global scope first in the future.
C-API change
We added back the definition and implementation related to getting information about the
plugin_paths, since we already had those mentioned and documented in the wiki.
Changelog
- Fix parenthesization for selector schema and real parents (@mgreter) #3047
- Add deprecation warning for global variable creation (@mgreter) #2913
- Ensure correct output order of compound selectors (@mgreter) #3086
- Handle loaded source code as shared objects (@mgreter) #3041
- New custom memory allocator - disabled for now (@mgreter) #3038
- Add back C-API getters for plugin paths (@mgreter) #3087
- Fix abspath handling on windows without directory (@mgreter) #3089
- Fix various edge case crashes (@mgreter) #3032
- Fix segfault on directive ruleset (@xzyfer) #3050
- Fix heap-buffer-overflow in lexer (@xzyfer) #3057
- Fix stack-overflow in parser (@xzyfer) #3058
- Fix memory leak in parser (@xzyfer) #3059
- Fix memory leak in evaluation (@xzyfer) #3060
- Fix memory handling edge case (@mgreter) #3088
- Fix some null pointer access crashes (@mgreter) #3090
- Preparations for ongoing refactoring (@mgreter) #3025
Outlook for LibSass 4.0
I'm already working on a refactoring since close to one year. Certain parts are already in this version
and have been the reason for certain regressions (the extend and parenthesizing part). The work in
progress already has back-ported the parser bits from dart-sass, meaning we can get rid of sass2scss
and have full support for css parsing as dart-sass has. Cssize step was also incorporated fully into the
evaluation phase. AST tree is improved to differentiate between nodes before and after evaluation
(sass nodes evaluate to css nodes). Overall the code uses a lot more C++11 features, but I haven't yet
decided what the minimum requirements will be. I already optimized most cases for move semantics
whenever possible. Overall it seems one can expect at least a 10 fold performance improvement.
The C-API will also change quite substantially, although the basic approach to have functions for
everything will stay the same. But instead of marshaling different structs internally it will use the
C++ object directly. I hope to have this ready for a beta released by end of this year, but it will
not yet contain the new @use import feature from sass though. Maybe somebody wants to
sponsor this feature to be added to LibSass sooner than later? 😃