https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #20 from Michael Matz <matz at suse dot de> --- (In reply to Jan Beulich from comment #19) > (In reply to Michael Matz from comment #14) > > The scrubber removes whitespace between tokens of different classes, but > > retains > > whitespace between token of same class, which sometimes makes it so that > > whitespace in macro invocation does or does not separate arguments, the > > difference visible in e.g.: > > > > invoke 1 2 > > invoke 1 + 2 3 > > But that's the whole issue: This isn't how the scrubber works. I was talking "in principle" and hence imprecisely. > It's not uniformly "different classes" (there's not really a proper concept > of tokens either). Tokens _are_ classes of character-sequences. 'identifier', 'number', 'punctuator', and so on. (Sometimes the class has just one member: e.g. ')'). But you're right that it's not the difference of classes between RHS and LHS that enables white-space removal, but rather if pasting the two strings results in one new token or not. > Boundaries between what may be numbers or identifiers are > different from boundaries between operators and alike. The original > report that I started this effort from was (iirc) something like > > invoke (1) (2) > > where the (pretty obviously) two arguments become just one. Yes, when the removed whitespace doesn't change the parse (i.e. the character sequences now side-by-side don't form a new token), then it can be removed. Except of course, it cannot, because whitespace has semantic meaning as separator later on :-/ I don't have a good solution, I see only hacks (e.g. above: fix _this_ very instance of '(1) (2)' being pasted, to not be anymore, or alternatively to continue pasting them, but handle outermost ')' as additional macro argument separator). :-( Or: accept the fact that '(1) (2)' is a single macro argument, even if surprising. -- You are receiving this mail because: You are on the CC list for the bug.
