about summary refs log tree commit diff
path: root/src/libstd/lib.rs
AgeCommit message (Collapse)AuthorLines
2020-02-15Rollup merge of #64069 - ↵Dylan DPC-0/+1
danielhenrymantilla:feature/cstring_from_vec_of_nonzerou8, r=KodrAus Added From<Vec<NonZeroU8>> for CString Added a `From<Vec<NonZeroU8>>` `impl` for `CString` # Rationale - `CString::from_vec_unchecked` is a subtle function, that makes `unsafe` code harder to audit when the generated `Vec`'s creation is non-trivial. This `impl` allows to write safer `unsafe` code thanks to the very explicit semantics of the `Vec<NonZeroU8>` type. - One such situation is when trying to `.read()` a `CString`, see issue #59229. - this lead to a PR: #59314, that was closed for being too specific / narrow (it only targetted being able to `.read()` a `CString`, when this pattern could have been generalized). - the issue suggested another route, based on `From<Vec<NonZeroU8>>`, which is indeed a less general and more concise code pattern. - quoting @shnatsel: - > For me the main thing about making this safe is simplifying auditing - people have spent like an hour looking at just this one unsafe block in libflate because it's not clear what exactly is unchecked, so you have to look it up when auditing anyway. This has distracted us from much more serious memory safety issues the library had. Having this trivial impl in stdlib would turn this into safe code with compiler more or less guaranteeing that it's fine, and save anyone auditing the code a whole lot of time.
2020-02-12Stabilize assoc_int_constsLinus Färnstrand-1/+0
2020-02-06Add primitive module to libcore/stdMark Rousskov-1/+4
This re-exports the primitive types from libcore at `core::primitive` to allow macro authors to have a reliable location to use them from.
2020-02-05Auto merge of #68755 - Tyg13:update_stdarch, r=alexcrichtonbors-6/+0
Update `rust-lang/stdarch` submodule Update submodule [rust-lang/stdarch](https://github.com/rust-lang/stdarch/)
2020-02-04Added From<Vec<NonZeroU8>> for CStringDaniel Henry-Mantilla-0/+1
Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com> Improved layout checks, type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com> Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead, then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments
2020-02-04Auto merge of #68708 - Mark-Simulacrum:stage0-step, r=pietroalbinibors-1/+0
Step stage0 to bootstrap from 1.42 This also includes a commit which fixes the rustfmt downloading logic to redownload when the rustfmt channel changes, and bumps rustfmt to a more recent version.
2020-02-03Rollup merge of #68797 - GuillaumeGomez:link-to-types, r=Dylan-DPCDylan DPC-2/+2
Fix links to types instead of modules r? @Dylan-DPC
2020-02-03Fix links to types instead of modulesGuillaume Gomez-2/+2
2020-02-01stdarch: update submodule.Tyler Lanphear-6/+0
2020-01-31Drop cfg(bootstrap) codeMark Rousskov-1/+0
2020-01-23Unlock assoc_int_consts in core+stdLinus Färnstrand-0/+1
2020-01-20Auto merge of #68066 - CAD97:stabilize-manuallydrop-take, ↵bors-1/+0
r=Amanieu,Mark-Simulacrum Stabilize ManuallyDrop::take Tracking issue: closes #55422 FCP merge: https://github.com/rust-lang/rust/issues/55422#issuecomment-572653619 Reclaims the doc improvements from closed #62198. ----- Stable version is a simple change if necessary. Proposal: [relnotes] (this changes how to best take advantage of `ManuallyDrop`, esp. wrt. `Drop::drop` and finalize-by-value members)
2020-01-18slice_patterns: remove internal uses of gateMazdak Farrokhzad-1/+1
2020-01-09stabalize ManuallyDrop::takeCAD97-1/+0
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 23:38:47 +0000