[Mesa-dev] [PATCH 3/5] glcpp: Allow arithmetic integer expressions in #line

[Antía Puentes]

First, sorry for the late answer, I somehow missed your replies (I was
not in CC).

On mar, 2015-06-09 at 10:59 -0700, Ian Romanick wrote:
> On 06/09/2015 10:40 AM, Carl Worth wrote:
> > On Tue, Jun 09 2015, Ian Romanick wrote:
> >>> From section 3.4 ("Preprocessor") of the GLSL ES 3.00 specification:
> >>> "#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 integral
> >>> expressions."
> > ...
> >>> From section 4.3.3 ("Constant Expressions") of the same specification:
> >>> "A constant integral expression is a constant expression that evaluates
> >>> to a scalar signed or unsigned integer."
> > 
> > Yes. That's an extremely unfortunate piece of the specification.
> > 
> > This, together with unary operators introduces inherent ambiguity into
> > the grammar. Just think about things like:

I forgot to mention in the patch's commit message that, because of the
ambiguity of the grammar, I made the assumption that one (or more
blanks) that are not part of an expression between parentheses, act as
parameter separators. Then, for the examples mentioned in the thread the
output would be:

#line 2-1+5 -> #line 6
#line 2 -1+5 -> #line 2 4
#line 2-1 +5 -> #line 1 5
#line 2-1+5 3 -> #line 6 3
#line 2 -1+5 3 -> compilation  error
#line 2-1 +5 3 -> compilation error

#line 3 +3 -> #line 3 3
#line 3 (+3) -> #line 3 3

And for the parentheses the behavior is:

#line (2  -1)+5 -> #line 6
#line 3 (4+1)-1 -> #line 3 4
#line (3) ((4+1) -1) -> #line 3 4
#line 3 (4+1) -1 -> compilation error

> The spec was supposed to get updated to say that parsing is greedy, so
> we at least know what those should do.  I say "supposed to" instead of
> "was" because I don't know for sure that it was updated.

I am afraid that greedy parsing is not what this patch implements, as
#line 3 +3 4 will not be evaluated as #line 6 4, but will raise an error
instead.

> > But I'll also take a look at this patch. Thanks for bringing it to my
> > attention, Ian.