about summary refs log tree commit diff
path: root/library/std/src/ffi
AgeCommit message (Collapse)AuthorLines
2022-04-27Revert "Re-export core::ffi types from std::ffi"Josh Triplett-9/+0
This reverts commit 9aed829fe6cdf5eaf278c6c3972f7acd0830887d. Fixes https://github.com/rust-lang/rust/issues/96435 , a regression in crates doing `use std::ffi::*;` and `use std::os::raw::*;`. We can re-add this re-export once the `core::ffi` types are stable, and thus the `std::os::raw` types can become re-exports as well, which will avoid the conflict. (Type aliases to the same type still conflict, but re-exports of the same type don't.)
2022-04-14library: Use type aliases to make `CStr(ing)` in libcore/liballoc unstableVadim Petrochenkov-4/+14
2022-04-14library: Move `CStr` to libcore, and `CString` to liballocVadim Petrochenkov-1925/+6
2022-03-18add CStr::from_bytes_until_nulEric Seppanen-0/+106
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.
2022-03-10Use implicit capture syntax in format_argsT-O-R-U-S-3/+3
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).
2022-03-02Re-export core::ffi types from std::ffibstrie-0/+9
2022-02-19Rollup merge of #93979 - SUPERCILEX:debug_check, r=dtolnayMatthias Krüger-20/+29
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.
2022-02-17Rollup merge of #89869 - kpreid:from-doc, r=yaahcMatthias Krüger-0/+23
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<T> for T` explains that it is not a conversion at all. * Also documented `impl<T, U> Into<U> for T where U: From<T>`, 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.
2022-02-16Add debug asserts to validate NUL terminator in c stringsAlex Saveau-20/+29
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
2022-02-07Auto merge of #87869 - thomcc:skinny-io-error, r=yaahcbors-1/+1
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<usize>` (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).
2022-02-06rewrite from_bytes_with_nul to match code style in from_vec_with_nulInteon-7/+8
Signed-off-by: Inteon <42113979+inteon@users.noreply.github.com>
2022-02-04Hide Repr details from io::Error, and rework `io::Error::new_const`.Thom Chiovoloni-1/+1
2022-01-20Correct docs in `Arc` and `Rc`.Jakob Degen-4/+8
A number of trait implementations incorrectly claimed to be zero cost.
2022-01-19Rollup merge of #92124 - ↵Matthias Krüger-22/+45
AngelicosPhosphoros:remove_extra_alloc_in_cstring_new_35838, r=Mark-Simulacrum Little improves in CString `new` when creating from slice Old code already contain optimization for cases with `&str` and `&[u8]` args. This commit adds a specialization for `&mut[u8]` too. Also, I added usage of old slice in search for zero bytes instead of new buffer because it produce better code for constant inputs on Windows LTO builds. For other platforms, this wouldn't cause any difference because it calls `libc` anyway. Inlined `_new` method into spec trait to reduce amount of code generated to `CString::new` callers.
2021-12-30Remove needless allocation from example code of OsStringDavid Tolnay-4/+4
2021-12-30Fix some copy/paste hysteresis in OsString try_reserve docsDavid Tolnay-4/+4
It appears `find_max_slow` comes from the BinaryHeap docs, where the try_reserve example is a slow implementation of find_max. It has no relevance to this code in OsString though.
2021-12-29Address commentsXuanwo-6/+6
Signed-off-by: Xuanwo <github@xuanwo.io>
2021-12-29Update library/std/src/ffi/os_str.rsXuanwo-1/+1
Co-authored-by: David Tolnay <dtolnay@gmail.com>
2021-12-28Add try_reserve for OsStringXuanwo-0/+81
Signed-off-by: Xuanwo <github@xuanwo.io>
2021-12-27Little improves in CString `new` when creating from sliceAngelicosPhosphoros-22/+45
Old code already contain optimization for cases with `&str` and `&[u8]` args. This commit adds a specialization for `&mut[u8]` too. Also, I added usage of old slice in search for zero bytes instead of new buffer because it produce better code for Windows on LTO builds. For other platforms, this wouldn't cause any difference because it calls `libc` anyway. Inlined `_new` method into spec trait to reduce amount of code generated to `CString::new` callers.
2021-12-13Stabilize const_cstr_uncheckedKonrad Borowski-1/+1
2021-12-04Add documentation to more `From::from` implementations.Kevin Reid-0/+23
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<T> for T` explains that it is not a conversion at all. * Also documented `impl<T, U> Into<U> for T where U: From<T>`, the other central blanket implementation of conversion. * 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.
2021-12-02Emphasise that an OsStr[ing] is not necessarily a platform stringChris Denton-10/+13
2021-10-31Rollup merge of #90430 - jkugelman:must-use-std-a-through-n, r=joshtriplettMatthias Krüger-0/+5
Add #[must_use] to remaining std functions (A-N) I've run out of compelling reasons to group functions together across crates so I'm just going to go module-by-module. This is half of the remaining items from the `std` crate, from A-N. I added these functions myself. Clippy predictably ignored the `mut` ones, but I don't know why the rest weren't flagged. Check them closely, please? Maybe I overlooked good reasons. ```rust std::backtrace::Backtrace const fn disabled() -> Backtrace; std::backtrace::Backtrace<'a> fn frames(&'a self) -> &'a [BacktraceFrame]; std::collections::hash_map::RawOccupiedEntryMut<'a, K, V> fn key_mut(&mut self) -> &mut K; std::collections::hash_map::RawOccupiedEntryMut<'a, K, V> fn get_mut(&mut self) -> &mut V; std::collections::hash_map::RawOccupiedEntryMut<'a, K, V> fn get_key_value(&mut self) -> (&K, &V); std::collections::hash_map::RawOccupiedEntryMut<'a, K, V> fn get_key_value_mut(&mut self) -> (&mut K, &mut V); std::env fn var_os<K: AsRef<OsStr>>(key: K) -> Option<OsString>; std::env fn split_paths<T: AsRef<OsStr> + ?Sized>(unparsed: &T) -> SplitPaths<'_>; std::io::Error fn get_mut(&mut self) -> Option<&mut (dyn error::Error + Send + Sync + 'static)>; ``` Parent issue: #89692 r? `@joshtriplett`
2021-10-31Rollup merge of #89786 - jkugelman:must-use-len-and-is_empty, r=joshtriplettMatthias Krüger-0/+2
Add #[must_use] to len and is_empty Parent issue: #89692 r? `@joshtriplett`
2021-10-31Rollup merge of #89835 - jkugelman:must-use-expensive-computations, ↵Matthias Krüger-0/+1
r=joshtriplett Add #[must_use] to expensive computations The unifying theme for this commit is weak, admittedly. I put together a list of "expensive" functions when I originally proposed this whole effort, but nobody's cared about that criterion. Still, it's a decent way to bite off a not-too-big chunk of work. Given the grab bag nature of this commit, the messages I used vary quite a bit. I'm open to wording changes. For some reason clippy flagged four `BTreeSet` methods but didn't say boo about equivalent ones on `HashSet`. I stared at them for a while but I can't figure out the difference so I added the `HashSet` ones in. ```rust // Flagged by clippy. alloc::collections::btree_set::BTreeSet<T> fn difference<'a>(&'a self, other: &'a BTreeSet<T>) -> Difference<'a, T>; alloc::collections::btree_set::BTreeSet<T> fn symmetric_difference<'a>(&'a self, other: &'a BTreeSet<T>) -> SymmetricDifference<'a, T> alloc::collections::btree_set::BTreeSet<T> fn intersection<'a>(&'a self, other: &'a BTreeSet<T>) -> Intersection<'a, T>; alloc::collections::btree_set::BTreeSet<T> fn union<'a>(&'a self, other: &'a BTreeSet<T>) -> Union<'a, T>; // Ignored by clippy, but not by me. std::collections::HashSet<T, S> fn difference<'a>(&'a self, other: &'a HashSet<T, S>) -> Difference<'a, T, S>; std::collections::HashSet<T, S> fn symmetric_difference<'a>(&'a self, other: &'a HashSet<T, S>) -> SymmetricDifference<'a, T, S> std::collections::HashSet<T, S> fn intersection<'a>(&'a self, other: &'a HashSet<T, S>) -> Intersection<'a, T, S>; std::collections::HashSet<T, S> fn union<'a>(&'a self, other: &'a HashSet<T, S>) -> Union<'a, T, S>; ``` Parent issue: #89692 r? ```@joshtriplett```
2021-10-30Add #[must_use] to remaining std functions (A-N)John Kugelman-0/+5
2021-10-30Add #[must_use] to len and is_emptyJohn Kugelman-0/+2
2021-10-27Add tracking issue number to const_cstr_uncheckedKonrad Borowski-1/+1
2021-10-22Auto merge of #90007 - xfix:inline-cstr-from-str, r=kennytmbors-0/+1
Inline CStr::from_ptr Inlining this function is valuable, as it allows LLVM to apply `strlen`-specific optimizations without having to enable LTO. For instance, the following function: ```rust pub fn f(p: *const c_char) -> Option<u8> { unsafe { CStr::from_ptr(p) }.to_bytes().get(0).copied() } ``` Looks like this if `CStr::from_ptr` is allowed to be inlined. ```asm before: push rax call qword ptr [rip + std::ffi::c_str::CStr::from_ptr@GOTPCREL] mov rcx, rax cmp rdx, 1 sete dl test rax, rax sete al or al, dl jne .LBB1_2 mov dl, byte ptr [rcx] .LBB1_2: xor al, 1 pop rcx ret after: mov dl, byte ptr [rdi] test dl, dl setne al ret ``` Note that optimization turned this from O(N) to O(1) in terms of performance, as LLVM knows that it doesn't really need to call `strlen` to determine whether a string is empty or not.
2021-10-20fix 'since' version numberNathan Stocks-1/+1
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
2021-10-20stabilize CString::from_vec_with_nul[_unchecked]Nathan Stocks-13/+9
2021-10-18Inline CStr::from_ptrKonrad Borowski-0/+1
2021-10-13Rollup merge of #89794 - jkugelman:must-use-to_value-conversions, r=joshtriplettYuki Okushi-0/+12
Add #[must_use] to to_value conversions `NonNull<T>::cast` snuck in when I wasn't looking. What a scamp! Parent issue: #89692 r? ````@joshtriplett````
2021-10-12Add #[must_use] to expensive computationsJohn Kugelman-0/+1
The unifying theme for this commit is weak, admittedly. I put together a list of "expensive" functions when I originally proposed this whole effort, but nobody's cared about that criterion. Still, it's a decent way to bite off a not-too-big chunk of work. Given the grab bag nature of this commit, the messages I used vary quite a bit.
2021-10-12Rollup merge of #89778 - jkugelman:must-use-as_type-conversions, r=joshtriplettthe8472-0/+6
Add #[must_use] to as_type conversions Clippy missed these: ```rust alloc::string::String fn as_mut_str(&mut self) -> &mut str; core::mem::NonNull<T> unsafe fn as_uninit_mut<'a>(&mut self) -> &'a MaybeUninit<T>; str unsafe fn as_bytes_mut(&mut self) -> &mut [u8]; str fn as_mut_ptr(&mut self) -> *mut u8; ``` Parent issue: #89692 r? ````@joshtriplett````
2021-10-11Add #[must_use] to to_value conversionsJohn Kugelman-0/+12
2021-10-11Add #[must_use] to as_type conversionsJohn Kugelman-0/+6
2021-10-11Rollup merge of #89753 - jkugelman:must-use-from_value-conversions, ↵Guillaume Gomez-0/+5
r=joshtriplett Add #[must_use] to from_value conversions I added two methods to the list myself. Clippy did not flag them because they take `mut` args, but neither modifies their argument. ```rust core::str const unsafe fn from_utf8_unchecked_mut(v: &mut [u8]) -> &mut str; std::ffi::CString unsafe fn from_raw(ptr: *mut c_char) -> CString; ``` I put a custom note on `from_raw`: ```rust #[must_use = "call `drop(from_raw(ptr))` if you intend to drop the `CString`"] pub unsafe fn from_raw(ptr: *mut c_char) -> CString { ``` Parent issue: #89692 r? ``@joshtriplett``
2021-10-11Rollup merge of #89729 - jkugelman:must-use-core-std-constructors, ↵Guillaume Gomez-0/+2
r=joshtriplett Add #[must_use] to core and std constructors Parent issue: #89692 r? ``@joshtriplett``
2021-10-10Add #[must_use] to conversions that move selfJohn Kugelman-1/+8
2021-10-10Add #[must_use] to from_value conversionsJohn Kugelman-0/+5
2021-10-10Add #[must_use] to core and std constructorsJohn Kugelman-0/+2
2021-10-09Add #[must_use] to string/char transformation methodsJohn Kugelman-0/+2
These methods could be misconstrued as modifying their arguments instead of returning new values. Where possible I made the note recommend a method that does mutate in place.
2021-09-28Clarify that `CString::from_vec_unchecked` appends 0 byte.et342-0/+2
2021-09-25Rollup merge of #89216 - r00ster91:bigo, r=dtolnayManish Goregaokar-2/+2
Consistent big O notation This makes the big O time complexity notation in places with markdown support more consistent. Inspired by #89210
2021-09-25Auto merge of #88343 - steffahn:fix_code_spacing, r=jyn514bors-78/+70
Fix spacing of links in inline code. Similar to #80733, but the focus is different. This PR eliminates all occurrences of pieced-together inline code blocks like [`Box`]`<`[`Option`]`<T>>` and replaces them with good-looking ones (using HTML-syntax), like <code>[Box]<[Option]\<T>></code>. As far as I can tell, I should’ve found all of these in the standard library (regex search with `` r"`\]`|`\[`" ``) \[except for in `core::convert` where I’ve noticed other things in the docs that I want to fix in a separate PR]. In particular, unlike #80733, I’ve added almost no new instance of inline code that’s broken up into multiple links (or some link and some link-free part). I also added tooltips (the stuff in quotes for the markdown link listings) in places that caught my eye, but that’s by no means systematic, just opportunistic. [Box]: https://doc.rust-lang.org/std/boxed/struct.Box.html "Box" [`Box`]: https://doc.rust-lang.org/std/boxed/struct.Box.html "Box" [Option]: https://doc.rust-lang.org/std/option/enum.Option.html "Option" [`Option`]: https://doc.rust-lang.org/std/option/enum.Option.html "Option" Context: I got annoyed by repeatedly running into new misformatted inline code while reading the standard library docs. I know that once issue #83997 (and/or related ones) are resolved, these changes become somewhat obsolete, but I fail to notice much progress on that end right now. r? `@jyn514`
2021-09-25Apply 16 commits (squashed)Frank Steffahn-78/+70
---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::fmt ---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::{rc, sync} ---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::string ---------- Fix spacing for links inside code blocks in alloc::vec ---------- Fix spacing for links inside code blocks in core::option ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in core::result ---------- Fix spacing for links inside code blocks in core::{iter::{self, iterator}, stream::stream, poll} ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in std::{fs, path} ---------- Fix spacing for links inside code blocks in std::{collections, time} ---------- Fix spacing for links inside code blocks in and make formatting of `&str`-like types consistent in std::ffi::{c_str, os_str} ---------- Fix spacing for links inside code blocks, and improve link tooltips in std::ffi ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in std::{io::{self, buffered::{bufreader, bufwriter}, cursor, util}, net::{self, addr}} ---------- Fix typo in link to `into` for `OsString` docs ---------- Remove tooltips that will probably become redundant in the future ---------- Apply suggestions from code review Replacing `…std/primitive.reference.html` paths with just `reference` Co-authored-by: Joshua Nelson <github@jyn.dev> ---------- Also replace `…std/primitive.reference.html` paths with just `reference` in `core::pin`
2021-09-24consistent big O notationr00ster91-2/+2
2021-09-15docs(std): add docs for cof_from_cstr implsMichael Howell-0/+3
CC #51430