Remove ast-ty-to-ty cache
As discussed on IRC, this basically just removes the cache, and rewrites rustdoc and save-analysis so call into the astconv code. It *might* make sense for this to be a more fine-grained query, but that would (at least) require us to be using `HirId` and not `NodeId`.
(Perhaps I should open a FIXME?)
I didn't measure perf impact (yet?). I did observe that the cache seems to hit *rarely* -- and only in between items (I experimented with a cache "per def-id", but that had zero hits). In other words, every single hit on the cache is a dependency bug, since it is "shuttling" information between items without dependency edges.
r? @eddyb
Fix @martinhath's mailmap entry
I stumbled upon a name duplication issue in [rust-lang-nursery/thanks](https://github.com/rust-lang-nursery/thanks/), and realized that this problem is easily fixable. I've (hopefully) done the right thing here. It works locally (`git shortlog | grep "Thoresen"` only returns one entry instead of two).
I didn't bother creating an issue in the `thanks` repository, since I did the `.mailmap` editing myself.
Generate XZ-compressed tarballs
Integrate the new `rust-installer` and extend manifests with keys for xz-compressed tarballs.
One of the steps required for https://github.com/rust-lang/rust/issues/21724
There are now two queries: crate and item. The crate one computes the
variance of all items in the crate; it is sort of an implementation
detail, and not meant to be used. The item one reads from the crate one,
synthesizing correct deps in lieu of the red-green algorithm.
At the same time, remove the `variance_computed` flag, which was a
horrible hack used to force invariance early on (e.g. when type-checking
constants). This is only needed because of trait applications, and
traits are always invariant anyway. Therefore, we now change to take
advantage of the query system:
- When asked to compute variances for a trait, just return a vector
saying 'all invariant'.
- Remove the corresponding "inferreds" from traits, and tweak the
constraint generation code to understand that traits are always
inferred.
rustbuild: Sanity-check cmake for sanitizers too
It's possible to build the sanitizers when using an external LLVM, but
we still need cmake for this. Extend the sanity check to look for cmake
whenever sanitizers are enabled too.
Remove ANTLR grammar
I *think* that nothing in-tree references this, but I may be wrong. If anyone thinks of anything, please let me know and I'll work on removing.
Fixes#15677.
Add -march=armv7-a parameter to armv7 android linker
Without this option, the linker fails to link any library that uses `std::future`. The error points some undefined references, like `std::__future_base::_Result_base`.
For example, it fails to link rustc because llvm 4.0 uses `std::future`.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735
Consider changing to & for let bindings #40402
This is a fix for #40402
For the example
```
fn main() {
let v = vec![String::from("oh no")];
let e = v[0];
}
```
It gives
```
error[E0507]: cannot move out of indexed content
--> ex1.rs:4:13
|
4 | let e = v[0];
| ^^^^ cannot move out of indexed content
|
= help: consider changing to `&v[0]`
error: aborting due to previous error
```
Another alternative is
```
error[E0507]: cannot move out of indexed content
--> ex1.rs:4:13
|
4 | let e = v[0];
| ^^^^ consider changing to `&v[0]`
error: aborting due to previous error
```
Also refer to #41564 for more details.
r? @nikomatsakis
rework the queries for the MIR pipeline
This PR refashions the MIR pipeline. There are a number of changes:
* We no longer have "MIR passes" and the pass manager is completely reworked. Unless we are doing the interprocedural optimization (meaning, right now, the inline pass), we will process a single MIR from beginning to finish in a completely on-demand fashion; i.e., when you request `optimized_mir(D)`, that will trigger the MIR for `D` to actually be built and optimized, but no other functions are built or touched.
* We no longer use `&'tcx RefCell<Mir<'tcx>>` as the result of queries, since that spoils the view of queries as "pure functions". To avoid however copying the MIR, we use a `&'tcx Steal<Mir<'tcx>>` -- this is something like a ref-cell, in that you can use `borrow()` to read it, but it has no `borrow_mut()`. Instead, it has `steal()`, which will take the contents and then panic if any further read attempt occurs.
* We now support `[multi]` queries, which can optionally yield not just one result but a sequence of (K, V) pairs. This is used for the inlining pass. If inlining is enabled, then when it is invoked on **any** def-id D, it will go and read the results for **all** def-ids and transform them, and then return the results for all of them at once. This isn't ideal, and we'll probably want to rework this further, but it seems ok for now (note that MIR inlining is not enabled by default).
**Tips for the reviewer:** The commits here are meant to build individually, but the path is a *bit* meandering. In some cases, for example, I introduce a trait in one commit, and then tweak it in a later commit as I actually try to put it to use. You may want to read the README in the final commit to get a sense of where the overall design is headed.
@eddyb I did not wind up adding support for queries that produce more than one *kind* of result. Instead, I decided to just insert judicious use of the `force()` command. In other words, we had talked about e.g. having a query that produced not only the MIR but also the `const_qualif` result for the MIR in one sweep. I realized you can also have the same effect by having a kind of meta-query that forces the const-qualif pass and then reads the result. See the README for a description. (We can still do these "multi-query results" later if we want, I'm not sure though if it is necessary.)
r? @eddyb
cc @michaelwoerister @matthewhammer @arielb1, who participated in the IRC discussion.
