Tracking Issue for `c"…"` string literals #105723

tmandry · 2022-12-14T23:19:55Z

CAD97 · 2022-12-15T04:35:43Z

w.r.t.

c'…' character literals

IIRC, C23 accepted N2653, which defines char8_t as a typedef for unsigned char. (C++20's char8_t is a distinct type.)

Assuming I'm correct that N2653 was accepted, it probably makes sense to define Rust's c"…" as being compatible with C's u"…" (char8_t[]) and Rust's c'…' as being compatible with C's u8'…' (char8_t).

To be explicit, this is not intended to argue that c"…"_Rust should be usable as *const c_uchar, just that c"…".as_ptr()_Rust should have the same memory content as u8"…"_C. It may argue for c"…"_Rust requiring UTF-8 well formedness; I do not know whether C's u8"…" allows constructing invalid UTF-8 via escapes.

Note that &CStr's pointer representation uses c_char_Rust, not c_uchar_Rust (which would match char8_t_C). This serves as a counterargument that c strings in Rust should match bare string/character literals in C, which use unqualified char_C, rather than the C17 (u8'…') and C23¹ (u8"…") prefixed literals.

The presence of UTF-8 literals being unsigned char in C may additionally add weak motivation for a UTF-8 CStr type for Rust separate from CStr, which corresponds to the unqualified c_char type.

To be fully accurate to my understanding, C17 added u8"…" literals of type array of char, and C23 changed their type to array of char8_t. Similarly, C17 added u8'…' literals of type unsigned char, and C23 changed their type to char8_t (for no semantic change, as char8_t is a typedef of unsigned char). ↩

ojeda · 2022-12-15T20:09:36Z

Assuming I'm correct that N2653 was accepted

Yeah, char8_t was voted into C23.

It may argue for c"…"Rust requiring UTF-8 well formedness; I do not know whether C's u8"…" allows constructing invalid UTF-8 via escapes.

I think it was possible before, and will still be in C23:

"Any hexadecimal escape sequence or octal escape sequence specified in a u8, u, or U string specifies a single char8_t, char16_t, or char32_t value and may result in the full character sequence not being valid UTF-8, UTF-16, or UTF-32."

dead-claudia · 2022-12-25T13:16:22Z

I do want to note a couple things in the alternatives:

While I like the idea of a FromStringLiteral, error messages would need at least a character offset to be actually useful beyond a mere compile-time panic!. Also, &CStrs are really more like byte string literals, and that offset would have to be a byte offset, not a char offset, too.
If some platforms use a u8 for c_char while others use a i8, you need the c'...' literal to be assignable to c_char regardless of which it is in order to be portable. Allowing it to coerce to either i8 or u8 is probably better than having it exactly what c_char is, though. (Ideally, c_char should've been #[repr(transparent)] struct c_char(pub i8/u8); to force people to differentiate the two, but the time to change to that is long past.)

tmandry · 2023-01-05T01:44:46Z

@CAD97 @dead-claudia Would you be willing to open issues for these points and add the F-c_str_literal label (or tag me and I can add it)? Otherwise they are likely to get lost in the discussion. Tracking issues are meant to serve as a hub to point to other threads, not to be a place for technical discussion themselves.

dead-claudia · 2023-01-05T03:51:32Z

Created #106479 for my first point. The second point's not likely to be relevant before a PR, and there's really not much to discuss there.

tgross35 · 2023-01-19T00:10:07Z

Should we make &CStr a thin pointer before stabilizing this? (If so, how?)

I don't think there would be anything about that change that should block this, it would just have to be updated whenever CStr becomes thin. The change itself is blocked, I think #81513 would solve it, but it is still quite young. Seems like there hasn't been much discussion on the topic recently anyway - #59905 is the only issue I could find, but it's pretty unofficial and stale

…r-errors Implement RFC 3348, `c"foo"` literals RFC: rust-lang/rfcs#3348 Tracking issue: rust-lang#105723

dtolnay · 2023-06-20T03:55:22Z

c"…" literals don't work right in proc macros — #112820.

dtolnay · 2023-07-07T03:43:02Z

I updated the summary comment with recent history.

The implementation of c"…", which first landed in nightly-2023-05-06, has been reverted in nightly-2023-07-07 by Revert the lexing of c"…" string literals #113334
Breakage found in the 1.71-beta crater runs is described in regression: c"..." are experimental #113235
Discussion around a reimplementation is happening in Reimplement the lexing of c"…" string literals with backward compatibility in mind #113333

…ilstrieb Stabilize C string literals RFC: https://rust-lang.github.io/rfcs/3348-c-str-literal.html Tracking issue: rust-lang#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`](https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html). Both new literals require Rust edition 2021 or later. ```rust 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 rust-lang#108801, which was reverted due to unintentional changes to lexer behavior in Rust editions < 2021. The current implementation landed in PR rust-lang#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.

Stabilize C string literals RFC: https://rust-lang.github.io/rfcs/3348-c-str-literal.html Tracking issue: rust-lang/rust#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`](https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html). Both new literals require Rust edition 2021 or later. ```rust 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 rust-lang/rust#108801, which was reverted due to unintentional changes to lexer behavior in Rust editions < 2021. The current implementation landed in PR rust-lang/rust#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.

WaffleLapkin · 2023-12-04T13:46:13Z

Closing this as per the merged stabilization PR: #117472

Stabilize C string literals RFC: https://rust-lang.github.io/rfcs/3348-c-str-literal.html Tracking issue: rust-lang/rust#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`](https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html). Both new literals require Rust edition 2021 or later. ```rust 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 rust-lang/rust#108801, which was reverted due to unintentional changes to lexer behavior in Rust editions < 2021. The current implementation landed in PR rust-lang/rust#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.

GoldsteinE · 2024-01-08T22:02:04Z

Stabilization is reverted in #119528, so probably this should be open again?

traviscross · 2024-01-29T18:15:08Z

@rustbot labels +I-lang-nominated

Nominating to discuss and ensure we're OK with the restabilization that will occur automatically if we take no action.

traviscross · 2024-01-31T17:29:52Z

@rustbot labels -I-lang-nominated

We discussed this in the triage call today and agreed, given that #119172 has landed, that we were happy to see this restabilize in Rust 1.77.

stefson · 2024-02-06T18:08:38Z

Was this fully stabilized for rust-1.77.0_beta? I am failing to bootstrap the beta from the beta tarball with: error[E0658]: c".." literals are experimental

ehuss · 2024-02-06T18:43:41Z

@stefson Yes, it was fully stabilized in 1.77. If you are unable to determine your issue, I would suggest opening a new issue with the exact reproduction steps and commands to run.

I'm going to close this issue as the revert only happened on the old beta branch (1.76), and is on track as stabilized in the new beta branch (1.77).

error[E0658]: `c".."` literals are experimental --> src/bar.rs:61:13 | 61 | c"i3bar-river".into(), | ^^^^^^^^^^^^^^ | = note: see issue #105723 <rust-lang/rust#105723> for more information error[E0658]: `c".."` literals are experimental --> src/wm_info_provider/river.rs:118:33 | 118 | PointerBtn::Left => c"set-focused-tags", | ^^^^^^^^^^^^^^^^^^^ | = note: see issue #105723 <rust-lang/rust#105723> for more information error[E0658]: `c".."` literals are experimental --> src/wm_info_provider/river.rs:119:34 | 119 | PointerBtn::Right => c"toggle-focused-tags", | ^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #105723 <rust-lang/rust#105723> for more information Reported by: pkg-fallout (direct commit to 2024Q1 as 73941e6 is missing on the branch)

Stabilize C string literals RFC: https://rust-lang.github.io/rfcs/3348-c-str-literal.html Tracking issue: rust-lang/rust#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`](https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html). Both new literals require Rust edition 2021 or later. ```rust 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 rust-lang/rust#108801, which was reverted due to unintentional changes to lexer behavior in Rust editions < 2021. The current implementation landed in PR rust-lang/rust#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.

rust-lang/rfcs#3348 rust-lang/rust#105723 rust-lang/rust#117472

Stabilize C string literals RFC: https://rust-lang.github.io/rfcs/3348-c-str-literal.html Tracking issue: rust-lang/rust#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`](https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html). Both new literals require Rust edition 2021 or later. ```rust 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 rust-lang/rust#108801, which was reverted due to unintentional changes to lexer behavior in Rust editions < 2021. The current implementation landed in PR rust-lang/rust#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.

sevctl 0.4.3 was refusing to compile on Ubuntu 22.04 and 24.02 because of some deps. This happened in the Github CI This prevented the build of package and the testing inside the CI Solution: Update sevctl to 0.6.0 Error logs Compiling structopt-derive v0.4.18 error[E0658]: `c".."` literals are experimental --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/kvm-ioctls-0.19.0/src/ioctls/system.rs:99:24 | 99 | let kvm_path = c"/dev/kvm"; | ^^^^^^^^^^^ | = note: see issue #105723 <rust-lang/rust#105723> for more information error[E0658]: `c".."` literals are experimental --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/kvm-ioctls-0.19.0/src/ioctls/system.rs:744:24 | 744 | let kvm_path = c"/dev/kvm"; | ^^^^^^^^^^^ | = note: see issue #105723 <rust-lang/rust#105723> for more information For more information about this error, try `rustc --explain E0658`. The following warnings were emitted during compilation: warning: kvm-ioctls@0.19.0: cargo:rustc-check-cfg requires -Zcheck-cfg flag error: could not compile `kvm-ioctls` (lib) due to 2 previous errors warning: build failed, waiting for other jobs to finish... error: failed to compile `sevctl v0.4.3 (https://github.com/virtee/sevctl.git?rev=c41c9172be013d6f10b9e1d7286fcb021805d5a5#c41c9172)`, intermediate artifacts can be found at `/tmp/cargo-installXhERbT`. To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path. make: *** [Makefile:51: target/bin/sevctl] Error 101 make: *** [Makefile:89: all-podman-ubuntu-2204] Error 2

tmandry mentioned this issue Dec 14, 2022

RFC: c"…" string literals rust-lang/rfcs#3348

Merged

dead-claudia mentioned this issue Jan 5, 2023

C string literals can't just use a trivial conversion from regular string or byte literals #106479

Open

dtolnay mentioned this issue Jan 31, 2023

Preserve c"..." and cr"..." literal tokens dtolnay/syn#1349

Merged

This was referenced Feb 14, 2023

c2rust translate unicode to utf8 but Rust doesn't support immunant/c2rust#762

Closed

(c2rust-analyze) Handle transpiled string literals (b"...\0" as *const u8 as *const libc::c_char) immunant/c2rust#833

Open

fee1-dead self-assigned this Mar 5, 2023

fee1-dead mentioned this issue Mar 6, 2023

Implement RFC 3348, c"foo" literals #108801

Merged

Noratrieb mentioned this issue Apr 29, 2023

Suggestion: CStr literals #75401

Closed

Manishearth added a commit to Manishearth/rust that referenced this issue May 4, 2023

Rollup merge of rust-lang#108801 - fee1-dead-contrib:c-str, r=compile…

7ba3a5a

…r-errors Implement RFC 3348, `c"foo"` literals RFC: rust-lang/rfcs#3348 Tracking issue: rust-lang#105723

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue May 4, 2023

Rollup merge of rust-lang#108801 - fee1-dead-contrib:c-str, r=compile…

7236d10

…r-errors Implement RFC 3348, `c"foo"` literals RFC: rust-lang/rfcs#3348 Tracking issue: rust-lang#105723

Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue May 5, 2023

Rollup merge of rust-lang#108801 - fee1-dead-contrib:c-str, r=compile…

4891f02

…r-errors Implement RFC 3348, `c"foo"` literals RFC: rust-lang/rfcs#3348 Tracking issue: rust-lang#105723

fee1-dead removed their assignment May 18, 2023

flip1995 pushed a commit to flip1995/rust that referenced this issue May 20, 2023

Rollup merge of rust-lang#108801 - fee1-dead-contrib:c-str, r=compile…

a48c735

…r-errors Implement RFC 3348, `c"foo"` literals RFC: rust-lang/rfcs#3348 Tracking issue: rust-lang#105723

dtolnay mentioned this issue Jun 20, 2023

c"…" literals are handled incorrectly by proc_macro::Literal #112820

Closed

TimNN mentioned this issue Jun 24, 2023

Propose code string literals rust-lang/rfcs#3450

Open

This was referenced Jun 24, 2023

Implement c"…" literal parsing dtolnay/proc-macro2#395

Merged

Support parsing c-str literals dtolnay/syn#1475

Merged

WaffleLapkin closed this as completed Dec 4, 2023

novafacing mentioned this issue Jan 7, 2024

proc_macro: Add Literal::c_string constructor #119651

Merged

novafacing mentioned this issue Jan 8, 2024

Tracking Issue for proc_macro_c_str_literals #119750

Closed

4 tasks

dtolnay reopened this Jan 8, 2024

madsmtm mentioned this issue Jan 18, 2024

Use &CStr instead of &str in runtime functions madsmtm/objc2#564

Closed

rustbot added the I-lang-nominated Nominated for discussion during a lang team meeting. label Jan 29, 2024

rustbot removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Jan 31, 2024

xFrednet mentioned this issue Feb 5, 2024

new lint: manual_c_str_literals rust-lang/rust-clippy#11919

Merged

ehuss closed this as completed Feb 6, 2024

Ddystopia mentioned this issue Feb 7, 2024

feature: c string literals have been stabilized in 1.77 tree-sitter/tree-sitter-rust#210

Closed

1 task

rlidwka mentioned this issue Feb 10, 2024

Support 'pub const BAR: &CStr = c"hello world";' mozilla/cbindgen#927

Open

rhysd mentioned this issue Mar 20, 2024

Support C string literals highlight rust-lang/rust.vim#508

Open

chocolate-pie added a commit to chocolate-pie/misskey-slacc that referenced this issue Apr 27, 2024

refactor(darwin): Use c"…" string literals in src/macos.rs

cae9888

rust-lang/rfcs#3348 rust-lang/rust#105723 rust-lang/rust#117472

pawel-twardziak mentioned this issue Sep 25, 2024

Affected: The table of options is not formatted properly nrwl/nx#27893

Closed

4 tasks

gnarlin mentioned this issue Oct 14, 2024

Failed to compile via cargo talwat/lowfi#27

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking Issue for `c"…"` string literals #105723

Tracking Issue for `c"…"` string literals #105723

tmandry commented Dec 14, 2022 •

edited by dtolnay

Loading

CAD97 commented Dec 15, 2022

ojeda commented Dec 15, 2022

dead-claudia commented Dec 25, 2022

tmandry commented Jan 5, 2023

dead-claudia commented Jan 5, 2023

tgross35 commented Jan 19, 2023

dtolnay commented Jun 20, 2023

dtolnay commented Jul 7, 2023

WaffleLapkin commented Dec 4, 2023

GoldsteinE commented Jan 8, 2024 •

edited

Loading

traviscross commented Jan 29, 2024

traviscross commented Jan 31, 2024

stefson commented Feb 6, 2024

ehuss commented Feb 6, 2024

Tracking Issue for c"…" string literals #105723

Tracking Issue for c"…" string literals #105723

Comments

tmandry commented Dec 14, 2022 • edited by dtolnay Loading

Steps / History

Unresolved Questions

CAD97 commented Dec 15, 2022

Footnotes

ojeda commented Dec 15, 2022

dead-claudia commented Dec 25, 2022

tmandry commented Jan 5, 2023

dead-claudia commented Jan 5, 2023

tgross35 commented Jan 19, 2023

dtolnay commented Jun 20, 2023

dtolnay commented Jul 7, 2023

WaffleLapkin commented Dec 4, 2023

GoldsteinE commented Jan 8, 2024 • edited Loading

traviscross commented Jan 29, 2024

traviscross commented Jan 31, 2024

stefson commented Feb 6, 2024

ehuss commented Feb 6, 2024

Tracking Issue for `c"…"` string literals #105723

Tracking Issue for `c"…"` string literals #105723

tmandry commented Dec 14, 2022 •

edited by dtolnay

Loading

GoldsteinE commented Jan 8, 2024 •

edited

Loading