[Bug 72273] GLSL preprocessor does not support expressions in #line

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=72273

--- Comment #3 from Carl Worth <cworth at cworth.org> ---
(In reply to comment #0)
> The GLSL spec says (emphasis mine):
> 
>     "#line must have, after macro substitution, one of the following forms:
> 
>         #line line
>         #line line source-string-number
> 
>     where line and source-string-number are constant integer *expressions*."

*Grumble*

That's a deviation from the specification for the preprocessor for C,
where N1256 has two basic forms:

  # line digit-sequence newline
  # line digit-sequence "s-char-sequence-opt" newline

And a third one specified as follows:

  A preprocessing directive of the form

    # line pp-tokens new-line

  (that does not match one of the two previous forms) is permitted. The
  preprocessing tokens after line on the directive are processed just as
  in normal text (each identifier currently defined as a macro name is
  replaced by its replacement list of preprocessing tokens). The directive
  resulting after all replacements shall match one of the two previous forms
  and is then processed as appropriate.

In other words, in C, you can have macro-substitution here, but in the end
you have to have digits and nothing but digits for the line number, (which
is basically what we currently have implemented in Mesa).

Anyway, like I said, it's not hard to change. But I wonder if this deviation
is a GLSL specification bug or is actually intended.

Ian, what prompted the bug report? Are there known shaders in the wild
putting parentheses in #line directives or something?

-Carl

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20140129/9e96793c/attachment.html>