about summary refs log tree commit diff
path: root/src/libstd
AgeCommit message (Collapse)AuthorLines
2020-07-23Auto merge of #74613 - Mark-Simulacrum:revert-gimli, r=nnethercotebors-31/+23
Revert libbacktrace -> gimli This reverts 4cbd265c119cb1a5eb92e98d2bb93466f05efa46 028f8d7b85898683b99e05564cd2976c7e0d5b43 13db3cc1e8d2fd4b8e7c74d91002274d7b62801b d7a36d8964c927863faef5d3b42da08f37e5896c (and technically 79673d300915f846726c27b9e1974dc451013ee9 but it's made empty by previous reverts). The current plan is to land this PR as a temporary change, so that we can get a better handle on the regressions introduced by it. Trying to fix/examine them in master is difficult, and we want to be better able to evaluate them without impact to other PRs being landed in the mean time. That said, it is currently *my* belief that gimli, in one form or another, will need to land sometime soon. I think it's quite likely that it may slip a week or two, but I would personally push for re-landing it then "regardless" of the regressions. We should try to focus efforts on understanding and removing as much of the performance impact as possible, as everyone pretty much agrees that it should be quite minimal (and entirely in the linker, basically). r? @nnethercote
2020-07-23Rollup merge of #74606 - cuviper:cloexec, r=sfacklerManish Goregaokar-195/+74
Remove Linux workarounds for missing CLOEXEC support Now that #74163 updated the minimum Linux kernel to 2.6.32, we can assume the availability of APIs that open file descriptors that are already set to close on exec, including the flags `O_CLOEXEC`, `SOCK_CLOEXEC`, and `F_DUPFD_CLOEXEC`. Closes #74519.
2020-07-23Rollup merge of #74587 - lzutao:consts, r=dtolnayManish Goregaokar-27/+26
Prefer constant over function Just that I prefer constants over functions that can be made const.
2020-07-23Rollup merge of #74548 - tshepang:one-more-example, r=dtolnayManish Goregaokar-0/+3
one more Path::with_extension example, to demonstrate behavior
2020-07-23Rollup merge of #74490 - yaahc:disabled-bt, r=dtolnayManish Goregaokar-0/+6
add a Backtrace::disabled function Based upon @dtolnay's suggestion here: https://github.com/dtolnay/anyhow/pull/97#issuecomment-647172942
2020-07-23Rollup merge of #74141 - euclio:typos, r=steveklabnikManish Goregaokar-12/+12
libstd/libcore: fix various typos
2020-07-23Prefer constant over functionLzu Tao-28/+27
2020-07-22Update src/libstd/backtrace.rsJane Lusby-1/+1
Co-authored-by: David Tolnay <dtolnay@gmail.com>
2020-07-22one more Path::with_extension example, to demonstrate behaviorTshepang Lekhonkhobe-0/+3
2020-07-22Move the pipe2 call behind a hard target `#[cfg]`Josh Stone-21/+29
2020-07-22build: Avoid unnecessary build script reruns in libstdVadim Petrochenkov-0/+1
Add a FIXME to build scripts in profiler_builtins
2020-07-22build: Remove unnecessary `build = "build.rs"` annotationsVadim Petrochenkov-1/+0
2020-07-22Revert "std: Switch from libbacktrace to gimli"Mark Rousskov-32/+23
This reverts commit 13db3cc1e8d2fd4b8e7c74d91002274d7b62801b.
2020-07-22Revert "std: Fix compilation without backtrace feature"Mark Rousskov-1/+2
This reverts commit 028f8d7b85898683b99e05564cd2976c7e0d5b43.
2020-07-21Remove Linux workarounds for missing CLOEXEC supportJosh Stone-187/+58
Now that #74163 updated the minimum Linux kernel to 2.6.32, we can assume the availability of APIs that open file descriptors that are already set to close on exec, including the flags `O_CLOEXEC`, `SOCK_CLOEXEC`, and `F_DUPFD_CLOEXEC`.
2020-07-21Auto merge of #74075 - sunfishcode:wasi-prelude-rawfd, r=alexcrichtonbors-1/+1
Add `RawFd` to WASI's `std::os::wasi::prelude`. Add `RawFd` to WASI's `std::os::wasi::prelude`, making it consistent with all other platforms which also have `AsRawFd`, `FromRawFd`, and `IntoRawFd` in their respective preludes.
2020-07-20Rollup merge of #74546 - jethrogb:jb/duplicate-attribute-maybe_uninit_extra, ↵Manish Goregaokar-4/+1
r=kennytm Fix duplicate maybe_uninit_extra attribute Introduced in #72414
2020-07-20Fix duplicate maybe_uninit_extra attributeJethro Beekman-4/+1
2020-07-20Auto merge of #74010 - pierwill:pierwill-o-notation, r=GuillaumeGomezbors-1/+1
Use italics for O notation In documentation, I think it makes sense to italicize O notation (*O(n)*) as opposed to using back-ticks (`O(n)`). Visually, back-ticks focus the reader on the literal characters being used, making them ideal for representing code. Using italics, as far I can tell, more closely follows typographic conventions in mathematics and computer science. Just a suggestion, of course! 😇
2020-07-20Auto merge of #74540 - alexcrichton:std-no-backtrace, r=Mark-Simulacrumbors-2/+1
std: Fix compilation without backtrace feature This should hopefully handle #74484 but in any case fixes compilation of the standard library without the `backtrace` feature. The need for this feature is somewhat unclear now because the `backtrace` crate should always compile (no more C code!) but we can handle that later if necessary.
2020-07-19Use italics for O notationpierwill-1/+1
Co-authored-by: Guillaume Gomez <guillaume1.gomez@gmail.com>
2020-07-19Rollup merge of #74536 - Nicholas-Baron:master, r=joshtriplettManish Goregaokar-4/+4
fix documentation surrounding the `in` and `for` keywords Addresses #74529 The `in` keyword incorrectly referenced the `Iterator` trait. This reference was changed to `IntoIterator` without changing the underlying link. Additionally, the `IntoIterator` trait was referenced towards the end of the documentation for `for`. An additional reference was added earlier and broadened the existing documentation from any iterator to anything that can be turned into an iterator.
2020-07-19Rollup merge of #74486 - poliorcetics:read-exact-doc-point-to-read, ↵Manish Goregaokar-1/+4
r=Mark-Simulacrum Improve Read::read_exact documentation Fixes #72186. For now I simply added a link to `Read::read` and held off changing the text in `Read::read_exact`. I can do it if it is deemed necessary. @rustbot modify labels: C-enhancement, T-libs
2020-07-19Rollup merge of #73618 - poliorcetics:false-keyword, r=jyn514Manish Goregaokar-3/+4
Documentation for the false keyword Partial fix of #34601. Short documentation for the false keyword mainly pointing to the `true` keyword.
2020-07-19std: Fix compilation without backtrace featureAlex Crichton-2/+1
This should hopefully handle #74484 but in any case fixes compilation of the standard library without the `backtrace` feature. The need for this feature is somewhat unclear now because the `backtrace` crate should always compile (no more C code!) but we can handle that later if necessary.
2020-07-19Update src/libstd/keyword_docs.rs Nicholas Baron-1/+1
Clear up wording regarding the iterator and usage of `break`. Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2020-07-19Linked the earlier mention of IntoIterator in the keyword 'for' docsNicholas-Baron-1/+1
2020-07-19Mentioned IntoIterator in keyword 'in' docsNicholas-Baron-2/+2
2020-07-19Mentioned IntoIterator earlier in keyword 'for' docsNicholas-Baron-2/+2
2020-07-19Fix merge conflict with recent PRAlexis Bourget-226/+372
2020-07-19Apply suggestions from reviewPoliorcetics-1/+1
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
2020-07-19Rollup merge of #74485 - Manishearth:more-intra-doc, r=jyn514Manish Goregaokar-196/+79
More intra-doc links, add explicit exception list to linkchecker Fixes the broken links behind #32553 Progress on #32130 and #32129 except for a small number of links. Instead of whitelisting entire files, I've changed the code to whitelist specific links in specific files, and added a comment requesting people explain the reasons they add exceptions. I'm not sure if we should close those issues in favor of the already filed intra-doc link issues.
2020-07-19Rollup merge of #74356 - lzutao:rm_combine, r=LukasKalbertodtManish Goregaokar-7/+3
Remove combine function Comparing two array directly helps generate better assert message. Resolve https://github.com/rust-lang/rust/pull/74271/files#r454538514
2020-07-19Rollup merge of #74333 - poliorcetics:std-alloc-unsafe-op-in-unsafe-fn, ↵Manish Goregaokar-20/+71
r=LukasKalbertodt Deny unsafe operations in unsafe functions in libstd/alloc.rs Partial fix of #73904. This encloses `unsafe` operations in `unsafe fn` in `libstd/alloc.rs`. @rustbot modify labels: F-unsafe-block-in-unsafe-fn
2020-07-19Remove useless link to bool primitiveAlexis Bourget-1/+0
2020-07-19Fix small nit in the link to readAlexis Bourget-1/+1
2020-07-18Update src/libstd/io/mod.rsManish Goregaokar-1/+1
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
2020-07-18Rollup merge of #74021 - 1011X:master, r=dtolnayManish Goregaokar-0/+38
impl Index<RangeFrom> for CStr This change implements (partial) slicing for `CStr`. Since a `CStr` must end in a null byte, it's not possible to trim from the right and still have a valid `CStr`. But, it *is* possible to trim from the left. This lets us be a bit more flexible and treat them more like strings. ```rust let string = CStr::from_bytes_with_nul(b"Hello World!\0"); let result = CStr::from_bytes_with_nul(b"World!\0"); assert_eq!(&string[6..], result); ```
2020-07-18Rollup merge of #73762 - poliorcetics:trait-keyword, r=KodrAusManish Goregaokar-3/+180
Document the trait keyword Partial fix of #34601. This document the trait keyword. To avoid doing too much and forcing more updates as functionalities evolve, I put two links to the reference, especially for trait objects. This mainly documents the "big" parts, not so much the small details that might trip someone experimenting. @rustbot modify labels: T-doc,C-enhancement
2020-07-18Rollup merge of #70817 - yoshuawuyts:task-ready, r=dtolnayManish Goregaokar-0/+1
Add core::task::ready! macro This PR adds `ready!` as a top-level macro to `libcore` following the implementation of `futures_core::ready`, tracking issue https://github.com/rust-lang/rust/issues/70922. This macro is commonly used when implementing `Future`, `AsyncRead`, `AsyncWrite` and `Stream`. And being only 5 lines, it seems like a useful and straight forward addition to std. ## Example ```rust use core::task::{Context, Poll}; use core::future::Future; use core::pin::Pin; async fn get_num() -> usize { 42 } pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut f = get_num(); let f = unsafe { Pin::new_unchecked(&mut f) }; let num = ready!(f.poll(cx)); // ... use num Poll::Ready(()) } ``` ## Naming In `async-std` we chose to nest the macro under the `task` module instead of having the macro at the top-level. This is a pattern that currently does not occur in std, mostly due to this not being possible prior to Rust 2018. This PR proposes to add the `ready` macro as `core::ready`. But another option would be to introduce it as `core::task::ready` since it's really only useful when used in conjunction with `task::{Context, Poll}`. ## Implementation questions I tried rendering the documentation locally but the macro didn't show up under `core`. I'm not sure if I quite got this right. I used the [`todo!` macro PR](https://github.com/rust-lang/rust/pull/56348/files) as a reference, and our approaches look similar. ## References - [`futures::ready`](https://docs.rs/futures/0.3.4/futures/macro.ready.html) - [`async_std::task::ready`](https://docs.rs/async-std/1.5.0/async_std/task/index.html) - [`futures_core::ready`](https://docs.rs/futures-core/0.3.4/futures_core/macro.ready.html)
2020-07-18Use intra-doc links on HashSetManish Goregaokar-38/+9
2020-07-18Use intra-doc links on HashMapManish Goregaokar-68/+19
2020-07-18Use intra-doc links in std::ioManish Goregaokar-90/+51
2020-07-18remove trailing semiJane Lusby-1/+1
2020-07-18add a Backtrace::disabled functionJane Lusby-0/+6
2020-07-18Add a link to read in the read_exact doc about the guaranteesAlexis Bourget-1/+4
2020-07-18Update stability attribute for CStr indexingDavid Tolnay-1/+1
2020-07-18impl Index<RangeFrom<usize>> for CStr1011X-0/+38
2020-07-18Auto merge of #73441 - alexcrichton:backtrace-gimli, r=Mark-Simulacrumbors-23/+32
std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called "libbacktrace". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time, unfortunately, though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself, both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose, which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate, by default, uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency, this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly, but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option, and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself, enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note, however, that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway, so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly, but a dependency of `addr2line`. * `adler32`- not used directly either, but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library, especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS, never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293, #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away, but correctness and performance may still have bugs arise. The gimli and `backtrace` crates, however, are actively maintained unlike libbacktrace, so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR, however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325, https://github.com/rust-lang/backtrace-rs/issues/326, https://github.com/rust-lang/backtrace-rs/issues/350, https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change, so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR), but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this, so I'm hoping others can help me figure that out!
2020-07-17Rollup merge of #72414 - KodrAus:feat/stdlazy, r=Mark-SimulacrumManish Goregaokar-4/+866
Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now, but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy`, especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally, if we're adding these types to `std::lazy` instead of `std::sync`, I'd be on-board with not worrying about poisoning in `std::lazy`, and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible, rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general, none of these seem to be really blocking an initial unstable merge, so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything, or were there any other considerations that have come up since we last looked at this?
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-09-29 13:28:31 +0000