add c_str! macro to create &'static CStr

[davidhewitt]

With Rust 1.77 finally stabilising c"" c-string literals, I've wanted for a little while to be able to make better use of &'static CStr inside PyO3.

This PR proposes a pathway to doing that, by adding a c_str!("foo") macro to create a static c-string safely. With MSRV 1.63 we're able to support this on all versions.

This has the nice effect of moving work from runtime to compile time, because at the moment we have a lot of &str which need to be converted to &CStr using runtime checks. In the future when MSRV passes 1.77 we have a trivial cleanup to swap everything to c"" literals.

The only user-facing changes:

• Add pyo3_ffi::c_str macro (also accessible as pyo3::ffi::c_str).
• The PyCFunction constructors now take &'static CStr where they previously took &'static str.

[mejrs]

I'm a big fan of this :)

[mejrs]

Rather than using TokenStream I'd prefer we make our own type for this and switch to syn::LitCStr when it becomes available.

Then we can also change

pub struct PythonDoc(TokenStream);

to

pub struct LitCStr { .. };
pub struct PythonDoc(LitCStr);

[davidhewitt]

I'm happy to go with that; I might also see how painful it is to use conditional code to emit c"" directly from macros on new enough versions. I think it'd be much more efficient codegen and makes it easier for us to clean up later.

... but maybe in the interest of not blocking the 0.22 release too much, would you be ok if I punt doing this into a follow-up internal refactoring PR?

[mejrs]

Sure 👍

[mejrs]

I'm happy to get rid of this :)

[davidhewitt]

Me too! It felt so awkward before to have to do the dance with &'static str in a bunch of places. In some we created these destructors and in others we made an unsafe requirement of no interior nulls. This end state is much more satisfying.

[Icxolu]

Big 👍 for this from me as well! This is a lot nicer and safer than having to remember to add the \0 and it also gets rid of a lot of casting which is nice to see.

[davidhewitt]

Given the two broadly positive sentiments, I think I'm going to merge this once I get CI passing. It'll make #4254 easier to finish implementing, which I want to complete ASAP with a view to then shipping 0.22.

If there are changes which are wanted (like the PythonDoc changes proposed above) let's put them into follow-up PRs or issues to land after we've shipped and unblocked everyone downstream from 3.13 testing.