rust/library/std/src/ffi/c_str.rs, branch perf-tmp

Reformat `use` declarations.

2024-07-28T22:26:52+00:00

The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.

Add std::ffi::c_str modules

2024-02-22T07:09:26+00:00

library: Move `CStr` to libcore, and `CString` to liballoc

2022-04-14T18:53:11+00:00

add CStr::from_bytes_until_nul

2022-03-18T22:46:49+00:00

This adds a member fn that converts a slice into a CStr; it is intended to be safer than from_ptr (which is unsafe and may read out of bounds), and more useful than from_bytes_with_nul (which requires that the caller already know where the nul byte is). feature gate: cstr_from_bytes_until_nul Also add an error type FromBytesUntilNulError for this fn.

Use implicit capture syntax in format_args

2022-03-10T15:23:40+00:00

This updates the standard library's documentation to use the new syntax. The documentation is worthwhile to update as it should be more idiomatic (particularly for features like this, which are nice for users to get acquainted with). The general codebase is likely more hassle than benefit to update: it'll hurt git blame, and generally updates can be done by folks updating the code if (and when) that makes things more readable with the new format. A few places in the compiler and library code are updated (mostly just due to already having been done when this commit was first authored).

Rollup merge of #93979 - SUPERCILEX:debug_check, r=dtolnay

2022-02-19T05:45:30+00:00

Add debug assertions to validate NUL terminator in c strings The `unchecked` variants from the stdlib usually perform the check anyway if debug assertions are on (for example, `unwrap_unchecked`). This PR does the same thing for `CStr` and `CString`, validating the correctness for the NUL byte in debug mode.

Rollup merge of #89869 - kpreid:from-doc, r=yaahc

2022-02-17T05:29:57+00:00

Add documentation to more `From::from` implementations. For users looking at documentation through IDE popups, this gives them relevant information rather than the generic trait documentation wording “Performs the conversion”. For users reading the documentation for a specific type for any reason, this informs them when the conversion may allocate or copy significant memory versus when it is always a move or cheap copy. Notes on specific cases: * The new documentation for `From for T` explains that it is not a conversion at all. * Also documented `impl Into for T where U: From`, the other central blanket implementation of conversion. * The new documentation for construction of maps and sets from arrays of keys mentions the handling of duplicates. Future work could be to do this for *all* code paths that convert an iterable to a map or set. * I did not add documentation to conversions of a specific error type to a more general error type. * I did not add documentation to unstable code. This change was prepared by searching for the text "From<... for" and so may have missed some cases that for whatever reason did not match. I also looked for `Into` impls but did not find any worth documenting by the above criteria.

Add debug asserts to validate NUL terminator in c strings

2022-02-17T02:34:17+00:00

Signed-off-by: Alex Saveau

Auto merge of #87869 - thomcc:skinny-io-error, r=yaahc

2022-02-07T20:32:56+00:00

Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time, but didn't see a good way to do it without having extra allocation. When looking at it yesterday, it was more clear what to do for some reason. This approach avoids any additional allocations, and reduces the size by half (8 bytes, down from 16). AFAICT it doesn't come additional runtime cost, and the compiler seems to do a better job with code using it. Additionally, this `io::Error` has a niche (still), so `io::Result<()>` is *also* 64 bits (8 bytes, down from 16), and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes, down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally, it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it, since one of the fields it stores is a `i32`, so we can't get below that, and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout, and why its implemented the way it is, are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be, but I didn't trim it down that much, since there's a lot of stuff I did deliberately, that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB, and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add`, and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation, so it would follow the safety contract of `core::ptr::{add,sub}`. The other pointer this had to encode is not tagged — or rather, the tagged repr is equivalent to untagged (it's tagged with 0b00, and has >=4b alignment, so we can reuse the bottom bits). And the other variants we encode are just integers, which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs, as my comments are informed by a lot of the UCG work, but it's possible I missed something or got it wrong (even if the implementation is okay, there are parts of the header comment that says things like "We can't do $x" which could be false). --- ### Why So Many Changes? The repr change was mostly internal, but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static`, rather than just the string. This would have been really tedious, but I made a macro that made it much simpler, but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things), so I expect there to be spottiness in CI initially, unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file), whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it, and will do a pass over it again later, sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing, and made it so we `debug_assert!` in cases the decode isn't what we encoded, but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal, especially around error cases, although I have no idea).

rewrite from_bytes_with_nul to match code style in from_vec_with_nul

2022-02-06T19:07:03+00:00

Signed-off-by: Inteon <42113979+inteon@users.noreply.github.com>