about summary refs log tree commit diff
path: root/library/std/src
AgeCommit message (Collapse)AuthorLines
2021-05-19Auto merge of #85176 - a1phyr:impl_clone_from, r=yaahcbors-1/+18
Override `clone_from` for some types Override `clone_from` method of the `Clone` trait for: - `cell::RefCell` - `cmp::Reverse` - `io::Cursor` - `mem::ManuallyDrop` This can bring performance improvements.
2021-05-18std: Attempt again to inline thread-local-init across cratesAlex Crichton-0/+24
Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-18fix typoJorge Ferreira-2/+2
2021-05-18Add diagnostic item to `CStr`Mateusz Gacek-0/+1
2021-05-18Auto merge of #82973 - ijackson:exitstatuserror, r=yaahcbors-20/+281
Provide ExitStatusError Closes #73125 In MR #81452 "Add #[must_use] to [...] process::ExitStatus" we concluded that the existing arrangements in are too awkward so adding that `#[must_use]` is blocked on improving the ergonomics. I wrote a mini-RFC-style discusion of the approach in https://github.com/rust-lang/rust/issues/73125#issuecomment-771092741
2021-05-18Stabilize extended_key_value_attributesJoshua Nelson-1/+1
# Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes, like so: ```rust #[doc = include_str!("my_doc.md")] struct S; #[path = concat!(env!("OUT_DIR"), "/generated.rs")] mod m; ``` See the changes to the reference for details on what macros are allowed; see Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected ("why accept no more and no less?") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns, but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!("lib.rs") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = "lib.rs")] struct S {} ``` The first works, but is non-trivial for people to discover, and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case, not just including files. I plan to remove `doc(include)` when this is stabilized. The `forward_inner_docs` workaround will still compile without warnings, but I expect it to be used less once it's no longer necessary.
2021-05-17Rollup merge of #85409 - CDirkx:cfg_redox, r=nagisaRalf Jung-1/+1
Simplify `cfg(any(unix, target_os="redox"))` in example to just `cfg(unix)` Update example for `OsString` that handled `redox` seperately from `unix`: Redox has been completely integrated under `target_family="unix"`, so `cfg(unix)` implies `target_os="redox"` https://github.com/rust-lang/rust/blob/35dbef235048f9a2939dc20effe083ca483c37ff/compiler/rustc_target/src/spec/redox_base.rs#L26
2021-05-17Rollup merge of #85302 - r00ster91:patch-7, r=joshtriplettRalf Jung-1/+1
Expand WASI abbreviation in docs I was pretty sure this was related to something for WebAssembly but wasn't 100% sure so I checked but even on these top-level docs I couldn't find the abbreviation expanded. I'm normally used to Rust docs being detailed and explanatory and writing abbreviations like this out in full at least once so I thought it was worth the change. Feel free to close this if it's too much.
2021-05-17Simplify `cfg(any(unix, target_os="redox"))` to just `cfg(unix)`Christiaan Dirkx-1/+1
2021-05-15Auto merge of #81858 - ijackson:fork-no-unwind, r=m-ou-sebors-17/+121
Do not allocate or unwind after fork ### Objective scenarios * Make (simple) panics safe in `Command::pre_exec_hook`, including most `panic!` calls, `Option::unwrap`, and array bounds check failures. * Make it possible to `libc::fork` and then safely panic in the child (needed for the above, but this requirement means exposing the new raw hook API which the `Command` implementation needs). * In singlethreaded programs, where panic in `pre_exec_hook` is already memory-safe, prevent the double-unwinding malfunction #79740. I think we want to make panic after fork safe even though the post-fork child environment is only experienced by users of `unsafe`, beause the subset of Rust in which any panic is UB is really far too hazardous and unnatural. #### Approach * Provide a way for a program to, at runtime, switch to having panics abort. This makes it possible to panic without making *any* heap allocations, which is needed because on some platforms malloc is UB in a child forked from a multithreaded program (see https://github.com/rust-lang/rust/pull/80263#issuecomment-774272370, and maybe also the SuS [spec](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html)). * Make that change in the child spawned by `Command`. * Document the rules comprehensively enough that a programmer has a fighting chance of writing correct code. * Test that this all works as expected (and in particular, that there aren't any heap allocations we missed) Fixes #79740 #### Rejected (or previously attempted) approaches * Change the panic machinery to be able to unwind without allocating, at least when the payload and message are both `'static`. This seems like it would be even more subtle. Also that is a potentially-hot path which I don't want to mess with. * Change the existing panic hook mechanism to not convert the message to a `String` before calling the hook. This would be a surprising change for existing code and would not be detected by the type system. * Provide a `raw_panic_hook` function to intercept panics in a way that doesn't allocate. (That was an earlier version of this MR.) ### History This MR could be considered a v2 of #80263. Thanks to everyone who commented there. In particular, thanks to `@m-ou-se,` `@Mark-Simulacrum` and `@hyd-dev.` (Tagging you since I think you might be interested in this new MR.) Compared to #80263, this MR has very substantial changes and additions. Additionally, I have recently (2021-04-20) completely revised this series following very helpful comments from `@m-ou-se.` r? `@m-ou-se`
2021-05-15Add doc aliases to `unit`r00ster-0/+3
2021-05-15Rollup merge of #85221 - ijackson:dbg-doc-re-tests, r=joshtriplettGuillaume Gomez-3/+4
dbg macro: Discuss use in tests, and slightly clarify As discussed in a tangent in #82778. I chose to use [semantic newlines](https://rhodesmill.org/brandon/2012/one-sentence-per-line/) in the source text but I don't mind reformatting it.
2021-05-15Rollup merge of #85207 - andrewhalle:typo-rootseparator, r=kennytmGuillaume Gomez-1/+1
Fix typo in comment missing space in "rootseparator"
2021-05-14Expand WASI abbreviation in docsr00ster-1/+1
2021-05-14add an example to explain std::io::Read::read returning 0 in some casesGeoffroy Couprie-1/+7
the example focuses on Linux, but that should be enough to explain how the behaviour can change
2021-05-14Move `std::memchr` to `sys_common`Christiaan Dirkx-8/+10
2021-05-13Add support for const operands and options to global_asm!Amanieu d'Antras-1/+1
On x86, the default syntax is also switched to Intel to match asm!
2021-05-13Fix indentation in move keyword documentationThomas Otto-2/+2
2021-05-13Tolerate SIGTRAP for panic abort after panic::always_abortIan Jackson-1/+1
Some platforma (eg ARM64) apparently generate SIGTRAP for panic abort! See eg https://github.com/rust-lang/rust/pull/81858#issuecomment-840702765 This is probably a bug, but we don't want to entangle this MR with it. When it's fixed, this commit should be reverted. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-13Change "etc." to "and similar"Ian Jackson-1/+1
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2021-05-12Auto merge of #84730 - sexxi-goose:rox-auto-trait, r=nikomatsakisbors-0/+2
Add auto traits and clone trait migrations for RFC2229 This PR - renames the existent RFC2229 migration `disjoint_capture_drop_reorder` to `disjoint_capture_migration` - add additional migrations for auto traits and clone trait Closes rust-lang/project-rfc-2229#29 Closes rust-lang/project-rfc-2229#28 r? `@nikomatsakis`
2021-05-12dbg macro: Discuss use in tests, and slightly clarifyIan Jackson-3/+4
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-12ExitStatusError: Remove mentions in stable docsIan Jackson-27/+3
We should revert this commit when this is stabilised. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-12impl crate::error::Error for ExitStatusErrorIan Jackson-0/+3
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-12ExitStatusError: Be more verbose in Display implIan Jackson-1/+1
Co-authored-by: Jane Lusby <jlusby@yaah.dev>
2021-05-12Fix typo in docIan Jackson-1/+1
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2021-05-12unix: impl ExitStatusExt for ExitStatusErrorIan Jackson-10/+76
It is unergnomic to have to say things like bad.into_status().signal() Implementing `ExitStatusExt` for `ExitStatusError` fixes this. Unfortunately it does mean making a previously-infallible method capable of panicing, although of course the existing impl remains infallible. The alternative would be a whole new `ExitStatusErrorExt` trait. `<ExitStatus as ExitStatusExt>::into_raw()` is not particularly ergonomic to call because of the often-required type annotation. See for example the code in the test case in library/std/src/sys/unix/process/process_unix/tests.rs Perhaps we should provide equivalent free functions for `ExitStatus` and `ExitStatusExt` in std::os::unix::process and maybe deprecate this trait method. But I think that is for the future. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-12Provide ExitStatusErrorIan Jackson-13/+227
Closes #73125 This is in pursuance of Issue #73127 Consider adding #[must_use] to std::process::ExitStatus In MR #81452 Add #[must_use] to [...] process::ExitStatus we concluded that the existing arrangements in are too awkward so adding that #[must_use] is blocked on improving the ergonomics. I wrote a mini-RFC-style discusion of the approach in https://github.com/rust-lang/rust/issues/73125#issuecomment-771092741 Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-11Fix typo in commentAndrew Halle-1/+1
missing space in "rootseparator"
2021-05-12Rollup merge of #85136 - shirshak55:master, r=dtolnayYuki Okushi-10/+10
Change param name (k to key and v to value) in std::env module 1. When I was reading code the ide displayed `k` and `v`, so I thought it would be better to show key and value? 2. I noticed var method already uses `key` instead of `k` so it is more consistent to use `key` instead of `k`? Thanks
2021-05-11use the correct attributes and add helper functionRoxane-2/+2
2021-05-11Override `clone_from` for some typesBenoƮt du Garreau-1/+18
2021-05-11Auto merge of #85109 - RalfJung:remove-const_fn, r=oli-obkbors-1/+0
remove const_fn feature gate Fixes https://github.com/rust-lang/rust/issues/84510 r? `@oli-obk`
2021-05-11Auto merge of #80300 - LeSeulArtichaut:80275-doc-inline, r=Manishearthbors-1/+0
Emit errors/warns on some wrong uses of rustdoc attributes This PR adds a few diagnostics: - error if conflicting `#[doc(inline)]`/`#[doc(no_inline)]` are found - introduce the `invalid_doc_attributes` lint (warn-by-default) which triggers: - if a crate-level attribute is used on a non-`crate` item - if `#[doc(inline)]`/`#[doc(no_inline)]` is used on a non-`use` item The code could probably be improved but I wanted to get feedback first. Also, some of those changes could be considered breaking changes, so I don't know what the procedure would be? ~~And finally, for the warnings, they are currently hard warnings, maybe it would be better to introduce a lint?~~ (EDIT: introduced the `invalid_doc_attributes` lint) Closes #80275. r? `@jyn514`
2021-05-11add missing windows testsMichael Hall-53/+140
2021-05-11add file_prefix methodMichael Hall-36/+191
2021-05-11Remove an invalid `#[doc(inline)]`LeSeulArtichaut-1/+0
2021-05-10io::Seek::rewind: Set tracking issueIan Jackson-1/+1
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-10Fix typo in docIan Jackson-1/+1
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
2021-05-10io::Seek: Provide rewind()Ian Jackson-0/+35
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-10io::Seek: Mention that seeking can fail due to buffer flush failIan Jackson-0/+2
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-10change k to key and v to v in std::env modshirshak55-10/+10
2021-05-10windows: provide NonZeroDWORDIan Jackson-0/+2
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-09remove const_fn feature gateRalf Jung-1/+0
2021-05-07Revert SGX inline asm syntaxJethro Beekman-8/+8
This was erroneously changed in #83387
2021-05-07panic/fork test: Do not run on emscriptenIan Jackson-0/+1
fork fails there. The failure message is confusing: so c.status() returns an Err, the closure panics, and the test thinks the panic was propagated from inside the child. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
2021-05-07Rollup merge of #85030 - jethrogb:jb/sgx-rearrange-files, r=nagisaDylan DPC-6/+7
Rearrange SGX split module files In #75979 several inlined modules were split out into multiple files. This PR keeps the multiple files but moves a few things around to organize things in a coherent way.
2021-05-07Rollup merge of #85029 - jethrogb:jb/sgx-movable-mutex, r=m-ou-seDylan DPC-1/+1
SGX mutex is movable r? ``@m-ou-se``
2021-05-07Rollup merge of #84655 - CDirkx:wasm, r=m-ou-seDylan DPC-65/+14
Cleanup of `wasm` Some more cleanup of `sys`, this time `wasm` - Reuse `unsupported::args` (functionally equivalent implementation, just an empty iterator). - Split out `atomics` implementation of `wasm::thread`, the non-`atomics` implementation is reused from `unsupported`. - Move all of the `atomics` code to a separate directory `wasm/atomics`. ````@rustbot```` label: +T-libs-impl r? ````@m-ou-se````
2021-05-07Rearrange SGX split module filesJethro Beekman-6/+7
In #75979 several inlined modules were split out into multiple files. This PR keeps the multiple files but moves a few things around to organize things in a coherent way.