use gcc::Build rather than deprecated gcc::Config
I did `cargo update -p gcc` to upgrade only this package. Is there further process that should be follwoed when updating a build dependency from crates.io?
r? @alexcrichton
Fixes#43973
rustdoc: add new "Implementations on Foreign Types" section to traits
Demo screenshot:
![image](https://user-images.githubusercontent.com/5217170/29281219-c547f758-80e3-11e7-808f-49f592c65c5b.png)
Full demo available at https://tonberry.quietmisdreavus.net/foreign-test/foreign_test/trait.CheckIt.html
This PR splits the "Implementors" section on trait pages into two: First, for impls on types local to the crate, their impls are kept as-is, printing one line for the impl line, and any additional lines for associated types. However, for types external to the crate, they are now pulled up over the others and are printed (almost) like the summary impl on the type page itself. This gives any doc comments on these impls or methods to be exposed in the documentation.
There's just one small problem, though: [libstd docs apparently surface impls for libc and rand, possibly among others](https://tonberry.quietmisdreavus.net/foreign-std/std/marker/trait.Copy.html#foreign-impls). This adds this section to pages in the std docs where we might not want them to show up in the first place. I think this is a bug distinct from this PR, but it does make it drastically apparent.
~~My question, then, is this: Do we want this here? Taking it out involves fixing which impls are visible to rustdoc, possibly specifically when rendering the std facade. I'm convinced this is fine to land as-is, since it adds a feature specifically for non-std crates (i'm thinking of things like `num` or related crates that implement things on primitives or std types as part of their functionality).~~ (EDIT: I have an open PR to fix this: https://github.com/rust-lang/rust/pull/44026)
Compact display of static lib dependencies
Fixes#33173
Instead of displaying one dependency per line, I've changed the format to display them all in one line.
As a bonus they're in format of linker flags (`-lfoo`), so the output can be copy&pasted if one is actually going to link as suggested.
expand on using rustup custom toolchains in CONTRIBUTING.md
fixes#42484
Should i include more notes about how to use a local build *without* rustup? It can kinda feel like a cop-out otherwise. Other means that come to mind are setting `$RUSTC` directly and fully installing it.
cc @rust-lang/docs
rustc: Flag {i,u}128 as unsafe for FFI
These don't appear to have a stable ABI as noted in #41799 and the work in
compiler-builtins definitely seems to be confirming it!
More general `on_unimplemented`, with uses in `Try`
Allow `on_unimplemented` directives to specify both the label and the primary message of the trait error, and allow them to be controlled by flags - currently only to be desugaring-sensitive.
e.g.
```Rust
#[rustc_on_unimplemented(
on(all(direct, from_desugaring="?"),
message="the `?` operator can only be used in a \
function that returns `Result` \
(or another type that implements `{Try}`)",
label="cannot use the `?` operator in a function that returns `{Self}`"),
)]
```
r? @nikomatsakis
Better StorageLive / StorageDead placement for constants.
Fixes problems in miri (see https://github.com/solson/miri/pull/324#issuecomment-326555552) caused by the new scope rules in #43932.
What I've tried to do here is always have a `StorageLive` but no `StorageDead` for `'static` slots.
It might not work perfectly in all cases, but it should unblock miri.
r? @nikomatsakis cc @oli-obk
rustc: Remove the `used_unsafe` field on TyCtxt
Now that lint levels are available for the entire compilation, this can be an
entirely local lint in `effect.rs`
cc #44137
Update rls
And expose the `CFG_VERSION` env var to tools so they can determine the version of Rust.
This gets the RLS back on master and so completes the PR dance for the generators PR.
r? @alexcrichton
powerpc64: improve extern struct ABI
These fixes all have to do with the 64-bit PowerPC ELF ABI for big-endian
targets. The ELF v2 ABI for powerpc64le already worked well.
- Return after marking return aggregates indirect. Fixes#42757.
- Pass one-member float aggregates as direct argument values.
- Aggregate arguments less than 64-bit must be written in the least-
significant bits of the parameter space.
- Larger aggregates are instead padded at the tail.
(i.e. filling MSBs, padding the remaining LSBs.)
New tests were also added for the single-float aggregate, and a 3-byte
aggregate to check that it's filled into LSBs. Overall, at least these
formerly-failing tests now pass on powerpc64:
- run-make/extern-fn-struct-passing-abi
- run-make/extern-fn-with-packed-struct
- run-pass/extern-pass-TwoU16s.rs
- run-pass/extern-pass-TwoU8s.rs
- run-pass/struct-return.rs
Add clippy as a submodule
~~This builds clippy as part of `./x.py build` (locally and in CI).~~
This allows building clippy with `./x.py build src/tools/clippy`
~~Needs https://github.com/nrc/dev-tools-team/issues/18#issuecomment-322456461 to be resolved before it can be merged.~~ Contributers can simply open a PR to clippy and point the submodule at the `pull/$pr_number/head` branch.
This does **not** build clippy or test the clippy test suite at all as per https://github.com/nrc/dev-tools-team/issues/18#issuecomment-321411418
r? @nrc
cc @Manishearth @llogiq @mcarton @alexcrichton