Fixes #73268

When a deref coercion occurs, we may end up with a move error if the
base value has been partially moved out of. However, we do not indicate
anywhere that a deref coercion is occuring, resulting in an error
message with a confusing span.

This PR adds an explicit note to move errors when a deref coercion is
involved. We mention the name of the type that the deref-coercion
resolved to, as well as the `Deref::Target` associated type being used.

Update Clippy

Biweekly Clippy update

r? `@Manishearth`

Rollup of 11 pull requests

Successful merges:

 - #75857 (Syntactically permit unsafety on mods)
 - #76289 (Add docs about crate level documentation support)
 - #76514 (Add revisions to const generic issue UI tests.)
 - #76524 (typeck: don't suggest inaccessible private fields)
 - #76548 (Validate removal of AscribeUserType, FakeRead, and Shallow borrow)
 - #76555 (Reword `trivial_casts` lint in rustc book to better explain what it does.)
 - #76559 (add the `const_evaluatable_checked` feature)
 - #76563 (small typo fix in rustc_parse docs)
 - #76565 (take reference to Place directly instead of taking reference to Box<Place>)
 - #76567 (use push(char) to add chars (single-char &strs) to strings instead of push_str(&str))
 - #76568 (Add missing examples on core traits' method)

Failed merges:

r? `@ghost`

Add missing examples on core traits' method

Linked to #76450.

r? @jyn514

use push(char) to add chars (single-char &strs) to strings instead of push_str(&str)

take reference to Place directly instead of taking reference to Box<Place>

clippy::borrowed_box

small typo fix in rustc_parse docs

small typo in rustc_parse::new_parser_from_file's documentation

I'm not sure a PR is the way to do this though.

add the `const_evaluatable_checked` feature

Implements a rather small subset of https://github.com/rust-lang/compiler-team/issues/340

Unlike the MCP, this does not try to compare different constant, but instead only adds the constants found in where clauses
to the predicates of a function. This PR adds the feature gate `const_evaluatable_checked`, without which nothing should change.

r? @oli-obk @EddyB

Reword `trivial_casts` lint in rustc book to better explain what it does.

The current description of the trivial casts lint under the "allowed
by default" listing in the rustc book indicates the lint is for casts
which may be removed, which is less clear than saying it's for casts
which may be replaced by coercion (which is the wording used by the
error message included in the doc).

This commit changes the wording slightly to better describe what the
lint does.

This issue bit me in some recent code where I was attempting to
convert a `Vec<SomeType>` to a `Vec<SomeTraitObject>`, and
hit my project-wide `#![deny(trivial_casts)]` with
`map(|o| Box::new(o) as TraitObject)`. I'd read the book docs for
`trivial_casts` and was surprised by the error, as I took it to mean
the cast ought to be removed (rather than replaced by ascription
in this case). Removing the cast meant other code didn't compile,
and I then found issues like #23742 and realized my misunderstanding.

Validate removal of AscribeUserType, FakeRead, and Shallow borrow

Those statements are removed by CleanupNonCodegenStatements pass
in drop lowering phase, and should not occur afterwards.

typeck: don't suggest inaccessible private fields

Fixes #76077.

This PR adjusts the missing field diagnostic logic in typeck so that when none of the missing fields in a struct expr are accessible then the error is less confusing.

r? @estebank

Add revisions to const generic issue UI tests.

Fixes #75279.

I have gotten into the flow, so I can do more of these if requested. I'm looking for feedback as to whether my work is on the right track so far.

Add docs about crate level documentation support

Wrote information about how to write documentation on the crate level in rhe rustdoc book

Syntactically permit unsafety on mods

Similar to https://github.com/rust-lang/rust/pull/66183; we will accept these constructs syntactically but reject with a semantic check after macro expansion if a proc macro hasn't replaced it with something else meaningful to Rust.

```rust
#[mymacro]
unsafe mod m {
    ...
}

#[mymacro]
unsafe extern "C++" {
    ...
}
```

The intention is that this might be used as a kind of "item-level unsafe" in attribute macro DSLs -- holding things which are unsafe to declare but potentially safe to use. For example I look forward to using this in https://github.com/dtolnay/cxx.

In the absence of a procedural macro rewriting them to something else, they'll continue to be rejected at compile time though with a better error message than before.

### Before:

```console
error: expected item, found keyword `unsafe`
 --> src/main.rs:1:1
  |
1 | unsafe mod m {
  | ^^^^^^ expected item
```

### After:

```console
error: module cannot be declared unsafe
 --> src/main.rs:1:1
  |
1 | unsafe mod m {
  | ^^^^^^

error: extern block cannot be declared unsafe
 --> src/main.rs:4:1
  |
4 | unsafe extern "C++" {
  | ^^^^^^
```

Closes #68048.

This commit adjusts the missing field diagnostic logic for struct
patterns in typeck to improve the diagnostic when the missing fields are
inaccessible.
Signed-off-by: NDavid Wood <david@davidtw.co>

This commit adjusts the missing field diagnostic logic for struct
expressions in typeck to improve the diagnostic when the missing
fields are inaccessible.
Signed-off-by: NDavid Wood <david@davidtw.co>

ci: avoid moving the build directory on GHA

While waiting for a PR job to start testing my code, I noticed the symlink-build-dir step took 10 minutes to complete, so I investigated what caused that.

It seems like something changed in the build environment between version 20200901.1 (where the step took 45 seconds) and version 20200908.1 (where the step took 10 minutes). At the time of writing this commit, the rust-lang organization is on vertsion 20200908.1, while the rust-lang-ci organization is at version 20200901.1 (and is not affected by this yet).

There is no need for this step anymore on GHA, as our XL builders got an increase in the root paritition size, so this commit removes the code that moved stuff around on GHA (while keeping it on Azure).

For the record, at the time of writing this, the disk situation is:

```
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       667G   60G  607G   9% /
/dev/sdb1       110G  4.1G  101G   4% /mnt
```

r? `@Mark-Simulacrum`

Add a lint to prevent `create_dir` from being used

This closes #5950
changelog: none

improve the suggestion of the lint `unit-arg`

Fixes #5823
Fixes #6015

Changes
```
help: move the expression in front of the call...
  |
3 |     g();
  |
help: ...and use a unit literal instead
  |
3 |     o.map_or((), |i| f(i))
  |
```
into
```
help: move the expression in front of the call and replace it with the unit literal `()`
  |
3 |     g();
  |     o.map_or((), |i| f(i))
  |
```
changelog: improve the suggestion of the lint `unit-arg`

link to the Box docs in related lint documentation.

changelog: link to the box docs in lint docs

Rustup

r? `@ghost`

changelog: none

clippy::single-char-push-str

clippy::borrowed_box

While waiting for a PR job to start testing my code, I noticed the
symlink-build-dir step took 10 minutes to complete, so I investigated
what caused that.

It seems like something changed in the build environment between version
20200901.1 (where the step took 45 seconds) and version 20200908.1
(where the step took 10 minutes). At the time of writing this commit,
the rust-lang organization is on vertsion 20200908.1, while the
rust-lang-ci organization is at version 20200901.1 (and is not affected
by this yet).

There is no need for this step anymore on GHA, as our XL builders got an
increase in the root paritition size, so this commit removes the code
that moved stuff around on GHA (while keeping it on Azure).

For the record, at the time of writing this, the disk situation is:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       667G   60G  607G   9% /
/dev/sdb1       110G  4.1G  101G   4% /mnt

rustbuild: Build tests with LLD if `use-lld = true` was passed

Addresses https://github.com/rust-lang/rust/pull/76127#discussion_r479932392.

Our test suite is generally ready to run with an explicitly specified linker (https://github.com/rust-lang/rust/pull/45191),
 so LLD specified with `use-lld = true` works as well.

Only 4 tests fail (on `x86_64-pc-windows-msvc`):
```
ui/panic-runtime/lto-unwind.rs
run-make-fulldeps/debug-assertions
run-make-fulldeps/foreign-exceptions
run-make-fulldeps/test-harness
```
All of them are legitimate issues with LLD (or at least with combination Rust+LLD) and manifest in segfaults on access to TLS (https://github.com/rust-lang/rust/pull/76127#issuecomment-683473325). UPD: These issues are caused by https://github.com/rust-lang/rust/issues/72145 and appear because I had `-Ctarget-cpu=native` set.

UPD: Further commits build tests with LLD for non-MSVC targets and propagate LLD to more places when `use-lld` is enabled.

Rename IsJoint -> Spacing

Builds on #76286 and might conflict with #76285

r? `@petrochenkov`

print the unit type `()` in related lint messages.

changelog: print the unit type `()` in related lint messages