summary refs log tree commit diff
path: root/src/libstd/lib.rs
AgeCommit message (Collapse)AuthorLines
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
2019-07-01Enable mem_take feature in relevant cratesChris Gregory-0/+1
2019-06-22Remove FnBox.Mazdak Farrokhzad-1/+0
2019-06-16Stabilize todo macroStjepan Glavina-1/+0
2019-06-10std: Remove internal definitions of `cfg_if!` macroAlex Crichton-0/+6
This is duplicated in a few locations throughout the sysroot to work around issues with not exporting a macro in libstd but still wanting it available to sysroot crates to define blocks. Nowadays though we can simply depend on the `cfg-if` crate on crates.io, allowing us to use it from there!
2019-06-03Fix cfg(test) build for x86_64-fortanix-unknown-sgxJethro Beekman-1/+2
2019-05-20stabilize core parts of MaybeUninit and deprecate mem::uninitialized in the ↵Ralf Jung-1/+0
future Also expand the documentation a bit
2019-05-09Fix cfg(test) build on SGXJethro Beekman-0/+1
2019-05-09Stabilize and re-export core::arrayYuki OKUSHI-1/+2
2019-04-26Remove feature gates from std and testsChristopher Serr-1/+0
2019-04-25Rollup merge of #60185 - NieDzejkob:int-error-kind-reexport, r=rkruppeMazdak Farrokhzad-0/+1
Reexport IntErrorKind in std Currently `IntErrorKind` can only be found in `core`. @Centril confirmed on Discord that this is unintentional (should I r? him in this situation?). Should there be a test for this? As far as this *specific* situation goes, I don't think so, I'll risk it and say that there's no way this regresses. However, it might be a good idea to have some tool detect public items in `core` that are not reexported in `std`. Does this belong in tidy, or should that be a separate tool? Is there some rustc-specific *linter*? Unless that's entirely a dumb idea, this should probably get an issue. Note: My local build hasn't finished yet, but it's well past the point where I would expect problems.
2019-04-23Stabilize futures_apiTaylor Cramer-7/+3
2019-04-23Reexport IntErrorKind in stdJakub Kądziołka-0/+1
2019-04-14make lint levels more consistentRalf Jung-3/+4
2019-04-12Stabilize the `alloc` crate.Simon Sapin-1/+0
This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783
2019-03-31libstd: deny(elided_lifetimes_in_paths)Mazdak Farrokhzad-1/+0
2019-03-18Add todo!() macroAleksey Kladov-1/+2
The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.
2019-03-16Rollup merge of #59152 - smmalis37:range_contains, r=SimonSapinkennytm-1/+1
Stabilize Range*::contains. Closes https://github.com/rust-lang/rust/issues/32311. There's also a bit of rustfmt on range.rs thrown in for good measure (I forgot to turn off format-on-save in VSCode).
2019-03-15Auto merge of #58710 - EdorianDark:master, r=sfacklerbors-0/+1
Add clamp for ranges. Implements #44095 Ready for merge
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 13:52:27 +0000