Convert struct FromBytesWithNulError into enum

[nyurik]

This PR renames the former kind enum from FromBytesWithNulErrorKind to FromBytesWithNulError, and removes the original struct.

See rust-lang/libs-team#493

Possible Changes - TBD

• should the new enum FromBytesWithNulError derive Copy?
• should there be any new/changed attributes?
• add some more tests

Problem

One of CStr constructors, CStr::from_bytes_with_nul(bytes: &[u8]) handles 3 cases:

1. bytes has one NULL as the last value - creates CStr
2. bytes has no NULL - error
3. bytes has a NULL in some other position - error

The 3rd case is error that may require lossy conversion, but the 2nd case can easily be handled by the user code. Unfortunately, this function returns an opaque FromBytesWithNulError error in both 2nd and 3rd case, so the user cannot detect just the 2nd case - having to re-implement the entire function and bring in the memchr dependency.

Motivating examples or use cases

In this code, my FFI code needs to copy user's &[u8] into a C-allocated memory blob in a NUL-terminated CStr format. My code must first validate if &[u8] has a trailing NUL (case 1), no NUL (adds one on the fly - case 2), or NUL in the middle (3rd case - error). I had to re-implement from_bytes_with_nul and add memchrdependency just to handle the 2nd case.

r? @Amanieu

[nyurik]

@tgross35 I thought this proposal has already passed - see rust-lang/libs-team#493

[tgross35]

The meeting was a preliminary thumbs up, but the actual FCP process still needs to happen for anything that changes stable API.

[nyurik]

@tgross35 thx, any links on anything I need to do? Or is this rust-team internal?

[tgross35]

Nothing internal and nothing for you to do, a lot of rust-lang just slows down around this time of year. Somebody from the libs-api team will need to propose FCP, Amanieu can do that and is already assigned.

[Amanieu]

This is insta-stable since this is turned into a enum which can be matched on, even if (I think) we put the variants under a feature flag.

@rfcbot merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[theemathas]

I believe that this can potentially break existing code, so this needs at the very least a crater run. See rust-lang/rfcs#3753

[tgross35]

@bors try

[bors]

⌛ Trying commit bf4ecec with merge aacf02f...

[bors]

☀️ Try build successful - checks-actions
Build commit: aacf02f (aacf02ff7319d9b9af3fe5e9e1094c2f000a4689)

[tgross35]

I was about to start a crater run but checked for use in the wild first, from a quick search I don't see any cases of the potentially breaking pattern mentioned in the ACP https://github.com/search?q=lang%3Arust+%2FFromBytesWithNulError+%3F%5C%7B+%3F%5C.%5C.%2F&type=code. So the beta crater runs are probably sufficient to cover anything here, unless there are other patterns that also break.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[dtolnay]

Thank you!

[dtolnay]

@bors r+

[bors]

📌 Commit 86b86fa has been approved by dtolnay

It is now in the queue for this repository.

[nyurik]

@rustbot label: +relnotes