On 01/29/2014 02:15 PM, Carl Worth wrote:
> Carl Worth writes:
>> Matt Turner 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
Carl Worth writes:
> Matt Turner 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 (as
Matt Turner writes:
>> -| LINE_EXPANDED integer_constant integer_constant NEWLINE {
>> +| LINE_EXPANDED expression integer_constant NEWLINE {
>
> shouldn't this should be
>
> LINE_EXPANDED expression expression NEWLINE
Yes. Thanks for the catch. I'll expand the testing and follow up wit
On Tue, Jan 28, 2014 at 5:56 PM, Carl Worth wrote:
> The GLSL specification explicitly allows for an in integer expression here,
> not just a literal integer. The specification says:
>
> #line must have, after macro substitution, one of the following forms:
>
> #line line
>
The GLSL specification explicitly allows for an in integer expression here,
not just a literal integer. The specification says:
#line must have, after macro substitution, one of the following forms:
#line line
#line line source-string-number
where
