Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cpp.pre] p1 directive-introducing token is immediately followed by a whitespace #5393

Open
xmh0511 opened this issue Apr 15, 2022 · 3 comments

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Apr 15, 2022

[cpp.pre] p1 says

the first token in the sequence, ..., is

  • [...]
  • an import preprocessing token immediately followed on the same logical line by a header-name, <, identifier, string-literal, or : preprocessing token, or
  • a module preprocessing token immediately followed on the same logical line by an identifier, :, or ; preprocessing token, or
  • an export preprocessing token immediately followed on the same logical line by one of the two preceding forms.

Consider such three cases:

import                             <string>;     
module                                ; 
export                import                    "squee";

Neither of them is immediately followed by the expected preprocessing tokens on the same logic line. In other words, these directive-introducing tokens are immediately followed by whitespaces. I think whitespace should be considered here since [lex.phases] p3 says

The source file is decomposed into preprocessing tokens ([lex.pptoken]) and sequences of whitespace characters (including comments).

Only at phase 7 will these whitespace characters be no longer significant. P7 says

Whitespace characters separating tokens are no longer significant.

In other words, it makes sense that we consider whitespace characters for any phase prior to phase 7. Thus, the intervening whitespace makes the tokens not immediately follow the directive-introducing token. I think [cpp.pre] p1 might be changed to

  • an import preprocessing token, if ignore whitespace containing no new-line characters, immediately followed on the same logical line by a header-name, <, identifier, string-literal, or : preprocessing token, or
  • a module preprocessing token, if ignore whitespace containing no new-line characters, immediately followed on the same logical line by an identifier, :, or ; preprocessing token, or
  • an export preprocessing token, if ignore whitespace containing no new-line characters, immediately followed on the same logical line by one of the two preceding forms.
@frederick-vs-ja
Copy link
Contributor

How about this?

  • an import preprocessing token immediately followed whose immediately following preprocessing token on the same logical line by is a header-name, <, identifier, string-literal, or : preprocessing token, or
  • a module preprocessing token immediately followed whose immediately following preprocessing token on the same logical line by is an identifier, :, or ; preprocessing token, or
  • an export preprocessing token immediately followed whose immediately following preprocessing token sequence on the same logical line by begins with one of the two preceding forms.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Apr 15, 2022

@frederick-vs-ja The suggestion sounds good. I think the third bullet might be changed to

an export preprocessing token whose immediately following preprocessing token on the same logical line is one of the two preceding forms.

This is enough sufficient since we have restricted the preceding two preprocessing tokens with the corresponding requirements to which they shall satisfy. So, it can be naturally construed that the tokens that immediately follow either the import or module that immediately follows export shall also satisfy what is said in the preceding bullets, respectively.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Apr 15, 2022

Also, I think the following sentence should be placed precede to above bullets

The last token in the sequence is the first token within the sequence that is immediately followed by whitespace containing a new-line character.

It makes sense that we should first determine which preprocessing tokens a preprocessing directive consists of. Based on it, we can say what the immediately following preprocessing token should be. I think the complete change might be:

A preprocessing directive consists of a sequence of preprocessing tokens that satisfies the following constraints at the start of translation phase 4:

  • the first token in the sequence, referred to as a directive-introducing token, begins with the first character in the source file (optionally after whitespace containing no new-line characters) or follows whitespace containing at least one new-line character
  • the last token in the sequence is the token within the sequence that is first to be immediately followed by whitespace containing a new-line character
  • the directive-introducing token(i.e. the first token) is one of the following:
  • a # preprocessing token
  • an import preprocessing token whose immediately following preprocessing token on the same logical line is a header-name, <, identifier, string-literal, or : preprocessing token
  • a module preprocessing token immediately followed whose immediately following preprocessing token on the same logical line is an identifier, :, or ; preprocessing token
  • an export preprocessing token whose immediately following preprocessing token on the same logical line is one of the two preceding forms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants