-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Rollup of 16 pull requests #40616
Rollup of 16 pull requests #40616
Conversation
We don't want a dynamic dependency in the library that we ship, so link it statically by configuring curl-sys's build script to not pick up the system version via pkg-config.
Also update some 128 bit builtins to be panic-free without relying on the const evaluator.
Per discussion on the tracking issue, naming `TryFrom`'s associated type `Error` is generally more consistent with similar traits in the Rust ecosystem, and what people seem to assume it should be called. It also helps disambiguate from `Result::Err`, the most common "Err". See rust-lang#33417 (comment). TryFrom<&str> and FromStr are equivalent, so have the latter provide the former to ensure that. Using TryFrom in the implementation of `str::parse` means types that implement either trait can use it. When we're ready to stabilize `TryFrom`, we should update `FromStr` to suggest implementing `TryFrom<&str>` instead for new code. See rust-lang#33417 (comment) and rust-lang#33417 (comment). Refs rust-lang#33417.
This seems to match other uses of "be accessed" in the document.
…uron Rename TryFrom's associated type and implement str::parse using TryFrom. Per discussion on the tracking issue, naming `TryFrom`'s associated type `Error` is generally more consistent with similar traits in the Rust ecosystem, and what people seem to assume it should be called. It also helps disambiguate from `Result::Err`, the most common "Err". See rust-lang#33417 (comment). `TryFrom<&str>` and `FromStr` are equivalent, so have the latter provide the former to ensure that. Using `TryFrom` in the implementation of `str::parse` means types that implement either trait can use it. When we're ready to stabilize `TryFrom`, we should update `FromStr` to suggest implementing `TryFrom<&str>` instead for new code. See rust-lang#33417 (comment) and rust-lang#33417 (comment). Refs rust-lang#33417.
Update libc to 0.2.21 Update to include android aarch64 and x86 improvements.
…, r=nrc `TokenStream`-based attributes, paths in attribute and derive macro invocations This PR - refactors `Attribute` to use `Path` and `TokenStream` instead of `MetaItem`. - supports macro invocation paths for attribute procedural macros. - e.g. `#[::foo::attr_macro] struct S;`, `#[cfg_attr(all(), foo::attr_macro)] struct S;` - supports macro invocation paths for derive procedural macros. - e.g. `#[derive(foo::Bar, super::Baz)] struct S;` - supports arbitrary tokens as arguments to attribute procedural macros. - e.g. `#[foo::attr_macro arbitrary + tokens] struct S;` - supports using arbitrary tokens in "inert attributes" with derive procedural macros. - e.g. `#[derive(Foo)] struct S(#[inert arbitrary + tokens] i32);` where `#[proc_macro_derive(Foo, attributes(inert))]` r? @nrc
Propagate expected type hints through struct literals. Partial fix for rust-lang#31260 to maximize backwards-compatibility, i.e. the hint is provided but not coerced to. The added test works because `{...; x}` with a hint of `T` coerces `x` to `T`, and the reasoning why that is slightly different has to do with DSTs: `&Struct { tail: [x] }: &Struct<[T]>` has a hint of `[T]` for `[x]`, but the inferred type should be `[T; 1]` to succeed later, so `[x]` shouldn't be *forced* to be `[T]`. *However*, implementing that complete behavior in a backwards-compatible way may be non-trivial, and has not yet been fully investigated, while this PR fixes rust-lang#40355 and can be backported. r? @nikomatsakis
Specialize Vec::from_elem to use calloc Fixes rust-lang#38723. This specializes the implementation for `u8` only, but it could be extended to other zeroable types if desired. I haven't tested this extensively, but I did verify that it gives the expected performance boost for large `vec![0; n]` allocations with both alloc_system and jemalloc, on Linux. (I have not tested or even built the Windows code.)
Target builds for older macOS Fix rust-lang#40481
travis: Ensure cargo links libcurl statically We don't want a dynamic dependency in the library that we ship, so link it statically by configuring curl-sys's build script to not pick up the system version via pkg-config.
Implemente overflowing_sh* with new unchecked_sh* intrinsics Also update some 128 bit builtins to not rely on the constant evaluator to avoid checked operations. Fixes rust-lang#40508. cc @nagisa, @alexcrichton Note: I still have a build running to see if the 128 bit changes worked (unoptimized builds take *forever* to compile), however at least the overflowing builtins no longer reference `core::panicking::panic`.
Library stabilizations for 1.17 Details of the stabilizations are available in the commits. Includes only library stabilizations; there are a couple of compiler stabilizations that should also be done for 1.17. Will need a beta backport, which I will create after approval. r? @alexcrichton
Remove unused param from bootstrap::clean::rm_rf None
…wsxcv Fix const not displayed in rustdoc Fixes rust-lang#40331. r? @rust-lang/docs
…ion, r=nrc macros: fix regression with `include!()` Fixes rust-lang#40469, a regression when `include!()`ing a `macro_rules!` containing `$crate`. r? @nrc
…excrichton Add a test for issue 34571 Closes rust-lang#34571.
documented order of conversion between u32 an ipv4addr This fixes rust-lang#40118
…uillaumeGomez minor wording tweak to slice::{as_ptr, as_mut_ptr} Per rust-lang#37334, the slice-as-pointer methods mentioned that "modifying the slice may cause its buffer to be reallocated", when in fact modifying the *slice* itself would cause no such change. (It is a borrow, after all!) This is a tweak to the wording of that line to stress it's the *collection* that could cause the buffer to be reallocated. r? @steveklabnik
Fix typo in mutex.rs docs This seems to match other uses of "be accessed" in the document.
@bors r+ p=10 |
📌 Commit f6c8a9d has been approved by |
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nrc (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
⌛ Testing commit f6c8a9d with merge 09adacd... |
💔 Test failed - status-appveyor |
TokenStream
-based attributes, paths in attribute and derive macro invocations #40346, Propagate expected type hints through struct literals. #40398, Specialize Vec::from_elem to use calloc #40409, Target builds for older macOS #40482, travis: Ensure cargo links libcurl statically #40507, Implemente overflowing_sh* with new unchecked_sh* intrinsics #40521, Library stabilizations for 1.17 #40538, Remove unused param from bootstrap::clean::rm_rf #40562, Fix const not displayed in rustdoc #40564, macros: fix regression withinclude!()
#40583, Add a test for issue 34571 #40588, documented order of conversion between u32 an ipv4addr #40590, minor wording tweak to slice::{as_ptr, as_mut_ptr} #40603, Fix typo in mutex.rs docs #40611