Stabilize C string literals

[jmillikin]

RFC: https://rust-lang.github.io/rfcs/3348-c-str-literal.html

Tracking issue: #105723

Documentation PR (reference manual): rust-lang/reference#1423

Stabilization report

Stabilizes C string and raw C string literals (c"..." and cr#"..."#), which are expressions of type &CStr. Both new literals require Rust edition 2021 or later.

const HELLO: &core::ffi::CStr = c"Hello, world!";

C strings may contain any byte other than NUL (b'\x00'), and their in-memory representation is guaranteed to end with NUL.

Implementation

Originally implemented by PR #108801, which was reverted due to unintentional changes to lexer behavior in Rust editions < 2021.

The current implementation landed in PR #113476, which restricts C string literals to Rust edition >= 2021.

Resolutions to open questions from the RFC

• Adding C character literals (c'.') of type c_char is not part of this feature.
  • Support for c"..." literals does not prevent c'.' literals from being added in the future.
• C string literals should not be blocked on making &CStr a thin pointer.
  • It's possible to declare constant expressions of type &'static CStr in stable Rust (as of v1.59), so C string literals are not adding additional coupling on the internal representation of CStr.
• The unstable concat_bytes! macro should not accept c"..." literals.
  • C strings have two equally valid &[u8] representations (with or without terminal NUL), so allowing them to be used in concat_bytes! would be ambiguous.
• Adding a type to represent C strings containing valid UTF-8 is not part of this feature.
  • Support for a hypothetical &Utf8CStr may be explored in the future, should such a type be added to Rust.

[rustbot]

r? @TaKO8Ki

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[jmillikin]

See comment #105723 (comment) regarding stabilization timeline -- I'm hoping this might pass FCP in time for v1.76, but acknowledge it might need to wait until the implementation has soaked a bit more.

[tgross35]

@rustbot label +T-lang +needs-fcp
r? lang

[compiler-errors]

I think this PR needs a stabilization report -- this PR seems pretty bare.

Specifically, things that come to mind are: should mention the implementation history, how C str literals work in the lexer/parser, any outstanding questions about the implementation, the extent to which the feature has been tested, etc. Are there reference changes to be made here?

[ehuss]

Can you please post a PR to https://github.com/rust-lang/reference/ to update the documentation for this feature?

[jmillikin]

Added a brief stability report to document decisions for each of the RFC's open questions.

PR for the reference manual: rust-lang/reference#1423

[jmillikin]

Gentle ping -- the documentation PR seems to be making progress, but it can't pass on CI until c_str_literals stabilizes.

Is there anything else blocking the stabilization, or can the FCP be started now?

[tgross35]

The I-lang-nominated label means it's a topic of discussion for an upcoming lang team meeting. It can take a few weeks to hear anything, the overall stabilization process (general discussion, team discussion, FCP proposal, FCP) is usually at least a month or so

[Property404]

FYI for people looking at this PR, I believe it's getting reverted here: #119528

[SUPERCILEX]

Dang, bummer. The gist is that NUL byte validation is being moved up to lexing (I think?) and then it'll try to be stabilized again.

[wesleywiser]

Adjusting milestone to 1.77 to account for the revert in 1.76.

[eduardosm]

I opened #119865 to bump version in compiler/rustc_feature/src/accepted.rs