about summary refs log tree commit diff
path: root/src/libstd/lib.rs
AgeCommit message (Collapse)AuthorLines
2018-08-26Auto merge of #53619 - japaric:panic-handler, r=SimonSapinbors-1/+2
add #[panic_handler]; deprecate #[panic_implementation] r? @SimonSapin cc #44489
2018-08-24check that adding infer-outlives requirement to all crates worksNiko Matsakis-0/+1
2018-08-23Stabilize 'attr_literals' feature.Sergio Benitez-1/+0
2018-08-23add #[panic_handler]; deprecate #[panic_implementation]Jorge Aparicio-1/+2
2018-08-23move pin module to liballoc and reexport thatNiv Kaminer-1/+2
2018-08-23move PinMut into pin module and export through stdNiv Kaminer-0/+1
2018-08-19Stabilize macro_vis_matcherJakub Kozlowski-1/+1
2018-08-17Stabilize `use_extern_macros`Vadim Petrochenkov-1/+1
2018-08-15Make std::io::Error #[non_exhaustive]varkor-0/+1
2018-08-10[nll] libstd: enable feature(nll) for bootstrapmemoryruins-0/+1
2018-08-08Move IPs to assoc constsLinus Färnstrand-0/+1
2018-08-08Make Ipv{4,6}Addr::new const fnsLinus Färnstrand-0/+2
2018-08-05Remove bad features after rebasevarkor-1/+0
2018-08-05Fix stage 2 testsvarkor-1/+1
2018-08-05Remove unnecessary or invalid feature attributesvarkor-17/+1
2018-07-20Update stdsimd to undo an accidental stabilizationAlex Crichton-4/+0
Closes #52403
2018-07-09Implement #[alloc_error_handler]Simon Sapin-1/+2
This to-be-stable attribute is equivalent to `#[lang = "oom"]`. It is required when using the alloc crate without the std crate. It is called by `handle_alloc_error`, which is in turned called by "infallible" allocations APIs such as `Vec::push`.
2018-06-30Bootstrap from 1.28.0-beta.3Mark Simulacrum-4/+1
2018-06-22Review nits and updatesTaylor Cramer-17/+18
Move future_from_generator out of raw Update await to use $crate Renumber errors
2018-06-21async await desugaring and testsTaylor Cramer-2/+2
2018-06-15Add doc for fn keywordGuillaume Gomez-0/+5
2018-06-12Auto merge of #51241 - glandium:globalalloc, r=sfackler,SimonSapinbors-8/+0
Stabilize GlobalAlloc and #[global_allocator] This PR implements the changes discussed in https://github.com/rust-lang/rust/issues/49668#issuecomment-393263510 Fixes #49668 Fixes #27389 This does not change the default global allocator: #36963
2018-06-11Remove some '#[feature]' attributes for stabilized featuresSimon Sapin-1/+0
2018-06-11Remove deprecated heap modulesSimon Sapin-7/+0
The heap.rs file was already unused.
2018-06-11Auto merge of #51442 - tinaun:more-future-impls, r=cramertjbors-0/+1
[futures] add a few blanket impls to std these were defined in the futures crate, but with the core definitions moving to std these would need to move too.
2018-06-11Add #[doc(inline)] in std::taskCrLF0710-0/+2
Add #[doc(inline)] in `std::task` to make the doc seem right.
2018-06-08add a few blanket future impls to stdtinaun-0/+1
2018-06-06Auto merge of #51263 - cramertj:futures-in-core, r=aturonbors-0/+16
Add Future and task system to the standard library This adds preliminary versions of the `std::future` and `std::task` modules in order to unblock development of async/await (https://github.com/rust-lang/rust/issues/50547). These shouldn't be considered as final forms of these libraries-- design questions about the libraries should be left on https://github.com/rust-lang/rfcs/pull/2418. Once that RFC (or a successor) is merged, these APIs will be adjusted as necessary. r? @aturon
2018-06-06Add Future and task system to the standard libraryTaylor Cramer-0/+16
2018-06-04Put doc keyword behind feature flagGuillaume Gomez-0/+1
2018-06-03implement #[panic_implementation]Jorge Aparicio-0/+2
2018-05-17Switch to 1.26 bootstrap compilerMark Simulacrum-8/+1
2018-05-16Stabilize num::NonZeroU*Simon Sapin-1/+0
Tracking issue: https://github.com/rust-lang/rust/issues/49137
2018-05-06Some final touches to ensure `./x.py test --stage 0 src/lib*` workskennytm-2/+2
2018-05-01Fix an error from "unused" lint + Fix rebaseVadim Petrochenkov-0/+1
2018-05-01Remove `macro_reexport`Vadim Petrochenkov-8/+8
It's subsumed by `feature(use_extern_macros)` and `pub use`
2018-04-24Rollup merge of #49906 - kennytm:stable-unreachable, r=sfacklerkennytm-0/+2
Stabilize `std::hint::unreachable_unchecked`. Closes #43751.
2018-04-22Replace GlobalAlloc::oom with a lang itemSteven Fackler-1/+2
2018-04-22Auto merge of #49757 - GuillaumeGomez:never-search, r=QuietMisdreavusbors-0/+1
Add specific never search Fixes #49529. r? @QuietMisdreavus
2018-04-22Auto merge of #49896 - SimonSapin:inherent, r=alexcrichtonbors-1/+2
Add inherent methods in libcore for [T], [u8], str, f32, and f64 # Background Primitive types are defined by the language, they don’t have a type definition like `pub struct Foo { … }` in any crate. So they don’t “belong” to any crate as far as `impl` coherence is concerned, and on principle no crate would be able to define inherent methods for them, without a trait. Since we want these types to have inherent methods anyway, the standard library (with cooperation from the compiler) bends this rule with code like [`#[lang = "u8"] impl u8 { /*…*/ }`](https://github.com/rust-lang/rust/blob/1.25.0/src/libcore/num/mod.rs#L2244-L2245). The `#[lang]` attribute is permanently-unstable and never intended to be used outside of the standard library. Each lang item can only be defined once. Before this PR there is one impl-coherence-rule-bending lang item per primitive type (plus one for `[u8]`, which overlaps with `[T]`). And so one `impl` block each. These blocks for `str`, `[T]` and `[u8]` are in liballoc rather than libcore because *some* of the methods (like `<[T]>::to_vec(&self) -> Vec<T> where T: Clone`) need a global memory allocator which we don’t want to make a requirement in libcore. Similarly, `impl f32` and `impl f64` are in libstd because some of the methods are based on FFI calls to C’s `libm` and we want, as much as possible, libcore not to require “runtime support”. In libcore, the methods of `str` and `[T]` that don’t allocate are made available through two **unstable traits** `StrExt` and `SliceExt` (so the traits can’t be *named* by programs on the Stable release channel) that have **stable methods** and are re-exported in the libcore prelude (so that programs on Stable can *call* these methods anyway). Non-allocating `[u8]` methods are not available in libcore: https://github.com/rust-lang/rust/issues/45803. Some `f32` and `f64` methods are in an unstable `core::num::Float` trait with stable methods, but that one is **not in the libcore prelude**. (So as far as Stable programs are concerns it doesn’t exist, and I don’t know what the point was to mark these methods `#[stable]`.) https://github.com/rust-lang/rust/issues/32110 is the tracking issue for these unstable traits. # High-level proposal Since the standard library is already bending the rules, why not bend them *a little more*? By defining a few additional lang items, the compiler can allow the standard library to have *two* `impl` blocks (in different crates) for some primitive types. The `StrExt` and `SliceExt` traits still exist for now so that we can bootstrap from a previous-version compiler that doesn’t have these lang items yet, but they can be removed in next release cycle. (`Float` is used internally and needs to be public for libcore unit tests, but was already `#[doc(hidden)]`.) I don’t know if https://github.com/rust-lang/rust/issues/32110 should be closed by this PR, or only when the traits are entirely removed after we make a new bootstrap compiler. # Float methods Among the methods of the `core::num::Float` trait, three are based on LLVM intrinsics: `abs`, `signum`, and `powi`. PR https://github.com/rust-lang/rust/pull/27823 “Remove dependencies on libm functions from libcore” moved a bunch of `core::num::Float` methods back to libstd, but left these three behind. However they aren’t specifically discussed in the PR thread. The `compiler_builtins` crate defines `__powisf2` and `__powidf2` functions that look like implementations of `powi`, but I couldn’t find a connection with the `llvm.powi.f32` and `llvm.powi.f32` intrinsics by grepping through LLVM’s code. In discussion starting at https://github.com/rust-lang/rust/issues/32110#issuecomment-370647922 Alex says that we do not want methods in libcore that require “runtime support”, but it’s not clear whether that applies to these `abs`, `signum`, or `powi`. In doubt, I’ve **removed** them for the trait and moved them to inherent methods in libstd for now. We can move them back later (or in this PR) if we decide that’s appropriate. # Change details For users on the Stable release channel: * I believe this PR does not make any breaking change * Some methods for `[u8]`, `f32`, and `f64` are newly available to `#![no_std]` users (fixes https://github.com/rust-lang/rust/issues/45803) * There should be no visible change for `std` users in terms of what programs compile or what their behavior is. (Only in compiler error messages, possibly.) For Nightly users, additionally: * The unstable `StrExt` and `SliceExt` traits are gone * Their methods are now inherent methods of `str` and `[T]` (so only code that explicitly named the traits should be affected, not "normal" method calls) * The `abs`, `signum` and `powi` methods of the `Float` trait are gone * The `Float` trait’s unstable feature name changed to `float_internals` with no associated tracking issue, to reflect it being a permanently unstable implementation detail rather than a public API on a path to stabilization. * Its remaining methods are now inherent methods of `f32` and `f64`. ----- CC @rust-lang/libs for the API changes, @rust-lang/compiler for the new lang items
2018-04-21Generate alias fileGuillaume Gomez-0/+1
2018-04-21Make the unstable StrExt and SliceExt traits private to libcore in not(stage0)Simon Sapin-1/+2
`Float` still needs to be public for libcore unit tests.
2018-04-20Revert "Stabilize the TryFrom and TryInto traits"Felix S. Klock II-0/+1
This reverts commit e53a2a72743810e05f58c61c9d8a4c89b712ad2e.
2018-04-20Revert stabilization of `feature(never_type)`.Felix S. Klock II-0/+1
This commit is just covering the feature gate itself and the tests that made direct use of `!` and thus need to opt back into the feature. A follow on commit brings back the other change that motivates the revert: Namely, going back to the old rules for falling back to `()`.
2018-04-18Auto merge of #50017 - tinaun:stabilize-all-the-things, r=sfacklerbors-1/+0
stabilize a bunch of minor api additions besides `ptr::NonNull::cast` (which is 4 days away from end of FCP) all of these have been finished with FCP for a few weeks now with minimal issues raised * Closes #41020 * Closes #42818 * Closes #44030 * Closes #44400 * Closes #46507 * Closes #47653 * Closes #46344 the following functions will be stabilized in 1.27: * `[T]::rsplit` * `[T]::rsplit_mut` * `[T]::swap_with_slice` * `ptr::swap_nonoverlapping` * `NonNull::cast` * `Duration::from_micros` * `Duration::from_nanos` * `Duration::subsec_millis` * `Duration::subsec_micros` * `HashMap::remove_entry`
2018-04-17Auto merge of #49542 - GuillaumeGomez:intra-link-resolution-error, ↵bors-2/+2
r=GuillaumeGomez Add warning if a resolution failed r? @QuietMisdreavus
2018-04-17stabilize `nonnull_cast` featuretinaun-1/+0
2018-04-17Auto merge of #49664 - alexcrichton:stable-simd, r=BurntSushibors-1/+1
Stabilize x86/x86_64 SIMD This commit stabilizes the SIMD in Rust for the x86/x86_64 platforms. Notably this commit is stabilizing: * The `std::arch::{x86, x86_64}` modules and the intrinsics contained inside. * The `is_x86_feature_detected!` macro in the standard library * The `#[target_feature(enable = "...")]` attribute * The `#[cfg(target_feature = "...")]` matcher Stabilization of the module and intrinsics were primarily done in rust-lang-nursery/stdsimd#414 and the two attribute stabilizations are done in this commit. The standard library is also tweaked a bit with the new way that stdsimd is integrated. Note that other architectures like `std::arch::arm` are not stabilized as part of this commit, they will likely stabilize in the future after they've been implemented and fleshed out. Similarly the `std::simd` module is also not being stabilized in this commit, only `std::arch`. Finally, nothing related to `__m64` is stabilized in this commit either (MMX), only SSE and up types and intrinsics are stabilized. Closes #29717 Closes #44839 Closes #48556
2018-04-16Add rustdoc-ui test suiteGuillaume Gomez-2/+2
2018-04-16Stabilize x86/x86_64 SIMDAlex Crichton-1/+1
This commit stabilizes the SIMD in Rust for the x86/x86_64 platforms. Notably this commit is stabilizing: * The `std::arch::{x86, x86_64}` modules and the intrinsics contained inside. * The `is_x86_feature_detected!` macro in the standard library * The `#[target_feature(enable = "...")]` attribute * The `#[cfg(target_feature = "...")]` matcher Stabilization of the module and intrinsics were primarily done in rust-lang-nursery/stdsimd#414 and the two attribute stabilizations are done in this commit. The standard library is also tweaked a bit with the new way that stdsimd is integrated. Note that other architectures like `std::arch::arm` are not stabilized as part of this commit, they will likely stabilize in the future after they've been implemented and fleshed out. Similarly the `std::simd` module is also not being stabilized in this commit, only `std::arch`. Finally, nothing related to `__m64` is stabilized in this commit either (MMX), only SSE and up types and intrinsics are stabilized. Closes #29717 Closes #44839 Closes #48556