API: Expose Access to Compiler Warnings

[bdkjones]

Issue:

Looking at error_handling.cpp, all deprecation warnings are currently hard-coded to print to STDERR.

Could this be changed so that implementors have access to these warnings, like we do for actual errors? STDERR is only useful if libsass is running in a Terminal environment, which it isn't in my case.

Proposal:

If a custom function to handle @warn statements is registered with Libsass, call that function and pass the deprecation warning just as you would for a normal @warn statement. If there is no custom handler for @warn registered, then fallback to printing the warnings to STDERR.

To allow implementors to differentiate between user warnings and compiler warnings, we could add one more property-getter such as sass_warning_get_origin(). Or an alternate name like sass_warning_is_user_generated(), etc.

Complexity

I do see a few variants of the deprecation handlers in error_handling.cpp, but it looks like all of them have the same information as a normal @warn: filename, line, column, message.

Version:

Libsass 3.6.3

[mgreter]

Closely related to #2862

[bdkjones]

Damn! I did search issues before posting. It might still be useful to get the warnings as a sass_value list so that we can format them as we like, etc. Merely dumping the output from stderr to a combined string is less flexible.

[bdkjones]

Would it be useful to re-use the @warn handler, if one is registered? Semantically, there's very little difference between a warning produced by the compiler and one produced by a @warn statement and as long as implementors had a way to determine which type a given warning is (if they choose to do so) perhaps re-using the existing mechanism would be clean and simple?