-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rolling up PRs in the queue #20145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Rolling up PRs in the queue #20145
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Take the docs from Rc<T>, apply them to Arc<T>, and fix some line lengths.
Disambiguate maximally by using 'and' instead of '&' next to discussion about references. As a bonus, fix the spelling of the car too.
This narrows the definition of nested returns such that only when the outer return has a chance of being executed (due to the inner return being conditional) do we mark the function as having nested returns. Fixes rust-lang#19684
There is currently no way to specify the stability level for a trait impl produced by `deriving`. This patch is a stopgap solution that: * Turns of stability inheritance for trait impls, and * Uses the stability level of the *trait* if no level is directly specified. That is, manual trait impls may still provide a directly stability level, but `deriving` will use the level of the trait. While not a perfect solution, it should be good enough for 1.0 API stabilization, as we will like *remove* any unwanted impls outright.
The use of `+a+x` is deprecated. Fixes rust-lang#19981.
The current indentation level would indicate that Boolean literals are on the same level as Integer and Float literals under Number literals, unindenting moves it to the same scope as Character and string literals, Byte and byte string literals, and Number literals under Literals.
This commit modifies rustdoc to not require these empty modules to be public in the standard library. The modules still remain as a location to attach documentation to, but the modules themselves are now private (don't have to commit to an API). The documentation for the standard library now shows all of the primitive types on the main index page.
…aring. It is useful to move all the elements out of some collections without deallocating the underlying buffer. It came up in IRC, and this patch implements it as `drain`. This has been discussed as part of RFC 509. r? @gankro cc: @frankmcsherry
Part of rust-lang#18424 This commit changes the semantics of `reserve` and `capacity` for Bitv and BitvSet to match conventions. It also introduces the notion of `reserve_index` and `reserve_index_exact` for collections with maximum-index-based capacity semantics. Deprecates free function constructors in favour of functions on Bitv itself. Changes `Bitv::pop` to return an Option rather than panicking. Deprecates and renames several methods in favour of conventions. Marks several blessed methods as unstable. This commit also substantially refactors Bitv and BitvSet's implementations. The new implementation is simpler, cleaner, better documented, and more robust against overflows. It also reduces coupling between Bitv and BitvSet. Tests have been seperated into seperate submodules. Fixes rust-lang#16958 [breaking-change]
This commit starts out by consolidating all `str` extension traits into one `StrExt` trait to be included in the prelude. This means that `UnicodeStrPrelude`, `StrPrelude`, and `StrAllocating` have all been merged into one `StrExt` exported by the standard library. Some functionality is currently duplicated with the `StrExt` present in libcore. This commit also currently avoids any methods which require any form of pattern to operate. These functions will be stabilized via a separate RFC. Next, stability of methods and structures are as follows: Stable * from_utf8_unchecked * CowString - after moving to std::string * StrExt::as_bytes * StrExt::as_ptr * StrExt::bytes/Bytes - also made a struct instead of a typedef * StrExt::char_indices/CharIndices - CharOffsets was renamed * StrExt::chars/Chars * StrExt::is_empty * StrExt::len * StrExt::lines/Lines * StrExt::lines_any/LinesAny * StrExt::slice_unchecked * StrExt::trim * StrExt::trim_left * StrExt::trim_right * StrExt::words/Words - also made a struct instead of a typedef Unstable * from_utf8 - the error type was changed to a `Result`, but the error type has yet to prove itself * from_c_str - this function will be handled by the c_str RFC * FromStr - this trait will have an associated error type eventually * StrExt::escape_default - needs iterators at least, unsure if it should make the cut * StrExt::escape_unicode - needs iterators at least, unsure if it should make the cut * StrExt::slice_chars - this function has yet to prove itself * StrExt::slice_shift_char - awaiting conventions about slicing and shifting * StrExt::graphemes/Graphemes - this functionality may only be in libunicode * StrExt::grapheme_indices/GraphemeIndices - this functionality may only be in libunicode * StrExt::width - this functionality may only be in libunicode * StrExt::utf16_units - this functionality may only be in libunicode * StrExt::nfd_chars - this functionality may only be in libunicode * StrExt::nfkd_chars - this functionality may only be in libunicode * StrExt::nfc_chars - this functionality may only be in libunicode * StrExt::nfkc_chars - this functionality may only be in libunicode * StrExt::is_char_boundary - naming is uncertain with container conventions * StrExt::char_range_at - naming is uncertain with container conventions * StrExt::char_range_at_reverse - naming is uncertain with container conventions * StrExt::char_at - naming is uncertain with container conventions * StrExt::char_at_reverse - naming is uncertain with container conventions * StrVector::concat - this functionality may be replaced with iterators, but it's not certain at this time * StrVector::connect - as with concat, may be deprecated in favor of iterators Deprecated * StrAllocating and UnicodeStrPrelude have been merged into StrExit * eq_slice - compiler implementation detail * from_str - use the inherent parse() method * is_utf8 - call from_utf8 instead * replace - call the method instead * truncate_utf16_at_nul - this is an implementation detail of windows and does not need to be exposed. * utf8_char_width - moved to libunicode * utf16_items - moved to libunicode * is_utf16 - moved to libunicode * Utf16Items - moved to libunicode * Utf16Item - moved to libunicode * Utf16Encoder - moved to libunicode * AnyLines - renamed to LinesAny and made a struct * SendStr - use CowString<'static> instead * str::raw - all functionality is deprecated * StrExt::into_string - call to_string() instead * StrExt::repeat - use iterators instead * StrExt::char_len - use .chars().count() instead * StrExt::is_alphanumeric - use .chars().all(..) * StrExt::is_whitespace - use .chars().all(..) Pending deprecation -- while slicing syntax is being worked out, these methods are all #[unstable] * Str - while currently used for generic programming, this trait will be replaced with one of [], deref coercions, or a generic conversion trait. * StrExt::slice - use slicing syntax instead * StrExt::slice_to - use slicing syntax instead * StrExt::slice_from - use slicing syntax instead * StrExt::lev_distance - deprecated with no replacement Awaiting stabilization due to patterns and/or matching * StrExt::contains * StrExt::contains_char * StrExt::split * StrExt::splitn * StrExt::split_terminator * StrExt::rsplitn * StrExt::match_indices * StrExt::split_str * StrExt::starts_with * StrExt::ends_with * StrExt::trim_chars * StrExt::trim_left_chars * StrExt::trim_right_chars * StrExt::find * StrExt::rfind * StrExt::find_str * StrExt::subslice_offset
This commit completes the deprecation story for the in-tree serialization library. The compiler will now emit a warning whenever it encounters `deriving(Encodable)` or `deriving(Decodable)`, and the library itself is now marked `#[unstable]` for when feature staging is enabled. All users of serialization can migrate to the `rustc-serialize` crate on crates.io which provides the exact same interface as the libserialize library in-tree. The new deriving modes are named `RustcEncodable` and `RustcDecodable` and require `extern crate "rustc-serialize" as rustc_serialize` at the crate root in order to expand correctly. To migrate all crates, add the following to your `Cargo.toml`: [dependencies] rustc-serialize = "0.1.1" And then add the following to your crate root: extern crate "rustc-serialize" as rustc_serialize; Finally, rename `Encodable` and `Decodable` deriving modes to `RustcEncodable` and `RustcDecodable`. [breaking-change]
This pull request: *Renames `BinaryHeap::top` to `BinaryHeap::peek` *Stabilizes `front/back/front_mut/back_mut` in `DList` and `RingBuf` *Stabilizes `swap` in `RingBuf` in accordance with rust-lang/rfcs#509. Note that this PR does not address `Bitv::{get,set}` or HashMap's iterators, nor does it move `std::vec` to `std::collections::vec`, all of which still need to be done. Because of the method renaming, this is a [breaking-change].
Internally refactor all mentions of `notrust` to the positive statement `rust`. [breaking-change] Change remaining `notrust` markers to the thing they actually represent, e.g. `sh` or `plain`. This supersedes rust-lang#19693 .
That sentence made it look like there was no option for using 'mut'
Now that rust-lang#19448 has landed in a snapshot, we can add proper by-value operator overloads for `HashSet`. The behavior of these operator overloads is consistent with rust-lang/rfcs#235.
This pull request updates the rustc manual page to represent current state of rustc option handling better. Moved the apparently deprecated options (rust-lang#19900) to their own section and added all the new codegen options. A bit unrelatedly, I also updated description of `-O` and `-g` flags to point to the new codegen options rather than old, deprecated ones. Fixes rust-lang#20111.
…entry This is an updated version of rust-lang#19711. The merge and subsequent rebase on that branch were more trouble than they were worth, so I am just resubmitting the relevant change here. If this PR is accepted, then rust-lang#19711 can be closed. /cc @gankro
Part of rust-lang#19253 I would have removed this public reexport in rust-lang#19842, but rust-lang#19812 hadn't merged (and snapshotted) at the time In rust-lang#19407, I changed the codebase to stop utilizing this reexport [breaking-change]
RFC 248? I think you meant RFC 438. There ain’t an RFC 248, while 438 looks to be what is being referred to: https://github.com/rust-lang/rfcs/blob/master/text/0438-precedence-of-plus.md -------------- Chis Morgan has a pretty important documentation fix in rust-lang#19385 and he hasn't responded in a while to that pull request so I rebased it for him Closes rust-lang#19385
Conflicts: src/libcollections/bit.rs src/libcore/str.rs
Conflicts: src/libcore/str.rs src/librustc_trans/trans/closure.rs src/librustc_typeck/collect.rs src/libstd/path/posix.rs src/libstd/path/windows.rs
Conflicts: src/librustc/session/config.rs src/librustc_driver/lib.rs src/librustc_driver/pretty.rs
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
🚋 💨 |
…cape Conflicts: src/libserialize/json.rs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.