| Age | Commit message (Collapse) | Author | Lines |
|
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.
|
|
Copy the documentation over to `slice::from_raw_parts_mut`.
|
|
Fixes #53676.
|
|
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.)
|