Skip to content

Conversation

@AlisdairM
Copy link
Contributor

This change set addresses a variety of concerns to produce a simpler and clearer specification for line directives. It makes no functional changes, but changes words sufficiently to require a Core review. A motivation behind this PR is to simplify the changes for the proposal to allow line directives before the global module fragment, https://wg21.link/P3868.

The line directive is given its own grammar production that formally states what used to be described in text restrictions and interpretations of the generic sequence of preprocessing tokens.

The other issue to address is that the specification refers to a string-literal that is not present in the grammar. However, the constraints on that string literal are sufficient to replace that quoted s-char-sequence in the grammar production with string-literal.

This change set addresses a variety of concerns to produce
a simpler and clearer specification for line directives.

The first issue to address is that the specification refers
to a _string-literal_ that is not present in the grammar.
Howeer, the constraints on that string literal are sufficient
to replace that quoted _s-char-sequence_ in the grammar
production with _string-literal_.

The line directive itself is given its own grammar production
that formally states what used to be described in text
restrictions and interprettions of the generic sequence of
preprocessing tokens.

Refactoring the grammar as its own production provides a
simpler way for incoming proposals to refer to line
directives, such as https://wg21.link/P3868.
@jensmaurer
Copy link
Member

Remark (not necessarily dispositive): The status quo still has a good match with the C phrasing; this change would kill that correspondence.

Other than that, the funny presentation of the preprocessor grammar in the status quo has at least two useful properties that we would lose with the reformulation:

  • There is no question that # line pp-tokens is a control-line. Once you factor the "of the form" rules into the grammar, the parser would simply reject a parse as a control-line and instead attempt to treat that as a text-line. Which is not desirable.
  • As written in the pull request, the grammar seems woefully ambiguous, because #line 100 matches both of the #line alternatives (100 is a preprocessing-token, indeed).

@AlisdairM
Copy link
Contributor Author

The grammar is disambiguated the same way that we do for #include and #embed but referring to "the first form" and going to the second form only if the first does not match.

The control-line issue is a genuine issue that I missed and should consider more carefully. That should also be a concern for #8249.

@AlisdairM AlisdairM marked this pull request as draft November 3, 2025 07:41
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

Successfully merging this pull request may close these issues.

2 participants