https://bugs.freedesktop.org/show_bug.cgi?id=63579
--- Comment #16 from Ian Romanick idr@freedesktop.org --- (In reply to comment #15)
Thanks for the clarification, but I'm still not entirely convinced.
I agree that this per-spec for OpenGL ES 3.0 (although I'm a bit disappointed that the ES3-group missed that we in the ES2-group had made it easy for you by requiring #version to be the first bytes, if present), and that there are spec-justification to rejecting the shader in question to compile (due to the character being outside of the character set). And I think we both agree that doing the latter would be a bad idea.
But I don't agree that this is per-spec for OpenGL nor OpenGL ES 2.0. It's the ratified spec that is the standard, not whatever discussions were held during the meeting. And even though you have a large collection of shaders that does not use it, I don't think breaking existing (unknown) applications is a good idea. How many shaders besides syntetic glsparsertest-shaders requires line-continuation to work correctly? My guess would be zero; shaders like these would not compile on AMD, NVIDIA, nor Intel's Windows drivers. I've just tested the latter. So apparently, Mesa is the only major OpenGL implementation that currently implements this.
They all support it in preprocessor directives. We verified this in 2010 when we added that level of support back. As I said before, we've encountered shaders in games that use line continuation for multi-line macros.
#define foo(a, b) \ do { \ b = bar(a); \ } while(0)
Making the support general (instead of just for preprocessor directives) simplified the code greatly. Since I'm responsible for maintaining this code base as my job, that's a strong incentive for me.
By the way, the WebGL conformance tests also checks that line continuation does not work. So there are at least two known, publically available shaders that depends on no line-continuation to work. Of course, the latter is synthetic, but at least it's based on wording in a specification.
I'm not going to add complexity or overhead to the preprocessor for this case. If WebGL tests non-continuation behavior, we can add the browsers to the workaround list.
I'm not trying to be a pain here, I just think you're pushing for a direction that just leads to even more fragmentation and pain.