Incorrect treatment of consecutive ## operators (compared with GCC).

[mrolle45]

-- EDIT -- Added comment with a different example and a different problem, and another comment with a suggested fix.

When a macro definition has either 'a ## ## c', the result differs from GCC. I'm not sure what the standard requires, though I suspect the answer is same as 'a ## c'. It may depend on the order of evaluation of the ## operators.

Sample input

#define FOO(a, b, c) a ## b ## c, a ## ## c
FOO (x, , y)
FOO (x, 42, y)

Output from gcc -E is

xy, xy
x42y, xy

Output from clang -E is

xy, x ##y
x42y, x ##y

clang also emits an error about pasting 'x##'. It's apparently trying to paste the 'x' to the second '##'. Whereas GCC treats the '## ##' as being separated by a blank value and following the placeholder rules.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (mrolle45)

When a macro definition has either 'a ## ## c', the result differs from GCC. I'm not sure what the standard requires, though I suspect the answer is same as 'a ## c'. It may depend on the order of evaluation of the ## operators.

Sample input

#define FOO(a, b, c) a ## b ## c, a ## ## c
FOO (x, , y)
FOO (x, 42, y)

Output from gcc -E is

xy, xy
x42y, xy

Output from clang -E is

xy, x ##y
x42y, x ##y

clang also emits an error about pasting 'x##'. It's apparently trying to paste the 'x' to the second '##'. Whereas GCC treats the '## ##' as being separated by a blank value and following the placeholder rules.

[zygoloid]

Per https://eel.is/c++draft/cpp#concat-3.sentence-6 it seems to me that the standards-conforming results are x## y or x ##y (both invalid because they form an invalid preprocessing token), not xy.

[chrchr-github]

FYI, MSVC behaves like gcc:

xy, xy
x42y, xy

https://godbolt.org/z/rzT8TP1EM

[shafik]

N4220 says this is ambiguous and proposes to make it ill-formed:

There is no rule against two consecutive paste tokens in the replacement list of a macro. It is ambiguous whether they are both operators, or if one is an operator and the other is an operand, i.e., that something will be concatenated with a ## token. The former interpretation acts the same as a single ## operator, and the latter interpretation usually, but does not always, result in a diagnosis. Such a macro should be treated as ill-formed upon definition.

CC @cor3ntin @tahonermann

Note edg also does the same thing but that is not inconsistent with above arguments: https://godbolt.org/z/1K5W565G7

[zygoloid]

From #116720, one further interesting case:

#define M(x) foo x ## ## ## bar
M()

Here, Clang rejects saying pasting formed 'foo##', an invalid preprocessing token.

I believe what's happening here is that x ## ## produces a ## token, resulting in foo ## ## bar, from where we paste the foo to the ## to form foo## bar. I think that's incorrect -- per [cpp.concat]/3, we should be performing concatenations for

each instance of a ## preprocessing token in the replacement list (not from an argument)

and the ## token here was produced by token paste, not from the replacement list. So if we want to paste left-to-right, I think the correct behavior would be to treat the produced ## as not being a token paste operator. So we should instead form foo ##bar and reject because ##bar isn't a valid preprocessing token.

Of course all of that is moot if this is made ill-formed :)

[zygoloid]

A related fun case:

#define M(x,y) foo x ## ## ## y bar
M(,)

This should become foo placemarker ## ## ## placemarker bar.

• Performing the first concat gives foo ## ## placemarker bar. (As is traditional, I've painted one ## blue to indicate that it shouldn't be expanded again.)
• Performing the next concat gives foo ## bar.
  And we're done: I believe the conforming result is that we produce three tokens.

Actual results:
Clang produces foobar (one token)
GCC and EDG produce foo bar (two tokens)
MSVC produces foo bar (two tokens, but also two spaces)
Circle produces foo ## bar