| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit 6810f5286b6b91daab06fc3dccb27d8c46f14349, reversing
changes made to 8586ec6980462c99a8926646201b2444d8938d29.
|
|
Move std::os::raw::c_void into libcore and re-export in libstd
Implements the first part of [RFC 2521](https://github.com/rust-lang/rfcs/pull/2521).
cc #53856
|
|
stabilize slice_align_to
This is very hard to implement correctly, and leads to [serious bugs](https://github.com/llogiq/bytecount/pull/42) when done incorrectly. Moreover, this is needed to be able to run code that opportunistically exploits alignment on miri. So code using `align_to`/`align_to_mut` gets the benefit of a well-tested implementation *and* of being able to run in miri to test for (some kinds of) UB.
This PR also clarifies the guarantee wrt. the middle part being as long as possible. Should the docs say under which circumstances the middle part could be shorter? Currently, that can only happen when running in miri.
|
|
|
|
Add forever unstable attribute to allow specifying arbitrary scalar ranges
r? @eddyb for the first commit and @nikomatsakis for the second one
|
|
Add a implementation of `From` for converting `&'a Option<T>` into `Option<&'a T>`
I'm not sure if any annotations regarding the stabilization are needed or in general what's the correct process of adding such an impl.
cc @sgrif (We have talked about this)
|
|
stabilize outlives requirements
https://github.com/rust-lang/rust/issues/44493
r? @nikomatsakis
|
|
Implemented map_or_else for Result<T, E>
Fulfills #53268
The example is ripped from `Option::map_or_else`, with the types corrected.
|
|
Co-authored-by: nikomatsakis
|
|
|
|
|
|
|
|
r=Mark-Simulacrum,QuietMisdreavus
Trait impl show docs
Fixes #51834.
<img width="1440" alt="screen shot 2018-06-29 at 00 14 33" src="https://user-images.githubusercontent.com/3050060/42063323-6e6e8cc8-7b31-11e8-88ef-4dd2229df76c.png">
(You can see both commit changes in the screenshot 😄)
r? @QuietMisdreavus
|
|
alexcrichton:remove-repr-transparent-atomics-master, r=sfackler
Remove `#[repr(transparent)]` from atomics
Added in #52149 the discussion in #53514 is showing how we may not want to
actually add this attribute to the atomic types. While we continue to
debate #53514 this commit reverts the addition of the `transparent` attribute.
This should be a more conservative route which leaves us the ability to tweak
this in the future but in the meantime allows us to continue discussion as well.
|
|
Clarify `ManuallyDrop` docs
Mention that you can use `into_inner` to drop the contained value.
|
|
Individual docs for {from,to}_*_bytes
|
|
Updated core/macros.rs to note it works in a no_std environment.
Fixes #45797
This PR updates the documentation of `write!` to note it works in a `no_std` environment, and adds an
example to showcase this. In a `no_std` environment, the author of the code is responsible for the
implementation of the `Write` trait. This example will work out of the box with `no_std`, but the
implementation of `Write` is expected to be provided by the user.
r? @steveklabnik
|
|
|
|
Add trim_start, trim_end etc.; deprecate trim_left, trim_right, etc. in future
Adds the methods: `trim_start`, `trim_end`, `trim_start_matches` and `trim_end_matches`.
Deprecates `trim_left`, `trim_right`, `trim_left_matches` and `trim_right_matches` starting from Rust 1.33.0, three versions from when they'll initially be marked as being deprecated, using the future deprecation from https://github.com/rust-lang/rust/issues/30785 and https://github.com/rust-lang/rust/pull/51681.
Fixes https://github.com/rust-lang/rust/issues/30459.
|
|
Added in #52149 the discussion in #53514 is showing how we may not want to
actually add this attribute to the atomic types. While we continue to
debate #53514 this commit reverts the addition of the `transparent` attribute.
This should be a more conservative route which leaves us the ability to tweak
this in the future but in the meantime allows us to continue discussion as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Mention that you can use `into_inner` to drop the contained value.
|
|
Link to more detailed docs in `slice::from_raw_parts_mut`
|
|
Add more const int ops
r? @oli-obk
Tracking Issue: #53718
list of `const fn`s in this PR:
- `feature = const_int_rotate`
- `rotate_left`
- `rotate_right`
- `feature = const_int_wrapping`
- `wrapping_add`
- `wrapping_sub`
- `wrapping_mul`
- `wrapping_shl`
- `wrapping_shr`
- `feature = const_int_overflowing`
- `overflowing_add`
- `overflowing_sub`
- `overflowing_mul`
- `overflowing_shl`
- `overflowing_shr`
- `feature = const_int_sign`
- `is_positive`
- `is_negative`
- `feature = const_int_conversion`
- `reverse_bits`
- `to_le_bytes`
- `to_ne_bytes`
- `from_be_bytes`
- `from_le_bytes`
- `from_ne_bytes`
- `reverse_bits`
|
|
|
|
|
|
use char pattern for single-character splits: a.split("x") -> a.split('x')
|
|
Rollup of 9 pull requests
Successful merges:
- #53076 (set cfg(rustdoc) when rustdoc is running on a crate)
- #53622 (cleanup: Add main functions to some UI tests)
- #53769 (Also link Clippy repo in the CONTRIBUTING.md file)
- #53774 (Add rust-gdbgui script.)
- #53781 (bench: libcore: fix build failure of any.rs benchmark (use "dyn Any"))
- #53782 (Make Arc cloning mechanics clearer in module docs)
- #53790 (Add regression test for issue #52060)
- #53801 (Prevent duplicated impl on foreign types)
- #53850 (Nuke the `const_to_allocation` query)
|
|
set cfg(rustdoc) when rustdoc is running on a crate
When using `#[doc(cfg)]` to document platform-specific items, it's a little cumbersome to get all the platforms' items to appear all at once. For example, the standard library adds `--cfg dox` to rustdoc's command line whenever it builds docs, and the documentation for `#![feature(doc_cfg)]` suggests using a Cargo feature to approximate the same thing. This is a little awkward, because you always need to remember to set `--features dox` whenever you build documentation.
This PR proposes making rustdoc set `#[cfg(rustdoc)]` whenever it runs on a crate, to provide an officially-sanctioned version of this that is set automatically. This way, there's a standardized way to declare that a certain version of an item is specifically when building docs.
To try to prevent the spread of this feature from happening too quickly, this PR also restricts the use of this flag to whenever `#![feature(doc_cfg)]` is active. I'm sure there are other uses for this, but right now i'm tying it to this feature. (If it makes more sense to give this its own feature, i can easily do that.)
|
|
bench: libcore: fix build failure of any.rs benchmark (use "dyn Any")
fixes
````
error: trait objects without an explicit `dyn` are deprecated
--> libcore/../libcore/benches/any.rs:18:36
|
18 | let mut y = &mut x as &mut Any;
| ^^^ help: use `dyn`: `dyn Any`
|
= note: requested on the command line with `-D bare-trait-objects`
````
|
|
|
|
Implement the `min_const_fn` feature gate
cc @RalfJung @eddyb
r? @Centril
implements the feature gate for #53555
I added a hack so the `const_fn` feature gate also enables the `min_const_fn` feature gate. This ensures that nightly users of `const_fn` don't have to touch their code at all.
The `min_const_fn` checks are run first, and if they succeeded, the `const_fn` checks are run additionally to ensure we didn't miss anything.
|
|
fix u32 steps_between for 16-bit systems
This fixes #48006.
|
|
|
|
|
|
Fix a comment in src/libcore/slice/mod.rs
|
|
Add partialeq implementation for TryFromIntError type
Fixes #53458.
|
|
r=QuietMisdreavus
Add another PartialEq example
r? @steveklabnik
|
|
|
|
|
|
|
|
map_or_else is now correctly labelled unstable and points to the
tracking issue on rust-lang/rust
|
