[Mesa-dev] [PATCH 07/23] glsl/glcpp: Stop using a lexer start condition (<SKIP>) for token skipping.

Jordan Justen jljusten at gmail.com
Mon Jul 28 14:13:11 PDT 2014


On Mon, Jul 28, 2014 at 11:33 AM, Carl Worth <cworth at cworth.org> wrote:
> Jordan Justen <jljusten at gmail.com> writes:
>> It looks like parser->last_token_was_newline will not be updated while
>> skipping. Should we update that during the skipping even though we're
>> not returning tokens?
>
> Thanks for the careful review, Jordan.
>
> While it would be more accurate to do that, I don't think it's worth the
> extra code complexity, (that some state would be updated when skipping
> while some would not).
>
> And the side-effect from not being strictly accurate here is easy to
> ignore. We're talking about EOF occurring while skipping, which is an
> "unterminated #if" error that will be caught regardless. The only
> effect of this state is whether the lexer correctly knows whether that
> EOF occurred with or without a final newline, (and if it gets it wrong,
> all it will do is emit an extra final newline).

Ok. I figured it might just be a matter of updating the macros, but I
do see some paths that will no longer use the macros when skipping.

> I'll go ahead and add tests for EOF occurring within an "#if 0" and
> within an "#if 1". (I just checked each of these and both work as they
> should.)
>
>>> +#define RETURN_STRING_TOKEN(token)                                     \
>>> +       do {                                                            \
>>> +               if (! parser->skipping) {                               \
>>> +                       yylval->str = ralloc_strdup (yyextra, yytext);  \
>>> +                       RETURN_TOKEN (token);                           \
>>
>> I guess this could use RETURN_TOKEN_NEVER_SKIP.
>
> Sure. I'll do that.
>
> Let me know if you'll offer a Reviewed-by given the explanation above.

Yeah, you can add my r-b.

Thanks,

-Jordan


More information about the mesa-dev mailing list