diff options
| author | bors <bors@rust-lang.org> | 2023-12-01 13:33:55 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2023-12-01 13:33:55 +0000 |
| commit | 63d16b5a98abc5e6c73f832ef85bd2415588f699 (patch) | |
| tree | 518ca74940b7d21162026f8c21d6a670813aae25 /compiler/rustc_builtin_macros/src/concat_bytes.rs | |
| parent | caf730043232affb6b10d1393895998cb4968520 (diff) | |
| parent | 0f41bc21b958fed66b3d055531af67638390f520 (diff) | |
| download | rust-63d16b5a98abc5e6c73f832ef85bd2415588f699.tar.gz rust-63d16b5a98abc5e6c73f832ef85bd2415588f699.zip | |
Auto merge of #117472 - jmillikin:stable-c-str-literals, r=Nilstrieb
Stabilize C string literals RFC: https://rust-lang.github.io/rfcs/3348-c-str-literal.html Tracking issue: https://github.com/rust-lang/rust/issues/105723 Documentation PR (reference manual): https://github.com/rust-lang/reference/pull/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 https://github.com/rust-lang/rust/pull/108801, which was reverted due to unintentional changes to lexer behavior in Rust editions < 2021. The current implementation landed in PR https://github.com/rust-lang/rust/pull/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.
Diffstat (limited to 'compiler/rustc_builtin_macros/src/concat_bytes.rs')
| -rw-r--r-- | compiler/rustc_builtin_macros/src/concat_bytes.rs | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/compiler/rustc_builtin_macros/src/concat_bytes.rs b/compiler/rustc_builtin_macros/src/concat_bytes.rs index 5499852e177..96e9584c209 100644 --- a/compiler/rustc_builtin_macros/src/concat_bytes.rs +++ b/compiler/rustc_builtin_macros/src/concat_bytes.rs @@ -19,8 +19,8 @@ fn invalid_type_err( let snippet = cx.sess.source_map().span_to_snippet(span).ok(); match ast::LitKind::from_token_lit(token_lit) { Ok(ast::LitKind::CStr(_, _)) => { - // FIXME(c_str_literals): should concatenation of C string literals - // include the null bytes in the end? + // Avoid ambiguity in handling of terminal `NUL` by refusing to + // concatenate C string literals as bytes. cx.emit_err(errors::ConcatCStrLit { span: span }); } Ok(ast::LitKind::Char(_)) => { |
