about summary refs log tree commit diff
path: root/compiler/rustc_builtin_macros/src/concat_bytes.rs
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2023-12-01 13:33:55 +0000
committerbors <bors@rust-lang.org>2023-12-01 13:33:55 +0000
commit63d16b5a98abc5e6c73f832ef85bd2415588f699 (patch)
tree518ca74940b7d21162026f8c21d6a670813aae25 /compiler/rustc_builtin_macros/src/concat_bytes.rs
parentcaf730043232affb6b10d1393895998cb4968520 (diff)
parent0f41bc21b958fed66b3d055531af67638390f520 (diff)
downloadrust-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.rs4
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(_)) => {