Linux kernel: supporting `non_ascii_idents`

[ojeda]

Context: For our incoming use of zerocopy and zerocopy-derive in the Linux kernel, I only needed a couple small patches to adapt the crates. It would be nice (but they are not blockers at the moment) if we could have these upstream to simplify upgrades later on.

---

The second most important one is #2880, which may get solved via upstream Rust's issue: rust-lang/rust#151025 (PR: rust-lang/rust#157497). On the kernel side, we will need to work around it until we bump the MSRV, thus likely late 2027, since we follow Debian Stable.

Otherwise, we could instead use another prefix/identifier that is ASCII-only, or perhaps conditionally via a cfg for the Linux kernel and other projects that deny non_ascii_idents.

Please see https://lore.kernel.org/rust-for-linux/20260602172920.30342-16-ojeda@kernel.org/ for the couple lines Linux kernel patch that works around the issue there.

Of course, this may be best merged with the existing issue above.

[Sagartaunk]

I would like to work on this. Based on the usage in try_from_bytes.rs a rename to __z seems safe. Should I submit a PR?
(Still fairly new to contributing and happy to be corrected if I am missing something).

[ojeda]

Up to @joshlf and @jswrenn -- I am not sure if just __z is good enough for upstream zerocopy (I used that in Linux because I did not expect collisions, at least initially, and we control the code base anyway, while they need to care about all potential zerocopy uses out there). I think in the original PR that added the Unicode character they suggested __Zerocopy_.

[joshlf]

Avoiding clashes with other names is one of the justifications here, but the other one is good error messages: these will show up in error messages, and so they need to be as close to the original field name as possible to not be confusing.

Given how small the downstream Linux patch is for this, and given that if we wanted to maintain the "avoiding clashes" thing we'd probably need to do something verbose like __Zerocopy_ that would harm the "good error messages" goal, I'm inclined to just ask Linux to keep the patch for now, especially combined with rust-lang/rust#157497 coming down the pike.

@ojeda if you're okay with just carrying the patch for now, you can go ahead and close this.

[ojeda]

I am out of the loop: does the Unicode one look somehow better in the error messages? Normally I would have expected a verbose one to be clearer.

But either way it is fine for us :) And with the improvement in upstream Rust we will be able to remove this in the next MSRV bump around late 2027 anyway, after Debian Stable releases.

So happy to close this, thanks!