This commit reorganizes how the persist code treats hashing. The idea is
that each crate saves a file containing hashes representing the metadata
for each item X. When we see a read from `MetaData(X)`, we can load this
hash up (if we don't find a file for that crate, we just use the SVH for
the entire crate).
To compute the hash for `MetaData(Y)`, where Y is some local item, we
examine all the predecessors of the `MetaData(Y)` node and hash their
hashes together.
For external crates, we must build up a map that goes from
the DefKey to the DefIndex. We do this by iterating over each
index that is found in the metadata and loading the associated
DefKey.
introduce a specializes cache
This query is frequently used during trait selection and caching the
result can be a reasonable performance win.
The one case I examined thus far was the mrusty package (v0.5.1), where I saw an improvement in "typeck item bodies" from ~8.3s to ~1.9s.
r? @aturon
syntax_ext: format: nest_level's are no more
Just noticed this while working on #33642 and here's a quick fix, shouldn't touch anything else. It's some historic code indeed...
When displaying the function parameters for a lifetime elision error message,
this changes it to first filter out the parameters that don't have elided
lifetimes.
Fixes#30255.
Warnings for issue #32330
This is an extension of the previous PR that issues warnings in more situations than before. It does not handle *all* cases of #32330 but I believe it issues warnings for all cases I've seen in practice.
Before merging I'd like to address:
- open a good issue explaining the problem and how to fix it (I have a [draft writeup][])
- work on the error message, which I think is not as clear as it could/should be (suggestions welcome)
r? @aturon
[draft writeup]: https://gist.github.com/nikomatsakis/631ec8b4af9a18b5d062d9d9b7d3d967
Added a big-picture explanation for thread::park() & co.
As I said in https://www.reddit.com/r/rust/comments/4ihvv1/hey_rust_programmers_got_a_question_ask_here/d372s4i, the current explanation of the `park()` and `unpark()` is a bit unclear. It says that they're used for blocking, but then it goes on explaining the semantics in detail, leaving the bigger picture a bit unclear.
I added a short high-level explanation that explains how the functions are used. I also exposed the full paths (`thread::park()` and `thread::Thread::unpark()`), because `unpark()`, being a method, is not directly visible at the module level.
