about summary refs log tree commit diff
path: root/src/libstd/lib.rs
AgeCommit message (Collapse)AuthorLines
2020-01-04Rollup merge of #67137 - anp:tracked-panic-internals, r=eddybDylan DPC-0/+1
libstd uses `core::panic::Location` where possible. cc @eddyb
2020-01-04core and std macros and panic internals use panic::Location::caller.Adam Perry-0/+1
2019-12-31Revert "core: add IntoFuture trait and support for await"Wesley Wiser-1/+0
This reverts commit f35517ee861dc012ccc26083dd4520045e2c4f6f.
2019-12-28Rollup merge of #67659 - SimonSapin:matches, r=rkruppeOliver Scherer-1/+0
Stabilize the `matches!` macro Fixes https://github.com/rust-lang/rust/issues/65721 FCP: https://github.com/rust-lang/rust/issues/65721#issuecomment-569118119
2019-12-27core: add IntoFuture trait and support for awaitSean McArthur-0/+1
2019-12-27Stabilize the `matches!` macroSimon Sapin-1/+0
Fixes https://github.com/rust-lang/rust/issues/65721 FCP: https://github.com/rust-lang/rust/issues/65721#issuecomment-569118119
2019-12-22Format the worldMark Rousskov-73/+73
2019-12-19Correct the todo! stabilization versionJakub Kądziołka-1/+1
2019-12-18Propagate cfg bootstrapMark Rousskov-2/+0
2019-12-14Auto merge of #67224 - nikomatsakis:revert-stabilization-of-never-type, ↵bors-1/+1
r=centril Revert stabilization of never type Fixes https://github.com/rust-lang/rust/issues/66757 I decided to keep the separate `never-type-fallback` feature gate, but tried to otherwise revert https://github.com/rust-lang/rust/pull/65355. Seemed pretty clean. ( cc @Centril, author of #65355, you may want to check this over briefly )
2019-12-14Revert "Stabilize the `never_type`, written `!`."Niko Matsakis-1/+1
This reverts commit 15c30ddd69d6cc3fffe6d304c6dc968a5ed046f1.
2019-12-13Reuse the `staged_api` feature for `rustc_const_unstable`Oliver Scherer-1/+1
2019-11-30Rollup merge of #66705 - pitdicker:atomic_mut_ptr, r=KodrAusMazdak Farrokhzad-0/+1
Atomic as_mut_ptr I encountered the following pattern a few times: In Rust we use some atomic type like `AtomicI32`, and an FFI interface exposes this as `*mut i32` (or some similar `libc` type). It was not obvious to me if a just transmuting a pointer to the atomic was acceptable, or if this should use a cast that goes through an `UnsafeCell`. See https://github.com/rust-lang/rust/issues/66136#issuecomment-557802477 Transmuting the pointer directly: ```rust let atomic = AtomicI32::new(1); let ptr = &atomic as *const AtomicI32 as *mut i32; unsafe { ffi(ptr); } ``` A dance with `UnsafeCell`: ```rust let atomic = AtomicI32::new(1); unsafe { let ptr = (&*(&atomic as *const AtomicI32 as *const UnsafeCell<i32>)).get(); ffi(ptr); } ``` Maybe in the end both ways could be valid. But why not expose a direct method to get a pointer from the standard library? An `as_mut_ptr` method on atomics can be safe, because only the use of the resulting pointer is where things can get unsafe. I documented its use for FFI, and "Doing non-atomic reads and writes on the resulting integer can be a data race." The standard library could make use this method in a few places in the WASM module. cc @RalfJung as you answered my original question.
2019-11-24Use as_mut_ptr instead of castsPaul Dicker-0/+1
2019-11-21Stabilize the `never_type`, written `!`.Mazdak Farrokhzad-1/+1
2019-11-18Remove compiler_builtins_lib feature from libstdYu Ding-1/+0
2019-11-12Snap cfgsMark Rousskov-1/+0
2019-11-06gate rustc_on_unimplemented under rustc_attrsMazdak Farrokhzad-1/+1
2019-10-25RFC 2008: StabilizationDavid Wood-1/+1
This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood <david@davidtw.co>
2019-10-25Rollup merge of #65742 - Centril:gate-pre-expansion-subset, r=davidtwcoMazdak Farrokhzad-1/+2
Pre-expansion gate most of the things This is a subset of https://github.com/rust-lang/rust/pull/64672. A crater run has already been done and this PR implements conclusions according to https://github.com/rust-lang/rust/pull/64672#issuecomment-542703363. r? @davidtwco cc @petrochenkov
2019-10-24pre-expansion gate decl_macroMazdak Farrokhzad-1/+2
2019-10-23Move the `matches!` macro to the preludeSimon Sapin-10/+2
2019-10-23Add `core::macros::matches!( $expr, $pat ) -> bool`Simon Sapin-1/+11
# Motivation This macro is: * General-purpose (not domain-specific) * Simple (the implementation is short) * Very popular [on crates.io](https://crates.io/crates/matches) (currently 37th in all-time downloads) * The two previous points combined make it number one in [left-pad index](https://twitter.com/bascule/status/1184523027888988160) score As such, I feel it is a good candidate for inclusion in the standard library. In fact I already felt that way five years ago: https://github.com/rust-lang/rust/pull/14685 (Although the proof of popularity was not as strong at the time.) Back then, the main concern was that this macro may not be quite universally-enough useful to belong in the prelude. # API Therefore, this PR adds the macro such that using it requires one of: ``` use core::macros::matches; use std::macros::matches; ``` Like arms of a `match` expression, the macro supports multiple patterns separated by `|` and optionally followed by `if` and a guard expression: ``` let foo = 'f'; assert!(matches!(foo, 'A'..='Z' | 'a'..='z')); let bar = Some(4); assert!(matches!(bar, Some(x) if x > 2)); ``` # Implementation constraints A combination of reasons make it tricky for a standard library macro not to be in the prelude. Currently, all public `macro_rules` macros in the standard library macros end up “in the prelude” of every crate not through `use std::prelude::v1::*;` like for other kinds of items, but through `#[macro_use]` on `extern crate std;`. (Both are injected by `src/libsyntax_ext/standard_library_imports.rs`.) `#[macro_use]` seems to import every macro that is available at the top-level of a crate, even if through a `pub use` re-export. Therefore, for `matches!` not to be in the prelude, we need it to be inside of a module rather than at the root of `core` or `std`. However, the only way to make a `macro_rules` macro public outside of the crate where it is defined appears to be `#[macro_export]`. This exports the macro at the root of the crate regardless of which module defines it. See [macro scoping]( https://doc.rust-lang.org/reference/macros-by-example.html#scoping-exporting-and-importing) in the reference. Therefore, the macro needs to be defined in a crate that is not `core` or `std`. # Implementation This PR adds a new `matches_macro` crate as a private implementation detail of the standard library. This crate is `#![no_core]` so that libcore can depend on it. It contains a `macro_rules` definition with `#[macro_export]`. libcore and libstd each have a new public `macros` module that contains a `pub use` re-export of the macro. Both the module and the macro are unstable, for now. The existing private `macros` modules are renamed `prelude_macros`, though their respective source remains in `macros.rs` files.
2019-10-21Rollup merge of #62330 - SimonSapin:no-drop-in-union-fields, r=RalfJungMazdak Farrokhzad-0/+1
Change untagged_unions to not allow union fields with drop This is a rebase of #56440, massaged to solve merge conflicts and make the test suite pass. Change untagged_unions to not allow union fields with drop Union fields may now never have a type with attached destructor. This for example allows unions to use arbitrary field types only by wrapping them in `ManuallyDrop` (or similar). The stable rule remains, that union fields must be `Copy`. We use the new rule for the `untagged_union` feature. Tracking issue: https://github.com/rust-lang/rust/issues/55149
2019-10-18Avoid realloc in `CString::new`Shotaro Yamada-0/+1
2019-10-11Prefer `ManuallyDrop::{take,new}` over `ptr::{read,write}`Oliver Scherer-0/+1
2019-10-08Stabilize mem::take (mem_take)Jon Gjengset-1/+0
Tracking issue: https://github.com/rust-lang/rust/issues/61129
2019-10-03Rollup merge of #61879 - stjepang:stabilize-todo, r=withoutboatsTyler Mandry-1/+0
Stabilize todo macro The `todo!` macro is just another name for `unimplemented!`. Tracking issue: https://github.com/rust-lang/rust/issues/59277 This PR needs a FCP to merge. r? @withoutboats
2019-09-25Snap cfgs to new betaMark Rousskov-1/+0
2019-09-11Auto merge of #64154 - alexcrichton:std-backtrace, r=sfacklerbors-0/+1
std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library, as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative, effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None`, as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487
2019-09-09std: Add a `backtrace` moduleAlex Crichton-0/+1
This commit adds a `backtrace` module to the standard library, as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative, effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None`, as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487
2019-09-08Dont use gate bind_by_move_pattern_guards internally.Mazdak Farrokhzad-1/+1
2019-09-05Stabilize checked_duration_since for 1.39.0Vitaly _Vi Shukela-1/+0
Resolves #58402.
2019-08-16Rollup merge of #63613 - petrochenkov:stdhyg, r=alexcrichtonMazdak Farrokhzad-2/+0
Hygienize use of built-in macros in the standard library Same as https://github.com/rust-lang/rust/pull/61629, but for built-in macros. Closes https://github.com/rust-lang/rust/issues/48781 r? @alexcrichton
2019-08-16Add the Layout of the failed allocation to TryReserveError::AllocErrorSimon Sapin-0/+1
… and add a separately-unstable field to force non-exhaustive matching (`#[non_exhaustive]` is no implemented yet on enum variants) so that we have the option to later expose the allocator’s error value. CC https://github.com/rust-lang/wg-allocators/issues/23
2019-08-15Remove `__rust_unstable_column`Vadim Petrochenkov-2/+0
2019-08-14Handle cfg(bootstrap) throughoutMark Rousskov-3/+2
2019-08-10Rollup merge of #63350 - iluuu1994:use-associated-type-bounds, r=CentrilMazdak Farrokhzad-0/+1
Use associated_type_bounds where applicable - closes #61738
2019-08-10Give built-in macros stable addresses in the standard libraryVadim Petrochenkov-21/+30
2019-08-09Add missing #![feature(associated_type_bounds)]Ilija Tovilo-0/+1
2019-08-09Postpone deprecating try! until 1.39.0Lzu Tao-1/+2
2019-08-09Deprecate `try!` macroBO41-1/+4
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com> Co-Authored-By: Oliver Middleton <olliemail27@gmail.com>
2019-07-31Remove derives `Encodable`/`Decodable` and unstabilize attribute `#[bench]`Vadim Petrochenkov-1/+2
2019-07-28Deny `unused_lifetimes` through rustbuildVadim Petrochenkov-0/+1
2019-07-28Remove lint annotations in specific crates that are already enforced by ↵Vadim Petrochenkov-2/+0
rustbuild Remove some random unnecessary lint `allow`s
2019-07-26Introduce built-in macros through libcoreVadim Petrochenkov-2/+38
2019-07-22Remove uses of mem::uninitialized in std::sys::cloudabiNathan-0/+1
Usages still appear in cloudabi tests and in the reentrant mutex implementation
2019-07-19do not use mem::uninitialized in std::ioRalf Jung-0/+1
2019-07-19warn about deprecated-in-future in most of libstdRalf Jung-1/+1
2019-07-15Update the stdarch submodulegnzlbg-2/+2
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 08:54:23 +0000