On Wed, Feb 5, 2014 at 1:08 PM, Harald van Dijk <[email protected]> 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
