update Miri

Fixes https://github.com/rust-lang/rust/issues/97745
r? `@ghost` Cc `@rust-lang/miri`
Cc `@InfRandomness`

Rollup of 3 pull requests

Successful merges:

 - #97700 (Add note to documentation of HashSet::intersection)
 - #97792 (More eslint checks)
 - #97794 (Fix typo in redundant_pattern_match.rs)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Fix typo in redundant_pattern_match.rs

alway -> always

More eslint checks

Here is the list of newly added eslint checks:

 * [no-confusing-arrow](https://eslint.org/docs/rules/no-confusing-arrow)
 * [no-div-regex](https://eslint.org/docs/rules/no-div-regex)
 * [no-floating-decimal](https://eslint.org/docs/rules/no-floating-decimal)
 * [no-implicit-globals](https://eslint.org/docs/rules/no-implicit-globals)
 * [no-implied-eval](https://eslint.org/docs/rules/no-implied-eval)
 * [no-label-var](https://eslint.org/docs/rules/no-label-var)

Since you already reviewed the previous ones:

r? `@Dylan-DPC`

Add note to documentation of HashSet::intersection

The functionality of the `std::collections::HashSet::intersection(...)` method was slightly surprising to me so I wanted to take a sec to contribute to the documentation for this method.

I've added a `Note:` section if that is appropriate.

Co-authored-by: NDavid Tolnay <dtolnay@gmail.com>

Update Clippy

r? `@Manishearth`

This includes a bit bigger `Cargo.lock` update.

Rollup of 5 pull requests

Successful merges:

 - #97312 (Compute lifetimes in scope at diagnostic time)
 - #97495 (Add E0788 for improper #[no_coverage] usage)
 - #97579 (Avoid creating `SmallVec`s in `global_llvm_features`)
 - #97767 (interpret: do not claim UB until we looked more into variadic functions)
 - #97787 (E0432: rust 2018 -> rust 2018 or later    in --explain message)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

interpret: better control over whether we read data with provenance

The resolution in https://github.com/rust-lang/unsafe-code-guidelines/issues/286 seems to be that when we load data at integer type, we implicitly strip provenance. So let's implement that in Miri at least for scalar loads. This makes use of the fact that `Scalar` layouts distinguish pointer-sized integers and pointers -- so I was expecting some wild bugs where layouts set this incorrectly, but so far that does not seem to happen.

This does not entirely implement the solution to https://github.com/rust-lang/unsafe-code-guidelines/issues/286; we still do the wrong thing for integers in larger types: we will `copy_op` them and then do validation, and validation will complain about the provenance. To fix that we need mutating validation; validation needs to strip the provenance rather than complaining about it. This is a larger undertaking (but will also help resolve https://github.com/rust-lang/miri/issues/845 since we can reset padding to `Uninit`).

The reason this is useful is that we can now implement `addr` as a `transmute` from a pointer to an integer, and actually get the desired behavior of stripping provenance without exposing it!

E0432: rust 2018 -> rust 2018 or later    in --explain message

interpret: do not claim UB until we looked more into variadic functions

I am not actually sure if this is UB, and anyway for FFI shims, Miri currently does not attempt to distinguish between arguments passed via variadics vs directly. So let's be consistent.
(Programs that ran into this error will anyway immediately fall through to the "unsupported" message on the next line.)

Avoid creating `SmallVec`s in `global_llvm_features`

This PR made a simple optimization to avoid creating extra `SmallVec`s by adjusting the use of iterator statements.
Also, given the very small size of `tied_target_features`, there is no need to insert each feature into the FxHashMap.

Add E0788 for improper #[no_coverage] usage

Essentially, this adds proper checking for the attribute (tracking issue #84605) and throws errors when it's put in obviously-wrong places, like on struct or const definitions. Most of the code is taken directly from the checks for the `#[inline]` attribute, since it's very similar.

Right now, the code only checks at the function level, but it seems reasonable to allow adding `#[no_coverage]` to individual blocks or expressions, so, for now those just throw `unused_attributes` warnings. Similarly, since there was a lot of desire to eventually allow recursive definitions as well on modules and impl blocks, these also throw `unused_attributes` instead of an error.

I'm not sure if anything has to be done since this error is technically for an unstable feature, but since an error for using unstable features will show up anyway, I think it's okay.

This is the first big piece needed for stabilising this attribute, although I personally would like to explore renaming it to `#[coverage(never)]` on a separate PR, which I will offer soon. There's a lot of discussion still to be had about that, which is why it will be kept separate.

I don't think much is needed besides adding this simple check and a UI test, but let me know if there's something else that should be added to make this happen.

Compute lifetimes in scope at diagnostic time

The set of available lifetimes is currently computed during lifetime resolution on HIR.  It is only used for one diagnostic.

In this PR, HIR lifetime resolution just reports whether elided lifetimes are well-defined at the place of use.  The diagnostic code is responsible for building a list of lifetime names if elision is not allowed.

This will allow to remove lifetime resolution on HIR eventually.

alway -> always

Report unsafe for overriding link sections

I'm not too sure about the lint wording here, but I couldn't think of anything better.

Rollup of 7 pull requests

Successful merges:

 - #90905 (Add empty impl blocks if they have documentation)
 - #97683 (Fail gracefully when encountering an HRTB in APIT. )
 - #97721 (Do `suggest_await_before_try` with infer variables in self, and clean up binders)
 - #97752 (typo: `-Zcodegen-backend=llvm -Cpasses=list` should work now)
 - #97759 (Suggest adding `{}` for `'label: non_block_expr`)
 - #97764 (use strict provenance APIs)
 - #97765 (Restore a test that was intended to test `as` cast to ptr)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Restore a test that was intended to test `as` cast to ptr

This test was changed in https://github.com/rust-lang/rust/pull/61864, but the original bug https://github.com/rust-lang/rust/issues/46365 was about casts so I doubt the changed test still even tests what this was intended to test. Let's restore the original test.

use strict provenance APIs

The stdlib was adjusted to avoid bare int2ptr casts, but recently some casts of that sort have sneaked back in. Let's fix that. :)

Suggest adding `{}` for `'label: non_block_expr`

Adds suggestions like this:
```text
help: consider enclosing expression in a block
  |
3 |     'l {0};
  |        + +
```

inspired by https://github.com/rust-lang/rust/issues/48594#issuecomment-1146744400

r? ``@compiler-errors``

typo: `-Zcodegen-backend=llvm -Cpasses=list` should work now

r? ```@bjorn3```

Do `suggest_await_before_try` with infer variables in self, and clean up binders

Fixes #97704

Also cleans up binders in this fn, since everything is a `Poly*` and we really shouldn't have stray escaping late-bound regions everywhere. That's why the function changed so much. This isn't necessary, so I can revert if necessary.

Fail gracefully when encountering an HRTB in APIT.

Fixes https://github.com/rust-lang/rust/issues/96954

~The first commit will be merged as part of https://github.com/rust-lang/rust/pull/97415~

Add empty impl blocks if they have documentation

Fixes https://github.com/rust-lang/rust/issues/90866.

The update for the test script is needed to count the number of impl blocks we have with only the struct. To be noted that with https://github.com/rust-lang/rust/pull/89676 merged, it wouldn't be needed (I don't know what is the status of it btw. cc ```@Mark-Simulacrum).```

It looks like this:

![Screenshot from 2021-11-14 16-51-28](https://user-images.githubusercontent.com/3050060/141689100-e57123c0-bf50-4c42-adf5-d991e169a0e4.png)

cc ```@jyn514```
r? ```@camelid```

[compiletest] Ignore known paths when abbreviating output

To prevent out of memory conditions, compiletest limits the amount of output a test can generate, abbreviating it if the test emits more than a threshold. While the behavior is desirable, it also causes some issues (like #96229, #94322 and #92211).

The latest one happened recently, when the `src/test/ui/numeric/numeric-cast.rs` test started to fail on systems where the path of the rust-lang/rust checkout is too long. This includes my own development machine and [LLVM's CI](https://github.com/rust-lang/rust/issues/96362#issuecomment-1108609893). Rust's CI uses a pretty short directory name for the checkout, which hides these sort of problems until someone runs the test suite on their own computer.

When developing the fix I tried to find the most targeted fix that would prevent this class of failures from happening in the future, deferring the decision on if/how to redesign abbreviation to a later date. The solution I came up with was to ignore known base paths when calculating whether the output exceeds the abbreviation threshold, which removes this kind of nondeterminism.

This PR is best reviewed commit-by-commit.

implement ptr.addr() via transmute

As per the discussion in https://github.com/rust-lang/unsafe-code-guidelines/issues/286, the semantics for ptr-to-int transmutes that we are going with for now is to make them strip provenance without exposing it. That's exactly what `ptr.addr()` does! So we can implement `ptr.addr()` via `transmute`. This also means that once https://github.com/rust-lang/rust/pull/97684 lands, Miri can distinguish `ptr.addr()` from `ptr.expose_addr()`, and the following code will correctly be called out as having UB (if permissive provenance mode is enabled, which will become the default once the [implementation is complete](https://github.com/rust-lang/miri/issues/2133)):

```rust
fn main() {
    let x: i32 = 3;
    let x_ptr = &x as *const i32;

    let x_usize: usize = x_ptr.addr();
    // Cast back an address that did *not* get exposed.
    let ptr = std::ptr::from_exposed_addr::<i32>(x_usize);
    assert_eq!(unsafe { *ptr }, 3); //~ ERROR Undefined Behavior: dereferencing pointer failed
}
```

This completes the Miri implementation of the new distinctions introduced by strict provenance. :)

Cc `@Gankra` -- for now I left in your `FIXME(strict_provenance_magic)` saying these should be intrinsics, but I do not necessarily agree that they should be. Or if we have an intrinsic, I think it should behave exactly like the `transmute` does, which makes one wonder why the intrinsic should be needed.

Co-authored-by: NMichael Goulet <michael@errs.io>