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!
constraints:
- clean/inline.rs needs this map to fill in traits when inlining
- fold.rs needs this map to allow passes to fold trait items
- html/render.rs needs this map to seed the Cache.traits map of all
known traits
The first two are the real problem, since `DocFolder` only operates on
`clean::Crate` but `clean/inline.rs` only sees the `DocContext`. The
introduction of early passes means that these two now exist at the same
time, so they need to share ownership of the map. Even better, the use
of `Crate` in a rustc thread pool means that it needs to be Sync, so it
can't use `Lrc<Lock>` to manually activate thread-safety.
`parking_lot` is reused from elsewhere in the tree to allow use of its
`ReentrantMutex`, as the relevant parts of rustdoc are still
single-threaded and this allows for easier use in that context.
Remove usages of span_suggestion without Applicability
Use `Applicability::Unspecified` for all of them instead.
Shall deprecations for the non-`_with_applicability` functions be added?
Shall clippy be addressed somehow?
r? @estebank
Update some `*-sys` dependencies of Cargo/RLS
This is intended to help solve #54206 on nightly where the RLS on MinGW is
having build issues with accidentally building a `curl` library which links to
pthread symbols on Windows (where it should use native mutex locking instead).
The build system for these `*-sys` crates have all been rewritten to be based on
`cc` to bypass native build systems and platform detection to make sure we
configure them correctly.
This is intended to help solve #54206 on nightly where the RLS on MinGW is
having build issues with accidentally building a `curl` library which links to
pthread symbols on Windows (where it should use native mutex locking instead).
The build system for these `*-sys` crates have all been rewritten to be based on
`cc` to bypass native build systems and platform detection to make sure we
configure them correctly.
Split `Liveness::users` into three.
This reduces memory usage on some benchmarks because no space is wasted
for padding. For a `check-clean` build of `keccak` it reduces `max-rss`
by 20%.
r? @nikomatsakis, but I want to do a perf run. Locally, I had these results:
- instructions: slight regression
- max-rss: big win on "Clean" builds
- faults: big win on "Clean" and "Nll" builds
- wall-time: small win on "Clean" and "Nll" builds
So I want to see how a different machine compares.
Fix `thread` `park`/`unpark` synchronization
Previously the code below would not be guaranteed to exit when the
second unpark took the `return, // already unparked` path because there
was no write to synchronize with a read in `park`.
EDIT: doesn't actually require third thread
```
use std::sync::atomic::{AtomicBool, Ordering};
use std:🧵:{current, spawn, park};
static FLAG: AtomicBool = AtomicBool::new(false);
fn main() {
let thread_0 = current();
spawn(move || {
thread_0.unpark();
FLAG.store(true, Ordering::Relaxed);
thread_0.unpark();
});
while !FLAG.load(Ordering::Relaxed) {
park();
}
}
```
I have some other ideas on how to improve the performance of `park` and `unpark` using fences, avoiding any atomic RMW when the state is already `NOTIFIED`, and also how to avoid calling `notify_one` without the mutex locked. But I need to write some micro benchmarks first, so I'll submit those changes at a later date if they prove to be faster.
Fixes https://github.com/rust-lang/rust/issues/53366 I hope.
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
Use `HybridBitSet` in `SparseBitMatrix`.
This fixes most of the remaining NLL memory regression.
r? @pnkfelix, because you reviewed #54286.
cc @nikomatsakis, because NLL
cc @Mark-Simulacrum, because this removes `array_vec.rs`
cc @lqd, because this massively improves `unic-ucd-name`, and probably other public crates
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.
OsStr: Document that it's not NUL terminated
I somehow got confused into thinking this was the case, but
it's definitely not. Let's help the common case of people who
have an `OsStr` and need to call e.g. Unix APIs.
Remove README with now-out-of-date docs about docs.
These docs haven't really been touched in years, and from what I tried, the `rustdoc` commands don't work. Seems like we don't need this?
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.
add `-Z dont-buffer-diagnostics`
Add `-Z dont-buffer-diagnostics`, a way to force NLL to immediately its diagnostics.
This is mainly intended for developers who want to see the error in its original context in the control flow. Two uses cases for that are:
1. `-Z treat-err-as-bug` (which then allows extraction of a stack-trace to the origin of the error)
2. RUST_LOG=... rustc, in which case it is often useful to see the logging statements that occurred immediately prior to the point where the diagnostic was signalled.
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
Add doc for impl From for Addr
As part of issue #51430 (cc @skade).
The impl is very simple, let me know if we need to go into any details.
Additionally, I added `#[inline]` for the conversion method, let me know if it is un-necessary or might break something.
This requires adding a few extra methods to `HybridBitSet`. (These are
tested in a new unit test.)
This commit reduces the `max-rss` for `nll-check` builds of `html5ever`
by 46%, `ucd` by 45%, `clap-rs` by 23%, `inflate` by 14%. And the
results for the `unic-ucd-name` crate are even more impressive: a 21%
reduction in instructions, a 60% reduction in wall-time, a 96%
reduction in `max-rss`, and a 97% reduction in faults!
Fixes#52028.
`SparseBitSet` is the only remaining user of `ArrayVec`. This commit
switches it to using `SmallVec`, and removes `array_vec.rs`.
Why the switch? Although `SparseBitSet` is size-limited and doesn't need
the ability to spill to the heap, `SmallVec` has many more features than
`ArrayVec`. In particular, it's now possible to keep `SparseBitSet`'s
elements in sorted order, which gives in-order iteration, which is a
requirement for the next commit.
