there is a soft-error for older toolchains
from https://reviews.llvm.org/D57264 in preparation for the
hard error in https://reviews.llvm.org/D66188

… for Polonius

… for Polonius

…or Polonius

as its output was changed by rust-lang@2ff337a#diff-bd3f80b956148a5d1567aa8698b8a507

This can be removed once dataflow-based const validation is merged.

Update installed compiler dependencies

As llvm have updated the minimum toolchain
https://reviews.llvm.org/D66188

On obligation errors point at the unfulfilled binding when possible

CC rust-lang#42855, rust-lang#64130, rust-lang#64135.

Polonius: more `ui` test suite fixes

Since rust-lang#62736, new tests have been added, and the `run-pass` suite was merged into the `ui` suite.

This PR adds the missing tests expectations for Polonius, and updates the existing ones where the NLL output has changed in some manner (e.g. ordering of notes)

Those are the trivial cases, but a more-detailed explanation is available [in this write-up](https://hackmd.io/CjYB0fs4Q9CweyeTdKWyEg?both#26-async-awaitasync-borrowck-escaping-closure-errorrs-outputs-from-NLL-Polonius-diff) starting at test case 26: they are only differing in diagnostics and instances of other existing test cases differences.

Only 3 of the 9020 tests are still "failing" at the moment (1 failure, 2 OOMs).

r? @nikomatsakis

…oli-obk

A more generic interface for dataflow analysis

rust-lang#64470 requires a transfer function that is slightly more complex than the typical `gen`/`kill` one. Namely, it must copy state bits between locals when assignments occur (see rust-lang#62547 for an attempt to make this fit into the existing framework). This PR contains a dataflow interface that allows for arbitrary transfer functions. The trade-off is efficiency: we can no longer coalesce transfer functions for blocks and must visit each statement individually while iterating to fixpoint.

Another issue is that poorly behaved transfer functions can result in an analysis that fails to converge. `gen`/`kill` sets do not have this problem. I believe that, in order to guarantee convergence, flipping a bit from `false` to `true` in the entry set cannot cause an output bit to go from `true` to `false` (negate all preceding booleans when `true` is the bottom value). Perhaps someone with a more formal background can confirm and we can add a section to the docs?

This approach is not maximally generic: it still requires that the lattice used for analysis is the powerset of values of `Analysis::Idx` for the `mir::Body` of interest. This can be done at a later date. Also, this is the bare minimum to get rust-lang#64470 working. I've not adapted the existing debug framework to work with the new analysis, so there are no `rustc_peek` tests either. I'm planning to do this after rust-lang#64470 is merged.

Finally, my ultimate plan is to make the existing, `gen`/`kill`-based `BitDenotation` a special case of `generic::Analysis`. Currently they share a ton of code. I should be able to do this without changing any implementers of `BitDenotation`. Something like:

```rust
struct GenKillAnalysis<A: BitDenotation> {
    trans_for_block: IndexVec<BasicBlock, GenKillSet<A::Idx>>,
    analysis: A,
}

impl<A> generic::Analysis for GenKillAnalysis<A> {
    // specializations of `apply_{partial,whole}_block_effect`...
}
```

r? @pnkfelix

…ievink

Fix a minor grammar nit, update UI tests

Minor fix, but I noticed it while debugging some code