Skip to content
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 15 pull requests #40615

Closed
wants to merge 34 commits into from
Closed

Rollup of 15 pull requests #40615

wants to merge 34 commits into from

Conversation

eddyb and others added 30 commits March 9, 2017 21:05
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.
Now that we've also updated cargo's release process this commit also changes the
download location of Cargo from Cargos archives back to the static.r-l.o
archives. This should ensure that the Cargo download is the exact Cargo paired
with the rustc that we release.
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 commit deletes the internal liblog in favor of the implementation that
lives on crates.io. Similarly it's also setting a convention for adding crates
to the compiler. The main restriction right now is that we want compiler
implementation details to be unreachable from normal Rust code (e.g. requires a
feature), and by default everything in the sysroot is reachable via `extern
crate`.

The proposal here is to require that crates pulled in have these lines in their
`src/lib.rs`:

    #![cfg_attr(rustbuild, feature(staged_api, rustc_private))]
    #![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))]

This'll mean that by default they're not using these attributes but when
compiled as part of the compiler they do a few things:

* Mark themselves as entirely unstable via the `staged_api` feature and the
  `#![unstable]` attribute.
* Allow usage of other unstable crates via `feature(rustc_private)` which is
  required if the crate relies on any other crates to compile (other than std).
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.
Remove internal liblog

This commit deletes the internal liblog in favor of the implementation that
lives on crates.io. Similarly it's also setting a convention for adding crates
to the compiler. The main restriction right now is that we want compiler
implementation details to be unreachable from normal Rust code (e.g. requires a
feature), and by default everything in the sysroot is reachable via `extern
crate`.

The proposal here is to require that crates pulled in have these lines in their
`src/lib.rs`:

    #![cfg_attr(rustbuild, feature(staged_api, rustc_private))]
    #![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))]

This'll mean that by default they're not using these attributes but when
compiled as part of the compiler they do a few things:

* Mark themselves as entirely unstable via the `staged_api` feature and the
  `#![unstable]` attribute.
* Allow usage of other unstable crates via `feature(rustc_private)` which is
  required if the crate relies on any other crates to compile (other than std).
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.)
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`.
rustbuild: Update bootstrap compiler

Now that we've also updated cargo's release process this commit also changes the
download location of Cargo from Cargos archives back to the static.r-l.o
archives. This should ensure that the Cargo download is the exact Cargo paired
with the rustc that we release.
…r, r=nrc

macros: improve the `TokenStream` quoter

This PR
 - renames the `TokenStream` quoter from `qquote!` to `quote!`,
 - uses `$` instead of `unquote` (e.g. `let toks: TokenStream = ...; quote!([$toks])`),
 - allows unquoting `Token`s as well as `TokenTree`s and `TokenStream`s (fixes rust-lang#39746), and
 - to preserve syntactic space, requires that `$` be followed by
   - a single identifier to unquote, or
   - another `$` to produce a literal `$`.

r? @nrc
…ion, r=nrc

macros: fix regression with `include!()`

Fixes rust-lang#40469, a regression when `include!()`ing a `macro_rules!` containing `$crate`.
r? @nrc
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.
@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (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.

@frewsxcv
Copy link
Member Author

@bors r+ p=10

@bors
Copy link
Contributor

bors commented Mar 17, 2017

📌 Commit 60e7df4 has been approved by frewsxcv

@frewsxcv frewsxcv closed this Mar 17, 2017
@frewsxcv frewsxcv deleted the rollup branch March 17, 2017 21:05
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup
Projects
None yet
Development

Successfully merging this pull request may close these issues.