r200787 - Fix whitespace handling in empty macro expansions

[Richard Smith]

On Wed, Feb 5, 2014 at 1:08 PM, Harald van Dijk <harald at gigawatt.nl> wrote:

> On 05/02/14 00:42, Richard Smith wrote:
> > Here's an easy test:
> >
> > #define foo() bar() b
> > #define bar()
> > a
> > foo()
> > c
> >
> > This should produce:
> >
> > # 1 "..."
> >
> >
> > a
> >  b
> > c
> >
> > ... but currently produces:
> >
> > #1 "..."
> >
> >
> > a b
> >
> > c
>
> Thanks Richard, I don't know how I managed to miss that.
>
> Setting Token::StartOfLine as mentioned gets this right in the lexer.
> However, even though the b token in the output has both
> Token::StartOfLine and Token::LeadingSpace set,
> PrintPPOutputPPCallbacks::HandleFirstTokOnLine uses the column number to
> determine whether to print spaces, not the flag. As a result, the output
> becomes not
>
> a
>  b
> c
>
> but
>
> a
> b
> c
>
> Given that the lexer behaviour is now right, would it be okay to leave
> this as it is, and only add a test to check that b is on a separate
> line, like attached? (I used first/second/third instead of a/b/c in an
> attempt to get FileCheck to print a better suggestion when the test
> fails, but it neither helps nor hurts.)


I'm not sure whether we have consumers of -E that care about this detail,
but I think this is an unrelated bug. Consider:

#define foo(x) x y
foo()

This also misses the leading space from the output. So:

1) I think your patch is fine as-is, and
2) I think we should fix PrintPreprocessedTokens to correctly handle the
first token on the line having leading space but being expanded from a
token in the first column.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140205/e6d74dde/attachment.html>