[feature request] Support Cstr literals

[novafacing]

CStr literals (c"Hello, world!") and raw literals (cr"Hello, World!") are supported as of rust-lang/rust#117472 and will be stabilized in ~1month. Would it be possible to add an option to emit this type of literal instead of &'static [u8] for string literals? If it sounds like a good idea, I can try and take a pass at it, it'd be nice for several of my projects.

[Property404]

I think the stabilization is getting reverted, unfortunately:
rust-lang/rust#119528

[novafacing]

A bit unfortunate -- although I think bindgen support will be benefitted by the revert so more features (like proc_macro C string literals in rust-lang/rust#119750) can make it in.

Bindgen support for this I think will be blocked by quote support for CStrs, which is blocked on syn support for them, which is blocked on proc-macro2 support, which is blocked on the issue/PR to proc_macro above. I'm planning on adding support to all of the above, but it'll take some time.

[emilio]

Seems fine to add an experimental feature. See bindgen/features.rs.

[wmmc88]

Looks like it will be re-stabilized in 1.78 on 3/21/24.

How would this interact with the existing generate_cstr option that will "will become enabled by default in a future release"? Would this just change the generated code from using ::core::ffi::CStr::from_bytes_with_nul_unchecked to using the new literal syntax?

[pvdrz]

I agree with @emilio, adding this as a nightly only feature meanwhile makes sense. If this feature is merged before the compiler feature is stabilized we can stabilize this feature and update the generate_cstr option in a single PR.

[teohhanhui]

C-string literals was stabilized in Rust 1.77: https://blog.rust-lang.org/2024/03/21/Rust-1.77.0.html#c-string-literals

[GKFX]

CStr literals don't exactly map to string literals in C, because a string literal may contain an embedded null byte. E.g. "ab\0c" will have to continue to be represented as a byte array.

A feature which automatically represented all strings without an embedded null as CStr and the rest as [u8] could be useful. However it would potentially be problematic/fragile as it would be changing data types based on seemingly irrelevant changes to string contents.