Formatting warnings/errors from glslc so VS can process them in the Errors/Issues List

[alecazam]

The formatting of errors, means that VS can't jump to them. Having to scour the build errors instead of a summary list isn't fun. Ideally VS should take in both of these styles, but doesn't.

VS wants errors formatted like this. Clang-cli and MSVC also format this way. So that's all VS intercepts.

1>Data/Shaders/LumFeedback.vert(65): error: 'setPointSize' : no matching overloaded function found

1>Data/Shaders/LumFeedback.vert(65,1): error: 'setPointSize' : no matching overloaded function found

But glslc formats them on Windows like this. This is how mac/linux clang format errors.

1>Data/Shaders/LumFeedback.vert:65: error: 'setPointSize' : no matching overloaded function found

[alecazam]

In message.cc, line 241

 switch (type) {
        case MessageType::Error:
        case MessageType::Warning:
          assert(!name.empty() && !line_number.empty() && !rest.empty());

 	*error_stream << name
#ifdef _WIN32 <- or whatever test is for Win platform build
          << "(" << line_number << ")"
#else 
	 << ":" << line_number 
#endif 
			<< ": "
                        << (type == MessageType::Error ? "error: "
                                                       : "warning: ")
                        << rest.strip_whitespace() << std::endl;

[dj2]

This seems more like a VS issue then a shaderc issue.

I'd be hesitant to change the format being emitted because we don't know if anything is depending on that format at this point.

[alecazam]

Then can a CLI setting be passed to alter the format then. VS has used this format for 30 years. I've already asked VS to update their error parser, but it's been a 2 year wait. The change above is a few lines.

This clickthrough is critical for tying the IDEs and also tying the IDE Issues Lists to shader errors. So then you can have shaders in a project, run the build script, and click through to 10's to 100's of warnings/errors.