about summary refs log tree commit diff
path: root/library/std
AgeCommit message (Collapse)AuthorLines
2024-04-23Rollup merge of #124266 - RalfJung:no-answer, r=joboetMatthias Krüger-8/+1
remove an unused type from the reentrant lock tests At least it seems unused. This was added back in 45aa6c8d1bc2f7863c92da6643de4642bb2d83bf together with a test related to poisoning; when the test got removed, it seems like it was forgotten to also remove this type.
2024-04-22remove an unused type from the reentrant lock testsRalf Jung-8/+1
2024-04-22export assert_unsafe_precondition macro for std-internal useThe 8472-0/+1
2024-04-22Stabilize generic `NonZero`.Markus Reiter-3/+4
2024-04-21Rollup merge of #124089 - ↵Guillaume Gomez-38/+66
simlay:fix-preadv64-and-pwritev64-link-for-watchos-and-visionos, r=workingjubilee Fix watchOS and visionOS for pread64 and pwrite64 calls In #122880, links to `preadv64` and `pwritev64` were added for `watchOS` however the underlying [`weak!` macro did not include `target_os = "watchos"`](https://github.com/rust-lang/rust/blob/c45dee5efd0c042e9d1e24559ebd0d6424d8aa70/library/std/src/sys/pal/unix/weak.rs#L30-L74). This resulted in an `xcodebuild` error when targeting `watchOS`: ``` Undefined symbols for architecture arm64: "_preadv64", referenced from: __rust_extern_with_linkage_preadv64 in libliveview_native_core.a[274](std-324fdd8d31e8eaa2.std.e18cf7e8d0336778-cgu.08.rcgu.o) "_pwritev64", referenced from: __rust_extern_with_linkage_pwritev64 in libliveview_native_core.a[274](std-324fdd8d31e8eaa2.std.e18cf7e8d0336778-cgu.08.rcgu.o) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` So I added them. I also went ahead and added the same for visionOS because it's bound to create the same issue.
2024-04-21Fix watchOS and visionOS for pread64 and pwrite64 callsSebastian Imlay-38/+66
* Refactor apple OSs to use pwritev and preadv rather pwritev64 and preadv64 * Updated the comments for preadv and pwritev
2024-04-20Abort a process when FD ownership is violatedThe 8472-1/+35
When an EBADF happens then something else already touched an FD in ways it is not allowed to. At that point things can already be arbitrarily bad, e.g. clobbered mmaps. Recovery is not possible. All we can do is hasten the fire.
2024-04-20Rollup merge of #124103 - dtolnay:metadatadebug, r=Mark-Simulacrum许杰友 Jieyou Xu (Joe)-10/+26
Improve std::fs::Metadata Debug representation - Remove duplication of `mode` between `file_type` and `permissions`, which both involve operating on the same mode_t integer - Add `is_symlink` - Add `len` in bytes - Remove Ok wrapping around `modified`, `accessed`, `created`, which eliminates 6 useless lines <table> <tr><th>Before</th><th>After</th></tr> <tr><td> ```console Metadata { file_type: FileType( FileType { mode: 0o100600 (-rw-------), }, ), is_dir: false, is_file: true, permissions: Permissions( FilePermissions { mode: 0o100600 (-rw-------), }, ), modified: Ok( SystemTime { tv_sec: 1713402981, tv_nsec: 682983531, }, ), accessed: Ok( SystemTime { tv_sec: 1713402983, tv_nsec: 206999623, }, ), created: Ok( SystemTime { tv_sec: 1713402981, tv_nsec: 682983531, }, ), .. } ``` </td><td> ```console Metadata { file_type: FileType { is_file: true, is_dir: false, is_symlink: false, .. }, permissions: Permissions( FilePermissions { mode: 0o100600 (-rw-------), }, ), len: 2096, modified: SystemTime { tv_sec: 1713402981, tv_nsec: 682983531, }, accessed: SystemTime { tv_sec: 1713402983, tv_nsec: 206999623, }, created: SystemTime { tv_sec: 1713402981, tv_nsec: 682983531, }, .. } ``` </td></tr></table> Generated by: ```rust fn main() { println!("{:#?}", std::fs::metadata("Cargo.toml").unwrap()); } ```
2024-04-20Rollup merge of #123967 - RalfJung:static_mut_refs, r=Nilstrieb许杰友 Jieyou Xu (Joe)-3/+2
static_mut_refs: use raw pointers to remove the remaining FIXME Using `SyncUnsafeCell` would not make a lot of sense IMO.
2024-04-18Rollup merge of #124116 - RalfJung:miri-rust-backtrace, r=NilstriebJubilee-0/+7
when suggesting RUST_BACKTRACE=1, add a special note for Miri's env var isolation Fixes https://github.com/rust-lang/miri/issues/2855
2024-04-18Rollup merge of #124019 - ChrisDenton:futex-raw-dylib, r=joboetJubilee-1/+13
Use raw-dylib for Windows synchronization functions Fixes #123999 by using the raw-dylib feature to specify the DLL to load the Windows futex functions from (e.g. [`WaitOnAddress`](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress)). This avoids reliance on the import library causing that issue. With apologies to ``@bjorn3,`` as it's currently necessary to revert this for cranelift.
2024-04-18Auto merge of #123144 - dpaoliello:arm64eclib, ↵bors-21/+23
r=GuillaumeGomez,ChrisDenton,wesleywiser Add support for Arm64EC to the Standard Library Adds the final pieces so that the standard library can be built for arm64ec-pc-windows-msvc (initially added in #119199) * Bumps `windows-sys` to 0.56.0, which adds support for Arm64EC. * Correctly set the `isEC` parameter for LLVM's `writeArchive` function. * Add `#![feature(asm_experimental_arch)]` to library crates where Arm64EC inline assembly is used, as it is currently unstable.
2024-04-18when suggesting RUST_BACKTRACE=1, add a special note for Miri's env var ↵Ralf Jung-0/+7
isolation
2024-04-17Improve std::fs::Metadata Debug representationDavid Tolnay-10/+26
Before: Metadata { file_type: FileType( FileType { mode: 0o100600 (-rw-------), }, ), is_dir: false, is_file: true, permissions: Permissions( FilePermissions { mode: 0o100600 (-rw-------), }, ), modified: Ok( SystemTime { tv_sec: 1713402981, tv_nsec: 682983531, }, ), accessed: Ok( SystemTime { tv_sec: 1713402983, tv_nsec: 206999623, }, ), created: Ok( SystemTime { tv_sec: 1713402981, tv_nsec: 682983531, }, ), .. } After: Metadata { file_type: FileType { is_dir: false, is_file: true, is_symlink: false, .. }, permissions: Permissions( FilePermissions { mode: 0o100600 (-rw-------), }, ), len: 2096, modified: SystemTime { tv_sec: 1713402981, tv_nsec: 682983531, }, accessed: SystemTime { tv_sec: 1713402983, tv_nsec: 206999623, }, created: SystemTime { tv_sec: 1713402981, tv_nsec: 682983531, }, .. }
2024-04-17Rollup merge of #124049 - slanterns:const_io_structs_stabilize, r=jhprattMatthias Krüger-7/+6
Stabilize `const_io_structs` This PR stabilizes `const_io_structs`. Tracking issue: https://github.com/rust-lang/rust/issues/78812. Implementation PR: https://github.com/rust-lang/rust/pull/78811. FCPs already completed in the tracking issue. Closes https://github.com/rust-lang/rust/issues/78812. ```@rustbot``` label: +T-libs-api r? libs-api
2024-04-17Rollup merge of #122201 - coolreader18:doc-clone_from, r=dtolnayMatthias Krüger-2/+14
Document overrides of `clone_from()` in core/std As mentioned in https://github.com/rust-lang/rust/pull/96979#discussion_r1379502413 Specifically, when an override doesn't just forward to an inner type, document the behavior and that it's preferred over simply assigning a clone of source. Also, change instances where the second parameter is "other" to "source". I reused some of the wording over and over for similar impls, but I'm not sure that the wording is actually *good*. Would appreciate feedback about that. Also, now some of these seem to provide pretty specific guarantees about behavior (e.g. will reuse the exact same allocation iff the len is the same), but I was basing it off of the docs for [`Box::clone_from`](https://doc.rust-lang.org/1.75.0/std/boxed/struct.Box.html#method.clone_from-1) - I'm not sure if providing those strong guarantees is actually good or not.
2024-04-18Stablise io_error_downcastJiahao XU-3/+1
Tracking issue #99262
2024-04-17Stabilize `const_io_structs`Slanterns-7/+6
2024-04-16Rollup merge of #123811 - joboet:queue_em_up, r=ChrisDentonGuillaume Gomez-387/+58
Use queue-based `RwLock` on more platforms This switches over Windows 7, SGX and Xous to the queue-based `RwLock` implementation added in #110211, thereby fixing #121949 for Windows 7 and partially resolving #114581 on SGX. TEEOS can't currently be switched because it doesn't have a good thread parking implementation. CC `@roblabla` `@raoulstrackx` `@xobs` Could you help me test this, please? r? `@ChrisDenton` the Windows stuff should be familiar to you
2024-04-16Use raw-dylib for Windows futex APIsChris Denton-1/+13
This is a workaround for older mingw `synchronization` import library not working on at least some system.
2024-04-16std: fix lint on SGXjoboet-2/+5
2024-04-16Rollup merge of #123721 - madsmtm:fix-visionos, r=davidtwcoGuillaume Gomez-12/+1
Various visionOS fixes A few small mistakes was introduced in https://github.com/rust-lang/rust/pull/121419, probably after the rename from `xros` to `visionos`. See the commits for details. CC `@agg23` Since you reviewed https://github.com/rust-lang/rust/pull/121419 r? davidtwco
2024-04-16Update usage note on OpenOptions::append()Hrvoje Niksic-9/+18
Avoid implying that concatenating data before passing it to `write()` (with or without `BufWriter`) ensures atomicity.
2024-04-15Add support for Arm64EC to the Standard LibraryDaniel Paoliello-21/+23
2024-04-15Rollup merge of #123970 - risc0:erik/zkvm-fix-os-str, r=joboetMichael Goulet-2/+4
zkvm: fix references to `os_str` module The `os_str` module has been moved to `sys`. This change fixes build issues by changing `use` to point to `crate::sys::os_str`.
2024-04-15Auto merge of #123968 - jieyouxu:rollup-1pnkxor, r=jieyouxubors-0/+1
Rollup of 12 pull requests Successful merges: - #123423 (Distribute LLVM bitcode linker as a preview component) - #123548 (libtest: also measure time in Miri) - #123666 (Fix some typos in doc) - #123864 (Remove a HACK by instead inferring opaque types during expected/formal type checking) - #123896 (Migrate some diagnostics in `rustc_resolve` to session diagnostic) - #123919 (builtin-derive: tag → discriminant) - #123922 (Remove magic constants when using `base_n`.) - #123931 (Don't leak unnameable types in `-> _` recover) - #123933 (move the LargeAssignments lint logic into its own file) - #123934 (`rustc_data_structures::graph` mini refactor) - #123941 (Fix UB in LLVM FFI when passing zero or >1 bundle) - #123957 (disable create_dir_all_bare test on all(miri, windows)) r? `@ghost` `@rustbot` modify labels: rollup
2024-04-15static_mut_refs: use raw pointers to remove the remaining FIXMERalf Jung-3/+2
2024-04-15zkvm: fix references to `os_str` moduleErik Kaneda-2/+4
The `os_str` module has been moved to `sys`.
2024-04-15Rollup merge of #123957 - RalfJung:create_dir_all_bare, r=joboet许杰友 Jieyou Xu (Joe)-0/+1
disable create_dir_all_bare test on all(miri, windows)
2024-04-15Auto merge of #123937 - RalfJung:miri-link-section, r=oli-obkbors-0/+1
Miri on Windows: run .CRT$XLB linker section on thread-end Hopefully fixes https://github.com/rust-lang/rust/issues/123583 First commit is originally by `@bjorn3` r? `@oli-obk` Cc `@ChrisDenton`
2024-04-15Auto merge of #123851 - NobodyXu:patch-1, r=BurntSushibors-6/+10
Update document for std::io::Error::downcast Resolve concern raised by `@BurntSushi` https://github.com/rust-lang/rust/issues/99262#issuecomment-2042641813
2024-04-15Update doc for std::io::Error::downcastJiahao XU-1/+5
2024-04-15disable create_dir_all_bare on all(miri, windows)Ralf Jung-0/+1
2024-04-15Auto merge of #123928 - tbu-:pr_statx_enosys, r=workingjubileebors-8/+5
`statx` probe: `ENOSYS` might come from a faulty FUSE driver Do the availability check regardless of the error returned from `statx`. CC https://github.com/rust-lang/rust/pull/122079#discussion_r1564761281
2024-04-14Rollup merge of #120900 - marcospb19:std-use-seek-stream-position, ↵Guillaume Gomez-29/+31
r=joshtriplett std: use `stream_position` where applicable by replacing `seek(SeekFrom::Current(0))` calls
2024-04-14Miri: run .CRT$XLB linker section on thread-endRalf Jung-0/+1
2024-04-14`statx` probe: `ENOSYS` might come from a faulty FUSE driverTobias Bucher-8/+5
Do the availability check regardless of the error returned from `statx`. CC https://github.com/rust-lang/rust/pull/122079#discussion_r1564761281
2024-04-14Auto merge of #122268 - ChrisDenton:no-libc, r=Mark-Simulacrumbors-9/+17
Link MSVC default lib in core ## The Problem On Windows MSVC, Rust invokes the linker directly. This means only the objects and libraries Rust explicitly passes to the linker are used. In short, this is equivalent to passing `-nodefaultlibs`, `-nostartfiles`, etc for gnu compilers. To compensate for this [the libc crate links to the necessary libraries](https://github.com/rust-lang/libc/blob/a0f5b4b21391252fe38b2df9310dc65e37b07d9f/src/windows/mod.rs#L258-L261). The libc crate is then linked from std, thus when you use std you get the defaults back.or integrate with C/C++. However, this has a few problems: - For `no_std`, users are left to manually pass the default lib to the linker - Whereas `std` has the opposite problem, using [`/nodefaultlib`](https://learn.microsoft.com/en-us/cpp/build/reference/nodefaultlib-ignore-libraries?view=msvc-170) doesn't work as expected because Rust treats them as normal libs. This is a particular problem when you want to use e.g. the debug CRT libraries in their place or integrate with C/C++.. ## The solution This PR fixes this in two ways: - moves linking the default lib into `core` - passes the lib to the linker using [`/defaultlib`](https://learn.microsoft.com/en-us/cpp/build/reference/defaultlib-specify-default-library?view=msvc-170). This allows users to override it in the normal way (i.e. with [`/nodefaultlib`](https://learn.microsoft.com/en-us/cpp/build/reference/nodefaultlib-ignore-libraries?view=msvc-170)). This is more or less equivalent to what the MSVC C compiler does. You can see what this looks like in my second commit, which I'll reproduce here for convenience: ```rust // In library/core #[cfg(all(windows, target_env = "msvc"))] #[link( name = "/defaultlib:msvcrt", modifiers = "+verbatim", cfg(not(target_feature = "crt-static")) )] #[link(name = "/defaultlib:libcmt", modifiers = "+verbatim", cfg(target_feature = "crt-static"))] extern "C" {} ``` ## Alternatives - Add the above to `unwind` and `std` but not `core` - The status quo - Some other kind of compiler magic maybe This bares some discussion so I've t-libs nominated it.
2024-04-14Replace libc::c_int with core::ffi::c_intChris Denton-9/+17
And remove the libc crate when it isn't needed
2024-04-14Rollup merge of #123879 - beetrees:missing-unsafe, r=Mark-SimulacrumMatthias Krüger-17/+24
Add missing `unsafe` to some internal `std` functions Adds `unsafe` to a few internal functions that have safety requirements but were previously not marked as `unsafe`. Specifically: - `std::sys::pal::unix::thread::min_stack_size` needs to be `unsafe` as `__pthread_get_minstack` might dereference the passed pointer. All callers currently pass a valid initialised `libc::pthread_attr_t`. - `std::thread::Thread::new` (and `new_inner`) need to be `unsafe` as it requires the passed thread name to be valid UTF-8, otherwise `Thread::name` will trigger undefined behaviour. I've taken the opportunity to split out the unnamed thread case into a separate `new_unnamed` function to make the safety requirement clearer. All callers meet the safety requirement now that #123505 has been merged.
2024-04-14Rollup merge of #123779 - semarie:notgull-openbsd-socket, r=Mark-SimulacrumMatthias Krüger-0/+10
OpenBSD fix long socket addresses Original diff from ``@notgull`` in #118349, small changes from me. on OpenBSD, getsockname(2) returns the actual size of the socket address, and not the len of the content. Figure out the length for ourselves. see https://marc.info/?l=openbsd-bugs&m=170105481926736&w=2 Fixes #116523
2024-04-14Rollup merge of #123651 - tgross35:thread-local-updates, r=Mark-SimulacrumMatthias Krüger-28/+32
Thread local updates for idiomatic examples Update thread local examples to make more idiomatic use of `Cell` for `Copy` types, `RefCell` for non-`Copy` types. Also shrink the size of `unsafe` blocks, add `SAFETY` comments, and fix `clippy::redundant_closure_for_method_calls`.
2024-04-13Rollup merge of #123716 - Kriskras99:patch-2, r=Mark-SimulacrumMatthias Krüger-6/+5
Update documentation of Path::to_path_buf and Path::ancestors `Path::to_path_buf` > Changes the example from using the qualified path of PathBuf with an import. This is what's done in all other Path/PathBuf examples and makes the code look a bit cleaner. `Path::ancestors` > If you take a quick glance at the documentation for Path::ancestors, the unwraps take the natural focus. Potentially indicating that ancestors might panic. In the reworked version I've also moved the link with parent returning None and that the iterator will always yield &self to before the yield examples. Feel free to cherry-pick the changes you like.
2024-04-13Rollup merge of #123868 - eduardosm:stabilize-slice_ptr_len, r=jhprattJacob Pratt-1/+0
Stabilize (const_)slice_ptr_len and (const_)slice_ptr_is_empty_nonnull Stabilized API: ```rust impl<T> *mut [T] { pub const fn len(self) -> usize; pub const fn is_empty(self) -> bool; } impl<T> *const [T] { pub const fn len(self) -> usize; pub const fn is_empty(self) -> bool; } impl<T> NonNull<[T]> { pub const fn is_empty(self) -> bool; } ``` FCP completed in tracking issue: https://github.com/rust-lang/rust/issues/71146
2024-04-13Add missing `unsafe` to internal `std::thread::Thread` creation functionsbeetrees-14/+21
2024-04-13Add missing `unsafe` to internal function ↵beetrees-3/+3
`std::sys::pal::unix::thread::min_stack_size`
2024-04-12Rollup merge of #123867 - eduardosm:unsafe-fns, r=ChrisDentonMatthias Krüger-12/+14
Add `unsafe` to two functions with safety invariants
2024-04-12Rollup merge of #123858 - marijanp:fix-zkvm-cmath-path, r=joboetMatthias Krüger-2/+0
zkvm: fix path to cmath in zkvm module I don't know why the original author decided to use relative paths. I think it would be better to use `use crate::sys::cmath;` The according issue can be found here https://github.com/risc0/risc0/issues/1647
2024-04-12Rollup merge of #123857 - devnexen:tcp_listener_update_backlog, r=ChrisDentonMatthias Krüger-0/+4
std::net: TcpListener shrinks the backlog argument to 32 for Haiku.
2024-04-12Rollup merge of #123807 - joboet:sys_common_thread, r=jhprattMatthias Krüger-24/+22
Remove `sys_common::thread` Part of #117276. The stack size calculation isn't system-specific at all and can just live together with the rest of the spawn logic.