`123_p+1` combined with user defined literal should be ill-formed

[llvmbot]

Bugzilla Link	39969
Version	trunk
OS	All
Reporter	LLVM Bugzilla Contributor
CC	@AaronBallman,@DougGregor,@zygoloid

Extended Description

Given the following code

int  operator"" _p(unsigned long long)
{ return 0; }

int test2()
{
    return 123_p+1;  
}

This should be ill-formed just like the following taken from this Stack Overflow question https://stackoverflow.com/a/53726202/1708801

int  operator"" _e(unsigned long long)
{ return 0; }

int test()
{
    return 0x123_e+1;
}

Where I note due to maximal munch 0x123_e+1 is a pp-token but the same analysis should also apply to 123_p+1 since the grammar for pp-token includes both:

pp-number e sign 
pp-number p sign

[ec04fc15-fa35-46f2-80e1-5d271f2ef708]

Interesting. Try 0x123_p+1 instead -- Clang appears to lex a + after a p only if the literal starts 0x; that was probably done for compatibility reasons when this was a GNU extension in C++.

[AaronBallman]

I'm not sure what bug you're reporting here. Clang accepts the 123_p+1 case in C++<=14 and rejects in C++17, which seems correct, as C++17 introduced the

pp-number p sign

production for pp-number.

Maybe I'm missing something, but Clang seems to accept 123_p+1 in C++17 mode. https://godbolt.org/z/Kvcl5U

[ec04fc15-fa35-46f2-80e1-5d271f2ef708]

I'm not sure what bug you're reporting here. Clang accepts the 123_p+1 case in C++<=14 and rejects in C++17, which seems correct, as C++17 introduced the

  pp-number p sign

production for pp-number.