* In the case of `derive-same-struct`, it seemed cleaner to add the
output than to try to modify the macro itself (which is where the
output is coming from).
* In the case of `custom-derive-partial-eq`, it was just easier to add
the output than to attempt to port the test to use a procedural
macro.
Rollup of 15 pull requests
Successful merges:
- #52813 (Duration div mul extras)
- #53470 (Warn about metadata loader errors)
- #54233 (Remove LLVM 3.9 workaround.)
- #54257 (Switch wasm math symbols to their original names)
- #54258 (Enable fatal warnings for the wasm32 linker)
- #54266 (Update LLVM to fix "bool" arguments on PPC32)
- #54290 (Switch linker for aarch64-pc-windows-msvc from LLD to MSVC)
- #54292 (Suggest array indexing when tuple indexing on an array)
- #54295 (A few cleanups and minor improvements to rustc/traits)
- #54298 (miri: correctly compute expected alignment for field)
- #54333 (Update The Book to latest)
- #54337 (Remove unneeded clone() from tests in librustdoc)
- #54346 (rustc: future-proof error reporting for polymorphic constants in types.)
- #54362 (Pass --batch to gdb)
- #54367 (Add regression test for thread local static mut borrows)
Add regression test for thread local static mut borrows
FIXME(#54366) - We probably shouldn't allow `#[thread_local] static mut` to get a `'static` lifetime, but for now, we should at least test the behavior that `rustc` currently has.
rustdoc: collect trait impls as an early pass
Fixes https://github.com/rust-lang/rust/issues/52545, fixes https://github.com/rust-lang/rust/issues/41480, fixes https://github.com/rust-lang/rust/issues/36922
Right now, rustdoc pulls all its impl information by scanning a crate's HIR for any items it finds. However, it doesn't recurse into anything other than modules, preventing it from seeing trait impls that may be inside things like functions or consts. Thanks to https://github.com/rust-lang/rust/pull/53002, now these items actually *exist* for rustdoc to see, but they still weren't getting collected for display.
But there was a secret. Whenever we pull in an item from another crate, we don't have any of its impls in the local HIR, so instead we ask the compiler for *everything* and filter out after the fact. This process is only triggered if there's a cross-crate re-export in the crate being documented, which can sometimes leave this info out of the docs. This PR instead moves this collection into an early pass, which occurs immediately after crate cleaning, so that that collection occurs regardless. In addition, by including the HIR's own `trait_impls` in addition to the existing `all_trait_implementations` calls, we can collect all these tricky trait impls without having to scan for them!
Update to a new pinning API.
~~Blocked on #53843 because of method resolution problems with new pin type.~~
@r? @cramertj
cc @RalfJung @pythonesque anyone interested in #49150
By introducing a new map that tracks the errors reported and the
`Place`s that spawned those errors against the move out that the error
was referring to, we are able to silence duplicate errors by emitting
only the error which corresponds to the most specific `Place` (that which
other `Place`s which reported errors are prefixes of).
This generally is an improvement, however there is a case -
`liveness-move-in-while` - where the output regresses.
Issue 54246
I added the option of providing a help message for deprecated features, that takes precedence over the default `help: remove this attribute` message, along with messages for the features that mention replacements in the reason for deprecation.
Fixes#54246.
Regression test for rust-lang/rust#53675.
(Includes a couple variations on the theme. I confirmed that the ones
in `in_expression_position` and `what_if_we_use_panic_directly_in_expr`
both failed back on "rustc 1.30.0-nightly (0f063aef6 2018-09-03)".)
Fix#53675
Temporarily prohibit proc macro attributes placed after derives
... and also proc macro attributes used together with `#[test]`/`#[bench]`.
Addresses item 6 from https://github.com/rust-lang/rust/pull/50911#issuecomment-411605393.
The end goal is straightforward predictable left-to-right expansion order for attributes.
Right now derives are expanded last regardless of their relative ordering with macro attributes and right now it's simpler to temporarily prohibit macro attributes placed after derives than changing the expansion order.
I'm not sure whether the new beta is already released or not, but if it's released, then this patch needs to be backported, so the solution needs to be minimal.
How to fix broken code (derives):
- Move macro attributes above derives. This won't change expansion order, they are expanded before derives anyway.
Using attribute macros on same items with `#[test]` and `#[bench]` is prohibited for similar expansion order reasons, but this one is going to be reverted much sooner than restrictions on derives.
How to fix broken code (test/bench):
- Enable `#![feature(plugin)]` (don't ask why).
r? @ghost
