Carl Worth <cwo...@cworth.org> writes: > Matt Turner <matts...@gmail.com> writes: >> >> LINE_EXPANDED expression expression NEWLINE > > Yes. Thanks for the catch. I'll expand the testing and follow up with a > new set of patches.
Except that that's totally bogus. We can't parse two adjacent expressions with no intervening separator (assuming whitespace is valid within each <expression>). This looks to me like a bug in the GLSL specification. Real preprocessors for languages like C do not accept expressions for #line, (they do perform macro substitution, but the final result must be an integer constant, not an expression). And that's what is in the C specifications. A deviation to accept an expression here, (together with the replacement of a source-file string, with a source-file number), gives us something unparseable, (or at least under-specified). It feels like something specified without an implementation in hand, (which can lead to problems like this). Ian, I asked in the bug[*] already, but I'll ask again here. Where did this bug report come from? And can we fix the problem by pushing to have the specification updated? If not, (that is, if there are real-world users with non-integer-literal #line directives), then it would be nice to see what those actually are so we could, at the very least, resolve the grammar ambiguity in a direction that will solve the real-world cases. [*] https://bugs.freedesktop.org/show_bug.cgi?id=72273 -- carl.d.wo...@intel.com
pgpON_fEKNxVI.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
