summary refs log tree commit diff
path: root/library/std/src
AgeCommit message (Collapse)AuthorLines
2020-12-08Pin the ReentrantMutexes in sys::io::stdio.Mara Bos-25/+30
The code before this change misused the ReentrantMutexes, by calling init() on them and moving them afterwards. Now that ReentrantMutex requires Pin for init(), this mistake is no longer easy to make.
2020-12-08Return a Pin from SyncOnceCell::get_or_init_pin.Mara Bos-4/+7
2020-12-08Add (internal-only) SyncOnceCell::get_or_init_pin.Mara Bos-0/+52
2020-12-08Update ReentrantMutex tests to use Pin.Mara Bos-15/+21
2020-12-08Use Pin for the 'don't move' requirement of ReentrantMutex.Mara Bos-33/+19
2020-12-08Remove unnecessary import of `crate::marker` in std::sys_common::remutex.Mara Bos-2/+1
It was used for marker::Send, but Send is already in scope.
2020-12-08Fix outdated comment about not needing to flush stderr.Mara Bos-7/+3
2020-12-08[beta] always disable copy_file_range to avoid EOVERFLOW errorsThe8472-1/+1
2020-11-12Auto merge of #78965 - jryans:emscripten-threads-libc, r=kennytmbors-20/+42
Update thread and futex APIs to work with Emscripten This updates the thread and futex APIs in `std` to match the APIs exposed by Emscripten. This allows threads to run on `wasm32-unknown-emscripten` and the thread parker to compile without errors related to the missing `futex` module. To make use of this, Rust code must be compiled with `-C target-feature=atomics` and Emscripten must link with `-pthread`. I have confirmed this works well locally when building multithreaded crates. Attempting to enable `std` thread tests currently fails for seemingly obscure reasons and Emscripten is currently disabled in CI, so further work is needed to have proper test coverage here.
2020-11-12Fix timeout conversionJ. Ryan Stinnett-2/+1
2020-11-12Update thread and futex APIs to work with EmscriptenJ. Ryan Stinnett-20/+43
This updates the thread and futex APIs in `std` to match the APIs exposed by Emscripten. This allows threads to run on `wasm32-unknown-emscripten` and the thread parker to compile without errors related to the missing `futex` module. To make use of this, Rust code must be compiled with `-C target-feature=atomics` and Emscripten must link with `-pthread`. I have confirmed this works well locally when building multithreaded crates. Attempting to enable `std` thread tests currently fails for seemingly obscure reasons and Emscripten is currently disabled in CI, so further work is needed to have proper test coverage here.
2020-11-11Rollup merge of #78216 - workingjubilee:duration-zero, r=m-ou-seJonas Schievink-16/+17
Duration::zero() -> Duration::ZERO In review for #72790, whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In https://github.com/rust-lang/rust/issues/73544#issuecomment-691701670 an invitation was opened to either stabilize the methods or propose a switch to the constant value, supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO, which would be reason enough. ZERO also "makes sense" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method, especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const, which could hurt discoverability of the associated constants overall. Elsewhere in `std`, methods for obtaining a constant value were even deprecated, as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value). Most importantly, ZERO costs less to use. A match supports a const pattern, but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise, while https://github.com/rust-lang/rust/issues/73544#issuecomment-691949373 notes `Duration::zero()` can optimize to a constant value, "can" is not "will". Only const contexts have a strong promise of such. Even without that in mind, the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use, may cost less to optimize, and seems to have more of a community consensus for it, the associated const seems best. r? ```@LukasKalbertodt```
2020-11-10Changed unwrap_or to unwrap_or_else in some places.Nicholas-Baron-1/+1
The discussion seems to have resolved that this lint is a bit "noisy" in that applying it in all places would result in a reduction in readability. A few of the trivial functions (like `Path::new`) are fine to leave outside of closures. The general rule seems to be that anything that is obviously an allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it is a 0-sized allocation.
2020-11-10Add missing newline to error message of the default OOM hookhyd-dev-1/+1
2020-11-09Rollup merge of #78878 - shepmaster:intersecting-ignores, r=Mark-SimulacrumDylan DPC-10/+15
Avoid overlapping cfg attributes when both macOS and aarch64 r? ``@Mark-Simulacrum``
2020-11-09Rollup merge of #78026 - sunfishcode:symlink-hard-link, r=dtolnayDylan DPC-3/+71
Define `fs::hard_link` to not follow symlinks. POSIX leaves it [implementation-defined] whether `link` follows symlinks. In practice, for example, on Linux it does not and on FreeBSD it does. So, switch to `linkat`, so that we can pick a behavior rather than depending on OS defaults. Pick the option to not follow symlinks. This is somewhat arbitrary, but seems the less surprising choice because hard linking is a very low-level feature which requires the source and destination to be on the same mounted filesystem, and following a symbolic link could end up in a different mounted filesystem. [implementation-defined]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/link.html
2020-11-08Avoid overlapping cfg attributes when both macOS and aarch64Jake Goulding-10/+15
2020-11-08Rollup merge of #78852 - camelid:intra-doc-bonanza, r=jyn514Mara Bos-16/+8
Convert a bunch of intra-doc links An intra-doc link bonanza! This was accomplished using a bunch of trial-and-error with sed.
2020-11-08Rollup merge of #78811 - a1phyr:const_io_structs, r=dtolnayMara Bos-7/+28
Make some std::io functions `const` Tracking issue: #78812 Make the following functions `const`: - `io::Cursor::new` - `io::Cursor::get_ref` - `io::Cursor::position` - `io::empty` - `io::repeat` - `io::sink` r? `````@dtolnay`````
2020-11-08Rollup merge of #78572 - de-vri-es:bsd-cloexec, r=m-ou-seMara Bos-6/+38
Use SOCK_CLOEXEC and accept4() on more platforms. This PR enables the use of `SOCK_CLOEXEC` and `accept4` on more platforms. ----- Android uses the linux kernel, so it should also support it. DragonflyBSD introduced them in 4.4 (December 2015): https://www.dragonflybsd.org/release44/ FreeBSD introduced them in 10.0 (January 2014): https://wiki.freebsd.org/AtomicCloseOnExec Illumos introduced them in a commit in April 2013, not sure when it was released. It is quite possible that is has always been in Illumos: https://github.com/illumos/illumos-gate/commit/5dbfd19ad5fcc2b779f40f80fa05c1bd28fd0b4e https://illumos.org/man/3socket/socket https://illumos.org/man/3socket/accept4 NetBSD introduced them in 6.0 (Oktober 2012) and 8.0 (July 2018): https://man.netbsd.org/NetBSD-6.0/socket.2 https://man.netbsd.org/NetBSD-8.0/accept.2 OpenBSD introduced them in 5.7 (May 2015): https://man.openbsd.org/socket https://man.openbsd.org/accept
2020-11-08Rollup merge of #76097 - pickfire:stabilize-spin-loop, r=KodrAusMara Bos-1/+0
Stabilize hint::spin_loop Partially fix #55002, deprecate in another release r? ``````@KodrAus``````
2020-11-07Convert a bunch of intra-doc linksCamelid-16/+8
2020-11-06Add tracking issueBenoît du Garreau-6/+6
2020-11-06Make some std::io functions `const`Benoît du Garreau-7/+28
Includes: - io::Cursor::new - io::Cursor::get_ref - io::Cursor::position - io::empty - io::repeat - io::sink
2020-11-07Rollup merge of #78006 - pitaj:master, r=jyn514Yuki Okushi-3/+5
Use Intra-doc links for std::io::buffered Helps with #75080. I used the implicit link style for intrinsics, as that was what `minnumf32` and others already had. ``@rustbot`` modify labels: T-doc, A-intra-doc-links r? ``@jyn514``
2020-11-07Rollup merge of #74979 - maekawatoshiki:fix, r=Mark-SimulacrumYuki Okushi-0/+2
`#![deny(unsafe_op_in_unsafe_fn)]` in sys/hermit Partial fix of #73904. This encloses ``unsafe`` operations in ``unsafe fn`` in ``sys/hermit``. Some unsafe blocks are not well documented because some system-based functions lack documents.
2020-11-06Stabilize hint::spin_loopIvan Tham-1/+0
Partially fix #55002, deprecate in another release Co-authored-by: Ashley Mannix <kodraus@hey.com> Update stable version for stabilize_spin_loop Co-authored-by: Joshua Nelson <joshua@yottadb.com> Use better example for spinlock As suggested by KodrAus Remove renamed_spin_loop already available in master Fix spin loop example
2020-11-06Disable accept4 on Android.Maarten de Vries-1/+7
2020-11-05document HACKsPeter Jaszkowiak-0/+2
2020-11-05Intra-doc links for std::io::bufferedPeter Jaszkowiak-3/+3
2020-11-05Rollup merge of #78757 - camelid:crate-link-text, r=jyn514Mara Bos-6/+6
Improve and clean up some intra-doc links
2020-11-05Rollup merge of #78716 - est31:array_traits, r=Dylan-DPCMara Bos-6/+3
Array trait impl comment/doc fixes Two small doc/comment fixes regarding trait implementations on arrays.
2020-11-05Rollup merge of #78093 - camelid:as-cleanup, r=jyn514Mara Bos-6/+13
Clean up docs for 'as' keyword
2020-11-04Add missing commaCamelid-1/+1
'Note however,' -> 'Note, however,'
2020-11-04Clean up some intra-doc linksCamelid-5/+5
2020-11-04Clean up docs for 'as' keywordCamelid-6/+13
2020-11-04Move Copy and Clone into the list of traits implemented for all sizesest31-6/+3
2020-11-01Rollup merge of #78602 - RalfJung:raw-ptr-aliasing-issues, r=m-ou-seMara Bos-1/+2
fix various aliasing issues in the standard library This fixes various cases where the standard library either used raw pointers after they were already invalidated by using the original reference again, or created raw pointers for one element of a slice and used it to access neighboring elements.
2020-11-01Rollup merge of #78599 - panstromek:master, r=m-ou-seMara Bos-0/+10
Add note to process::arg[s] that args shouldn't be escaped or quoted This came out of discussion on [forum](https://users.rust-lang.org/t/how-to-get-full-output-from-command/50626), where I recently asked a question and it turned out that the problem was redundant quotation: ```rust Command::new("rg") .arg("\"pattern\"") // this will look for "pattern" with quotes included ``` This is something that has bitten me few times already (in multiple languages actually), so It'd be grateful to have it in the docs, even though it's not sctrictly Rust specific problem. Other users also agreed. This can be really annoying to debug, because in many cases (inluding mine), quotes can be legal part of the argument, so the command doesn't fail, it just behaves unexpectedly. Not everybody (including me) knows that quotes around arguments are part of the shell and not part of the called program. Coincidentally, somoene had the same problem [yesterday](https://www.reddit.com/r/rust/comments/jkxelc/going_crazy_over_running_a_curl_process_from_rust/) on reddit. I am not a native speaker, so I welcome any corrections or better formulation, I don't expect this to be merged as is. I was also reminded that this is platform/shell specific behaviour, but I didn't find a good way to formulate that briefly, any ideas welcome. It's also my first PR here, so I am not sure I did everything correctly, I did this just from Github UI.
2020-10-31Apply suggestions from code reviewMatyáš Racek-4/+8
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
2020-10-31fix aliasing issue in unix sleep functionRalf Jung-1/+2
2020-10-31Add note to process::arg[s] that args shouldn't be escaped or quotedMatyáš Racek-0/+6
2020-10-31Rollup merge of #77099 - tspiteri:exp_m1-examples, r=m-ou-seMara Bos-16/+20
make exp_m1 and ln_1p examples more representative of use With this PR, the examples for `exp_m1` would fail if `x.exp() - 1.0` is used instead of `x.exp_m1()`, and the examples for `ln_1p` would fail if `(x + 1.0).ln()` is used instead of `x.ln_1p()`.
2020-10-31Rollup merge of #74622 - fusion-engineering-forks:panic-box, r=KodrAusMara Bos-0/+14
Add std::panic::panic_any. The discussion of #67984 lead to the conclusion that there should be a macro or function separate from `std::panic!()` for throwing arbitrary payloads, to make it possible to deprecate or disallow (in edition 2021) `std::panic!(arbitrary_payload)`. Alternative names: - `panic_with!(..)` - ~~`start_unwind(..)`~~ (panicking doesn't always unwind) - `throw!(..)` - `panic_throwing!(..)` - `panic_with_value(..)` - `panic_value(..)` - `panic_with(..)` - `panic_box(..)` - `panic(..)` The equivalent (private, unstable) function in `libstd` is called `std::panicking::begin_panic`. I suggest `panic_any`, because it allows for any (`Any + Send`) type. _Tracking issue: #78500_
2020-10-30Use SOCK_CLOEXEC and accept4() on more platforms.Maarten de Vries-6/+32
2020-10-30Rollup merge of #78554 - camelid:improve-drop_in_place-docs-wording, r=jyn514Yuki Okushi-2/+2
Improve wording of `core::ptr::drop_in_place` docs And two small intra-doc link conversions in `std::{f32, f64}`.
2020-10-30Rollup merge of #77921 - wcampbell0x2a:f64-collapsible-if, r=jyn514Yuki Okushi-14/+12
f64: Refactor collapsible_if
2020-10-29Improve wording of `core::ptr::drop_in_place` docsCamelid-2/+2
And two small intra-doc link conversions in `std::{f32, f64}`.
2020-10-28Add tracking issue number for panic_any.Mara Bos-1/+1
2020-10-28Update panic_any feature name.Mara Bos-1/+1
Co-authored-by: Camelid <camelidcamel@gmail.com>
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-05 04:05:58 +0000