CWG3177 [lex.pptoken] *header-name* formation rule is defined in terms of itself

[zygoloid]

Reference (section label): [lex.pptoken], [cpp.pre]

Issue description:

[lex.pptoken]/5.4.2.1 is supposed to indicate when we form a header-name token, and says we only do so "immediately after the include, embed, or import preprocessing token in a #include ([cpp.include]), #embed ([cpp.embed]), or import ([cpp.import]) directive"

But [cpp.pre]/2.2 says when we are processing an import directive, and that that happens only when we encounter "an import preprocessing token immediately followed on the same logical source line by a header-name, <, identifier, or : preprocessing token"

So, given:

import <foo>;

... we form a header-name token if we're processing an import directive, and we're processing an import directive if we form a header-name token. This rule lacks foundation.

We first got the [lex.pptoken] side of this from P1703R1. We then got the [cpp.pre] side of this from P1857R3. The author of P1857R3 has indicated the intent was that we form a header-name token if possible in a context where we could form an import directive.

Also, the wording uses the term "immediately after" and "immediately following" without definition, and the intended definition is not the obvious one -- we don't mean "with no intervening characters" and we don't mean "as the very next preprocessing token", we actually mean "as the very next preprocessing token and on the same logical source line".

Suggested resolution:

Change in [lex.pptoken]/5.4:

Otherwise, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token, even if that would cause further lexical analysis to fail, except that

• (5.4.1) a string-literal token is never formed when a header-name token can be formed, and
• (5.4.2) a header-name ([lex.header]) is only formed
  • (5.4.2.1) immediately after the include, or embed, or import preprocessing token in a #include ([cpp.include]), or #embed ([cpp.embed]), or import ([cpp.import]) directive, respectively, or
  • (5.4.2.1+) immediately after an import preprocessing token that is at the start of a logical source line, or
  • (5.4.2.2) immediately after a preprocessing token sequence of __has_include or __has_embed immediately followed by ( in a #if, #elif, or #embed directive ([cpp.cond], [cpp.embed]).
    A preprocessing token is considered to be immediately after another preprocessing token if the tokens are on the same logical source line and there are no intervening preprocessing tokens.

It might also be worth investigating whether the wording in [cpp.pre] can be cleaned up by making more use of "logical source line" terminology in place of talking about whitespace not containing a newline character, since they're different ways of saying the same thing and we currently use a mixture of the two approaches. (It's also surprising that a /* \n */ comment is considered to be whitespace that does not contain a newline character for these purposes!)

[jensmaurer]

CWG3177