about summary refs log tree commit diff
path: root/library/std/src/lib.rs
AgeCommit message (Collapse)AuthorLines
2021-02-26Rollup merge of #81940 - jhpratt:stabilize-str_split_once, r=m-ou-seGuillaume Gomez-1/+0
Stabilize str_split_once Closes #74773
2021-02-25Convert primitives to use intra-doc linksJoshua Nelson-6/+6
2021-02-25Add {core,std}::prelude::{rust_2015,rust_2018,rust_2021}.Mara Bos-0/+1
rust_2015 and rust_2018 are just re-exports of v1. rust_2021 is a module that for now just re-exports everything from v1, such that we can add more things later.
2021-02-24Constify methods of `std::net::SocketAddr`, `SocketAddrV4` and `SocketAddrV6`Christiaan Dirkx-0/+1
The following methods are made unstable const under the `const_socketaddr` feature: `SocketAddr` - `ip` - `port` - `is_ipv4` - `is_ipv6` `SocketAddrV4` - `ip` - `port` `SocketAddrV6` - `ip` - `port` - `flowinfo` - `scope_id`
2021-02-23Use #[doc = include_str!()] in stdLeSeulArtichaut-1/+0
2021-02-23Auto merge of #82076 - jyn514:update-bootstrap, r=Mark-Simulacrumbors-2/+2
Update the bootstrap compiler This updates the bootstrap compiler, notably leaving out a change to enable semicolon in macro expressions lint, because stdarch still depends on the old behavior.
2021-02-22Rollup merge of #82228 - ijackson:nonzero-cint, r=KodrAusYuki Okushi-0/+1
Provide NonZero_c_* integers I'm pretty sure I am going want this for #73125 and it seems like an omission that would be in any case good to remedy. <strike>Because the raw C types are in `std`, not `core`, to achieve this we must export the relevant macros from `core` so that `std` can use them. That's done with a new `num_internals` perma-unstable feature. The macros need to take more parameters for the module to get the types from and feature attributes to use. I have eyeballed the docs output for core, to check that my changes to these macros have made no difference to the core docs output.</strike>
2021-02-20Update the bootstrap compilerJoshua Nelson-2/+2
Note this does not change `core::derive` since it was merged after the beta bump.
2021-02-18Stabilize `unsafe_op_in_unsafe_fn` lintLeSeulArtichaut-1/+1
2021-02-18Auto merge of #81172 - SimonSapin:ptr-metadata, r=oli-obkbors-0/+1
Implement RFC 2580: Pointer metadata & VTable RFC: https://github.com/rust-lang/rfcs/pull/2580 ~~Before merging this PR:~~ * [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278). * [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513 * [x] Update `#[unstable]` attributes in the PR with the tracking issue number ---- This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts, parameters can be assumed to implement it without a corresponding bound. For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals, so careful review is appreciated. This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`: ```rust pub trait Pointee { /// One of `()`, `usize`, or `DynMetadata<dyn SomeTrait>` type Metadata: Copy + Send + Sync + Ord + Hash + Unpin; } pub trait Thin = Pointee<Metadata = ()>; pub const fn metadata<T: ?Sized>(ptr: *const T) -> <T as Pointee>::Metadata {} pub const fn from_raw_parts<T: ?Sized>(*const (), <T as Pointee>::Metadata) -> *const T {} pub const fn from_raw_parts_mut<T: ?Sized>(*mut (),<T as Pointee>::Metadata) -> *mut T {} impl<T: ?Sized> NonNull<T> { pub const fn from_raw_parts(NonNull<()>, <T as Pointee>::Metadata) -> NonNull<T> {} /// Convenience for `(ptr.cast(), metadata(ptr))` pub const fn to_raw_parts(self) -> (NonNull<()>, <T as Pointee>::Metadata) {} } impl<T: ?Sized> *const T { pub const fn to_raw_parts(self) -> (*const (), <T as Pointee>::Metadata) {} } impl<T: ?Sized> *mut T { pub const fn to_raw_parts(self) -> (*mut (), <T as Pointee>::Metadata) {} } /// `<dyn SomeTrait as Pointee>::Metadata == DynMetadata<dyn SomeTrait>` pub struct DynMetadata<Dyn: ?Sized> { // Private pointer to vtable } impl<Dyn: ?Sized> DynMetadata<Dyn> { pub fn size_of(self) -> usize {} pub fn align_of(self) -> usize {} pub fn layout(self) -> crate::alloc::Layout {} } unsafe impl<Dyn: ?Sized> Send for DynMetadata<Dyn> {} unsafe impl<Dyn: ?Sized> Sync for DynMetadata<Dyn> {} impl<Dyn: ?Sized> Debug for DynMetadata<Dyn> {} impl<Dyn: ?Sized> Unpin for DynMetadata<Dyn> {} impl<Dyn: ?Sized> Copy for DynMetadata<Dyn> {} impl<Dyn: ?Sized> Clone for DynMetadata<Dyn> {} impl<Dyn: ?Sized> Eq for DynMetadata<Dyn> {} impl<Dyn: ?Sized> PartialEq for DynMetadata<Dyn> {} impl<Dyn: ?Sized> Ord for DynMetadata<Dyn> {} impl<Dyn: ?Sized> PartialOrd for DynMetadata<Dyn> {} impl<Dyn: ?Sized> Hash for DynMetadata<Dyn> {} ``` API differences from the RFC, in areas noted as unresolved questions in the RFC: * Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T`, following the precedent of `null`, `slice_from_raw_parts`, etc. * Added `to_raw_parts`
2021-02-17Provide NonZero_c_* integersIan Jackson-0/+1
I'm pretty sure I am going want this for #73125 and it seems like an omission that would be in any case good to remedy. It's a shame we don't have competent token pasting and case mangling for use in macro_rules!. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-02-15Rollup merge of #82120 - sfackler:arguments-as-str, r=dtolnayJonas Schievink-1/+0
Stabilize Arguments::as_str Closes #74442
2021-02-15Fix intra-doc link to raw pointer methodSimon Sapin-0/+1
CC https://github.com/rust-lang/rust/pull/80181
2021-02-14Stabilize Arguments::as_strSteven Fackler-1/+0
Closes #74442
2021-02-10Seal the CommandExt, OsStrExt and OsStringExt traitsAmanieu d'Antras-0/+8
2021-02-09Stabilize str_split_onceJacob Pratt-1/+0
2021-02-03Stabilize the Wake traitYoshua Wuyts-2/+1
Co-Authored-By: Ashley Mannix <kodraus@hey.com>
2021-02-01Rollup merge of #78641 - the8472:buffered-copy, r=sfacklerJonas Schievink-0/+2
Let io::copy reuse BufWriter buffers This optimization will allow users to implicitly set the buffer size for io::copy by wrapping the writer into a `BufWriter` if the default block size is insufficient, which should fix #49921 Due to min_specialization limitations this approach only works with `BufWriter` but not for `BufReader<R>` since `R` is unconstrained and thus the necessary specialization on `R: Read` is not always applicable. Once specialization becomes more powerful this optimization could be extended to look at the reader and writer side and use whichever buffer is larger.
2021-02-01Auto merge of #80851 - m-ou-se:panic-2021, r=petrochenkovbors-0/+1
Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std, core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.
2021-01-31specialize io::copy to use the memory of the writer if it is a BufWriterThe8472-0/+2
2021-01-30Rollup merge of #80886 - RalfJung:stable-raw-ref-macros, r=m-ou-seYuki Okushi-1/+0
Stabilize raw ref macros This stabilizes `raw_ref_macros` (https://github.com/rust-lang/rust/issues/73394), which is possible now that https://github.com/rust-lang/rust/issues/74355 is fixed. However, as I already said in https://github.com/rust-lang/rust/issues/73394#issuecomment-751342185, I am not particularly happy with the current names of the macros. So I propose we also change them, which means I am proposing to stabilize the following in `core::ptr`: ```rust pub macro const_addr_of($e:expr) { &raw const $e } pub macro mut_addr_of($e:expr) { &raw mut $e } ``` The macro name change means we need another round of FCP. Cc `````@rust-lang/libs````` Fixes #73394
2021-01-30Rollup merge of #79023 - yoshuawuyts:stream, r=KodrAusYuki Okushi-0/+3
Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet, but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html), [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html), and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as "infinite streams" and "laziness" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = "future_trait"]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate, with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization, as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream, Next}` and re-exports it from `std` as `std::stream::{Stream, Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````
2021-01-29rename raw_const/mut -> const/mut_addr_of, and stabilize themRalf Jung-1/+0
2021-01-25Implement new panic!() behaviour for Rust 2021.Mara Bos-0/+1
2021-01-24Rollup merge of #79174 - taiki-e:std-future, r=Mark-SimulacrumJonas Schievink-3/+2
Make std::future a re-export of core::future After 1a764a7ef59b9cb2eb31658625a6a7dacc3d819b, there are no `std::future`-specific items (except for `cfg(bootstrap)` items removed in 93eed402adbe9e7a532995500d50716d52eefee9). So, instead of defining `std` own module, we can re-export the `core::future` directly.
2021-01-22Add `core::stream::Stream`Yoshua Wuyts-0/+3
This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with RFC2996. Add feedback from @camelid
2021-01-20Deprecate-in-future the constants superceded by RFC 2700bstrie-0/+12
2021-01-07Auto merge of #77853 - ijackson:slice-strip-stab, r=Amanieubors-1/+0
Stabilize slice::strip_prefix and slice::strip_suffix These two methods are useful. The corresponding methods on `str` are already stable. I believe that stablising these now would not get in the way of, in the future, extending these to take a richer pattern API a la `str`'s patterns. Tracking PR: #73413. I also have an outstanding PR to improve the docs for these two functions and the corresponding ones on `str`: #75078 I have tried to follow the [instructions in the dev guide](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr). The part to do with `compiler/rustc_feature` did not seem applicable. I assume that's because these are just library features, so there is no corresponding machinery in rustc.
2020-12-30Bump bootstrap compiler to 1.50 betaMark Rousskov-2/+1
2020-12-27Auto merge of #80181 - jyn514:intra-doc-primitives, r=Manishearthbors-2/+3
Fix intra-doc links for non-path primitives This does *not* currently work for associated items that are auto-implemented by the compiler (e.g. `never::eq`), because they aren't present in the source code. I plan to fix this in a follow-up PR. Fixes https://github.com/rust-lang/rust/issues/63351 using the approach mentioned in https://github.com/rust-lang/rust/issues/63351#issuecomment-683352130. r? `@Manishearth` cc `@petrochenkov` - this makes `rustc_resolve::Res` public, is that ok? I'd just add an identical type alias in rustdoc if not, which seems a waste.
2020-12-27Stablize slice::strip_prefix and strip_suffix, with SlicePatternIan Jackson-1/+0
We hope later to extend `core::str::Pattern` to slices too, perhaps as part of stabilising that. We want to minimise the amount of type inference breakage when we do that, so we don't want to stabilise strip_prefix and strip_suffix taking a simple `&[T]`. @KodrAus suggested the approach of introducing a new perma-unstable trait, which reduces this future inference break risk. I found it necessary to make two impls of this trait, as the unsize coercion don't apply when hunting for trait implementations. Since SlicePattern's only method returns a reference, and the whole trait is just a wrapper for slices, I made the trait type be the non-reference type [T] or [T;N] rather than the reference. Otherwise the trait would have a lifetime parameter. I marked both the no-op conversion functions `#[inline]`. I'm not sure if that is necessary but it seemed at the very least harmless. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2020-12-22Fix new ambiguity in the standard libraryJoshua Nelson-2/+3
This caught several bugs where people expected `slice` to link to the primitive, but it linked to the module instead. This also uses `cfg_attr(bootstrap)` since the ambiguity only occurs when compiling with stage 1.
2020-12-22Stabilize `core::slice::fill`Yoshua Wuyts-1/+0
2020-12-18Auto merge of #79485 - EllenNyan:stabilize_unsafe_cell_get_mut, r=m-ou-sebors-1/+0
Stabilize `unsafe_cell_get_mut` Tracking issue: #76943 r? `@m-ou-se`
2020-12-10Rollup merge of #79809 - Eric-Arellano:split-once, r=matkladTyler Mandry-0/+1
Dogfood `str_split_once()` Part of https://github.com/rust-lang/rust/issues/74773. Beyond increased clarity, this fixes some instances of a common confusion with how `splitn(2)` behaves: the first element will always be `Some()`, regardless of the delimiter, and even if the value is empty. Given this code: ```rust fn main() { let val = "..."; let mut iter = val.splitn(2, '='); println!("Input: {:?}, first: {:?}, second: {:?}", val, iter.next(), iter.next()); } ``` We get: ``` Input: "no_delimiter", first: Some("no_delimiter"), second: None Input: "k=v", first: Some("k"), second: Some("v") Input: "=", first: Some(""), second: Some("") ``` Using `str_split_once()` makes more clear what happens when the delimiter is not found.
2020-12-08Use Pin for the 'don't move' requirement of ReentrantMutex.Mara Bos-0/+2
The code in io::stdio before this change misused the ReentrantMutexes, by calling init() on them and moving them afterwards. Now that ReentrantMutex requires Pin for init(), this mistake is no longer easy to make.
2020-12-07Dogfood 'str_split_once()` in the std libEric Arellano-0/+1
2020-12-03Only deny doc_keyword in std and set it as "allow" by defaultGuillaume Gomez-0/+1
2020-12-02Auto merge of #69864 - LinkTed:master, r=Amanieubors-0/+1
unix: Extend UnixStream and UnixDatagram to send and receive file descriptors Add the functions `recv_vectored_fds` and `send_vectored_fds` to `UnixDatagram` and `UnixStream`. With this functions `UnixDatagram` and `UnixStream` can send and receive file descriptors, by using `recvmsg` and `sendmsg` system call.
2020-11-28Stabilize unsafe_cell_get_mutEllen-1/+0
2020-11-23Rename `optin_builtin_traits` to `auto_traits`Camelid-1/+2
They were originally called "opt-in, built-in traits" (OIBITs), but people realized that the name was too confusing and a mouthful, and so they were renamed to just "auto traits". The feature flag's name wasn't updated, though, so that's what this PR does. There are some other spots in the compiler that still refer to OIBITs, but I don't think changing those now is worth it since they are internal and not particularly relevant to this PR. Also see <https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/opt-in.2C.20built-in.20traits.20(auto.20traits).20feature.20name>.
2020-11-22Auto merge of #79319 - m-ou-se:rollup-d9n5viq, r=m-ou-sebors-2/+0
Rollup of 10 pull requests Successful merges: - #76941 (Add f{32,64}::is_subnormal) - #77697 (Split each iterator adapter and source into individual modules) - #78305 (Stabilize alloc::Layout const functions) - #78608 (Stabilize refcell_take) - #78793 (Clean up `StructuralEq` docs) - #79267 (BTreeMap: address namespace conflicts) - #79293 (Add test for eval order for a+=b) - #79295 (BTreeMap: fix minor testing mistakes in #78903) - #79297 (BTreeMap: swap the names of NodeRef::new and Root::new_leaf) - #79299 (Stabilise `then`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2020-11-22Rollup merge of #79299 - varkor:stabilise-then, r=m-ou-seMara Bos-1/+0
Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`), and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.
2020-11-22Auto merge of #79219 - shepmaster:beta-bump, r=Mark-Simulacrumbors-2/+1
Bump bootstrap compiler version r? `@Mark-Simulacrum` /cc `@pietroalbini`
2020-11-22Stabilize refcell_takeThinkChaos-1/+0
2020-11-22Stabilise `then`varkor-1/+0
2020-11-22Auto merge of #77872 - Xaeroxe:stabilize-clamp, r=scottmcmbors-1/+0
Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?
2020-11-19Bump bootstrap compiler versionJake Goulding-2/+1
2020-11-19Make std::future a re-export of core::futureTaiki Endo-3/+2
2020-11-17Auto merge of #78924 - bjorn3:less_sysroot_build_scripts, r=Mark-Simulacrumbors-1/+1
Make the libstd build script smaller Of all sysroot crates currently only compiler_builtins, miniz_oxide and std require a build script. compiler_builtins uses to conditionally enable certain features and possibly compile a C version ([source](https://github.com/rust-lang/compiler-builtins/blob/63ccaf11f08fb5d0b39cc33884c5a1a63f547ace/build.rs)), miniz_oxide only uses it to detect if liballoc is supported as the MSRV is 1.34.0 instead of the 1.36.0 which stabilized liballoc ([source](https://github.com/Frommi/miniz_oxide/blob/28514ec09f0b1ce74bfb2d561de52a6652ce377a/miniz_oxide/build.rs)). std now only uses it to enable `freebsd12` when the `RUST_STD_FREEBSD_12_ABI` env var is set, to determine if `restricted-std` should be set, to set the `STD_ENV_ARCH` env var identical to `CARGO_CFG_TARGET_ARCH`, and to unconditionally enable `backtrace_in_libstd`. If all build scripts were to be removed, it would be possible for rustc to completely compile it's own sysroot. It currently requires a rustc version that already has an available libstd to compile the build scripts. If rustc can completely compile it's own sysroot, rustbuild could be simplified to not forcefully use the bootstrap compiler for build scripts. `@rustbot` modify labels: +T-compiler +libs-impl
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 01:41:11 +0000