Skip to content

[cpp.line] Address string-literal vs s-char-sequence#8369

Draft
AlisdairM wants to merge 2 commits into
cplusplus:mainfrom
AlisdairM:fix_string_literal_in_line_directive
Draft

[cpp.line] Address string-literal vs s-char-sequence#8369
AlisdairM wants to merge 2 commits into
cplusplus:mainfrom
AlisdairM:fix_string_literal_in_line_directive

Conversation

@AlisdairM

Copy link
Copy Markdown
Contributor

The text of this specification places a restriction on a string-literal that is not present in the grammar, although the grammar is an exact match for a string-literal with that restriction.

The restricted term is also used when specifying the effects of the line directive with a string, so prefer to move string-literal into the grammar rather than strike that paragraph and adjust the specification for its effects.

Added a cross-reference to where character string literal is defined as it may not be obvious to all readers that this is a term of power, even though it is defined as a term and has an index entry.

@AlisdairM AlisdairM changed the title [cpp.line] Address _string-literal_ vs _s-char-sequence_ [cpp.line] Address string-literal vs s-char-sequence Oct 25, 2025
Comment thread source/preprocessor.tex Outdated
A preprocessing directive of the form
\begin{ncsimplebnf}
\terminal{\# line} digit-sequence \terminal{"} \opt{s-char-sequence} \terminal{"} new-line
\terminal{\# line} digit-sequence \terminal{"} \opt{string-literal} \terminal{"} new-line

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No.

First, a string-literal includes the delimiting quotation marks, so this is a bad change.
Second, a string-literal allows for an encoding-prefix or rawness, but the status quo "form" match does not. So, this is a bad change, because it would appear to allow such prefixes (and we don't know what they mean in this context). A reference to "the character string literal" does not establish a suitable constraint.

Yes, p1 talks about a string-literal with zero context, and that's a bug that needs to be fixed, but this intro sentence is at issue, not the rest of the specification without further elaboration. What does C23 say in that area?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The term "character string literal" is a well defined term establishing exactly that restriction, but if you prefer I will tackle this problem from the specification of what to do with the s-char-sequence instead.

My preferred resolution for C++29 would be to introduce character-string-literal as the quoted s-char-sequence in [lex.string], so that a string-literal is an encoding prefix followed by either a character-string-literal or a R raw-string-literal. That would allow us to use character-string-literal both here in [cpp.line] and [cpp.stringize], and potentially clean up other parts of the standard jumping around string literal syntax --- but that is more than I want to push into ballot review time, as that would clearly need Core review, better spent elsewhere.

@jensmaurer

Copy link
Copy Markdown
Member

CWG2693 is related.

@jensmaurer

jensmaurer commented Oct 25, 2025

Copy link
Copy Markdown
Member

And see CWG3076 for the introduction of plain-string-literal (with no prefix), which might be useful here.

But that's not editorial territory; there is too much subtlety to go wrong.

@AlisdairM

Copy link
Copy Markdown
Contributor Author

I have pushed a revision with the basis of my broader update, and will turn this into a draft PR. I suspect that my update will be in the direction of plain-string-literal but I think you cited the wrong core issue?

Noted that the direction specifically for #line to move in the direction of header-name does seem more appropriate.

I will leave this now as potential C++29 material.

@AlisdairM AlisdairM marked this pull request as draft October 25, 2025 18:38
@AlisdairM AlisdairM force-pushed the fix_string_literal_in_line_directive branch from 104160f to d74f45a Compare October 25, 2025 18:45
The text of this specification places a restriction on a string-literal
that is not present in the grammar, although the grammar is an exact
match for a string-literal with that restriction.

The restricted term is also used when specifying the effects of the
line directive with a string, so prefer to move string-literal into
the grammar rather than strike that paragraph and adjust the effects.

Added a cross-reference to where character string literal is defined
as it may not be obvious to all readers that this is a term of power,
even though it is defined as a term and has an index entry.
…terals

There are several places in the grammar where we want to refer to a
plain character string literal without a prefix and that is not raw.
Introduce _character-string_ into the grammar to replace a quoted
_s-char-sequence_ in a number of places, and move the `R` of a raw
string literal into the _raw-string_ grammar so that _raw-string_
and _character-string_ are used consistently where they appear.
@AlisdairM AlisdairM force-pushed the fix_string_literal_in_line_directive branch from d74f45a to 51c4357 Compare December 8, 2025 12:26
@wg21bot wg21bot added the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Apr 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs rebase The pull request needs a git rebase to resolve merge conflicts.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants