https://bugs.freedesktop.org/show_bug.cgi?id=63579
--- Comment #17 from Erik Faye-Lund kusmabite@gmail.com --- (In reply to comment #16)
(In reply to comment #15)
Thanks for the clarification, but I'm still not entirely convinced.
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)
That might very well be the case. But this ticket is not about line continuation in pre-processor directives. My test were in comments, as is the issue with this ticket. And none of them implementations listed above supports them in comments before a "#version 420" statement (if supported at all).
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.
I'm sorry if this is a bit blunt, but wow. That's one of the least appealing arguments I've heard in a long time. Not only is someone paying you for your time, you think that's a *justification* for not supporting the standard? That's pretty much the oppositte of how this usually works.
So, as a paying customer of Intel, where would I file a bug-report that Intel will deal with in a responsible way?
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.
Fair enough. At least when considered in isolation.