Add cstr! macro.

[reitermarkus]

This adds a cstr! macro for easily creating &'static Cstr.

ACP: rust-lang/libs-team#103

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @scottmcm

(rust-highfive has picked a reviewer for you, use r? to override)

[reitermarkus]

cc @oli-obk, since you reviewed #100291.

[klensy]

Making some functions const and adding cstr macro (isn't there already some private macro like that? Feeling like i saw it some time ago) is two independent things, should they be separated into its own PRs?

[reitermarkus]

is two independent things, should they be separated into its own PRs?

Generally yes, but the macro only works if the functions are const. This will have to be rebased anyways once #100291 is merged so might be possible to split it then.

[m-ou-se]

Nominating for lang team discussion, to discuss if we should add something like c"abc" to the language instead of adding a macro to the library.

This would allow the tokenizer to know something is a C string, such that escape sequences like \0 can be an error, and we can allow invalid unicode like \x80.

[est31]

Such checking can also happen in a proc macro, if the tokenizer is made tolerant of invalid characters, and the "valid unicode" check is turned into a post-parsing error. I'm one of the fans of rust-lang/rfcs#3267 :). Any capability built into the language is one that libraries can't customize.

[scottmcm]

I'd still like to get inferred-type literals, since we want it for all kinds of things (like takes_nonzero(2)), so at that point we'd also be able to have takes_cstr(b"asdf") that would also do the checking, same as how takes_nonzero(0) would do checking to fail at compile-time.

[Mark-Simulacrum]

IMO, it feels pretty weird for us to have a macro here rather than just have CStr::from_bytes_with_nul(b"testing\0").unwrap() as the way to do this in const contexts. If that name is too long for specific cases people can wrap that function with const fn c(s: &str) -> &CStr in the particular context.

There's probably missing const features (e.g., you can't insert the \0 to a 'static "compile time" allocation today), and unwrap() IIRC doesn't quite work, but it seems like those are generally "on the roadmap", to my knowledge. (And at least IMO writing \0 at the end isn't terrible).

[est31]

I've grepped the compiler for usages of the cstr! macro from the cstr crate, and could only find 10 usages. I've originally thought it would be more.

Looking over all of the ecosystem, it seems that the macro is used in "only" 224 files: https://grep.app/search?q=cstr%21&filter[lang][0]=Rust

[lopopolo]

As another data point, I previously used the cstr crate in my own code but replaced it with qed::const_cstr_from_str! to avoid depending on a proc macro.

This crate has a similar function qed::const_cstr_from_bytes! to handle byte literals.

The bulk of my work involves oxidizing a C codebase. I would very much like easy and linenoise-free CStr construction in source code, especially in const and static contexts.

[reitermarkus]

The bulk of my work involves oxidizing a C codebase.

This is also my use-case for this macro.

IMO, it feels pretty weird for us to have a macro here rather than just have CStr::from_bytes_with_nul(b"testing\0").unwrap() as the way to do this in const contexts.

CStr::from_bytes_with_nul(b"Hello, world!\0").unwrap() is not really ergonomic to use and also not usable in const contexts yet. Even if it was, when passing e.g. a *const c_char to a function, using const { CStr::from_bytes_with_nul(b"Hello, world!\0").unwrap() }.as_ptr() or defining a constant just to then pass it to a function is even less ergonomic to use.

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting. We are potentially interested in doing this in the future, but we don't expect to do so on a soon enough timeframe to warrant discouraging the libs team from adding this macro. Go ahead and add it if in the libs team's judgement people want it and would use it. We might add a native lang construct later, but the macro can always map to that.

[reitermarkus]

We are potentially interested in doing this in the future

With “this” referring to c"..." syntax?

but we don't expect to do so on a soon enough timeframe to warrant discouraging the libs team from adding this macro.

So is anything still blocking this from being merged now?

[m-ou-se]

We are potentially interested in doing this in the future, but we don't expect to do so on a soon enough

I've opened rust-lang/rfcs#3348 to try make that happen sooner.

This PR adds a bunch of relatively hard to maintain (and hard to optimize) code to the standard library, so I'd very much prefer built in support for C string literals.

[joshtriplett]

Looks like RFC 3348 is going to get accepted; closing this in favor of c"..." string literals.