We can't do it for everything, but it would be nice to at least stop making calls to clone methods in debug from things like derived-clones.

Treat constant values as mir::ConstantKind::Val

Another step that is necessary for the introduction of Valtrees: we don't want to treat `ty::Const` instances of kind `ty::ConstKind::Value` as `mir::ConstantKind::Ty` anymore.

r? `@oli-obk`

Rollup of 8 pull requests

Successful merges:

 - #91804 (Make some `Clone` impls `const`)
 - #92541 (Mention intent of `From` trait in its docs)
 - #93057 (Add Iterator::collect_into)
 - #94739 (Suggest `if let`/`let_else` for refutable pat in `let`)
 - #94754 (Warn users about `||` in let chain expressions)
 - #94763 (Add documentation about lifetimes to thread::scope.)
 - #94768 (Ignore `close_read_wakes_up` test on SGX platform)
 - #94772 (Add miri to the well known conditional compilation names and values)

Failed merges:

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

add `#[rustc_pass_by_value]` to more types

the only interesting changes here should be to `TransitiveRelation`, but I believe to be highly unlikely that we will ever use a non `Copy` type with this type.

Add miri to the well known conditional compilation names and values

This pull request adds `miri` to the list of well known names and values of the conditional compilation checking (`--check-cfg`).

This was brought up in [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/RFC.203013.3A.20Checking.20conditional.20compilation.20at.20compile.20time/near/274513827) when discussing about the future of `--check-cfg`.

r? ``@petrochenkov``

Ignore `close_read_wakes_up` test on SGX platform

PR #94714 enabled the `close_read_wakes_up` test for all platforms. This is incorrect. This test should be ignored at least for the SGX platform.

cc: ``@mzohreva`` ``@jethrogb``

Add documentation about lifetimes to thread::scope.

This resolves the last unresolved question of https://github.com/rust-lang/rust/issues/93203

This was brought up in https://github.com/rust-lang/rust/pull/94559#discussion_r820872694

r? `````@Mark-Simulacrum`````

Warn users about `||` in let chain expressions

Or more specifically, warn that `||` operators are forbidden.

This PR is simple so I guess anyone can review 🤷

cc #53667
cc ``@matthewjasper``

Suggest `if let`/`let_else` for refutable pat in `let`

r? `````@oli-obk`````

Add Iterator::collect_into

This PR adds `Iterator::collect_into` as proposed by ``@cormacrelf`` in #48597 (see https://github.com/rust-lang/rust/pull/48597#issuecomment-842083688).
Followup of #92982.

This adds the following method to the Iterator trait:

```rust
fn collect_into<E: Extend<Self::Item>>(self, collection: &mut E) -> &mut E
```

Mention intent of `From` trait in its docs

This pr is a docs modification to add to the documentation of the `From` trait a note about its intent as a perfect conversion.  This is already stated in the `TryFrom` docs so this is simply adding that information in a more visible way.

Make some `Clone` impls `const`

Tracking issue: #91805
`Clone::clone_from` and some impls (Option, Result) bounded on `~const Drop`.

```rust
// core::clone
impl const Clone for INTEGER
impl const Clone for FLOAT
impl const Clone for bool
impl const Clone for char
impl const Clone for !
impl<T: ?Sized> const Clone for *const T
impl<T: ?Sized> const Clone for *mut T
impl<T: ?Sized> const Clone for &T

// core::option
impl<T> const Clone for Option<T>
where
    T: ~const Clone + ~const Drop

// core::result
impl<T, E> const Clone for Result<T, E>
where
    T: ~const Clone + ~const Drop,
    E: ~const Clone + ~const Drop,

// core::convert
impl const Clone for Infallible

// core::ptr
impl<T: ?Sized> const Clone for NonNull<T>
impl<T: ?Sized> const Clone for Unique<T>
```

Fix spurious CI failures

This should fix the CI error encountered in https://github.com/rust-lang/rust/pull/94774 (and multiple others).

cc `@nikic`

Tweak move error

Point at method definition that causes type to be consumed.

Fix #94056.

Rollup of 6 pull requests

Successful merges:

 - #94312 (Edit `rustc_trait_selection::infer::lattice` docs)
 - #94583 (Add a team for '`@rustbot` ping fuchsia')
 - #94686 (Do not allow `#[rustc_legacy_const_generics]` on methods)
 - #94699 (BTree: remove dead data needlessly complicating insert)
 - #94756 (Use `unreachable!` for an unreachable code path)
 - #94759 (Update cargo)

Failed merges:

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

Update cargo

11 commits in 3d6970d50e30e797b8e26b2b9b1bdf92dc381f34..65c82664263feddc5fe2d424be0993c28d46377a
2022-02-28 19:29:07 +0000 to 2022-03-09 02:32:56 +0000
- Remove remaining 2 warn(clippy::*) instances (rust-lang/cargo#10438)
- Use `available_parallelism` instead of `num_cpus` (rust-lang/cargo#10427)
- Wait up to one second while waiting for curl (rust-lang/cargo#10456)
- Improve code coverage (rust-lang/cargo#10460)
- Don't recommend leaking tokens into the console history (rust-lang/cargo#10458)
- fix some typos (rust-lang/cargo#10454)
- Use `extend` instead of `push`ing in a loop (rust-lang/cargo#10453)
- Use locked_version more (rust-lang/cargo#10449)
- Disable dependabot (rust-lang/cargo#10443)
- Update git2 dependencies (rust-lang/cargo#10442)
- Stop gating stable features (rust-lang/cargo#10434)

Use `unreachable!` for an unreachable code path

Closes #73212

BTree: remove dead data needlessly complicating insert

Possibly needless instructions generated

r? rust-lang/libs
r? ``@Amanieu``
cc ``@frank-king``

Do not allow `#[rustc_legacy_const_generics]` on methods

It caused an ICE since `item` was `None`.

Fixes #94629.

Add a team for '@rustbot ping fuchsia'

I was looking for this in response to https://github.com/rust-lang/rust/pull/93858#issuecomment-1041367498.

Depends on https://github.com/rust-lang/team/pull/710.

Edit `rustc_trait_selection::infer::lattice` docs

Closes #94311.

Removes mentions of outdated/missing type and filename (`infer.rs` and `LatticeValue`).

unix: reduce the size of DirEntry

On platforms where we call `readdir` instead of `readdir_r`, we store
the name as an allocated `CString` for variable length. There's no point
carrying around a full `dirent64` with its fixed-length `d_name` too.

Rollup of 5 pull requests

Successful merges:

 - #94689 (Use impl substs in `#[rustc_on_unimplemented]`)
 - #94714 (Enable `close_read_wakes_up` test on Windows)
 - #94723 (Add core::hint::must_use)
 - #94724 (unix: Avoid name conversions in `remove_dir_all_recursive`)
 - #94730 (Reverted atomic_mut_ptr feature removal causing compilation break)

Failed merges:

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

Reverted atomic_mut_ptr feature removal causing compilation break

Fixes a regression introduced as part of https://github.com/rust-lang/rust/pull/94546

Std no longer compiles on nightly while using the following commnd:

export RUSTFLAGS='-C target-feature=+atomics,+bulk-memory'
cargo build --target wasm32-unknown-unknown -Z build-std=panic_abort,std

I can help add tests to avoid future breaks but i couldn't understand the test framework

unix: Avoid name conversions in `remove_dir_all_recursive`

Each recursive call was creating an `OsString` for a `&Path`, only for
it to be turned into a `CString` right away. Instead we can directly
pass `.name_cstr()`, saving two allocations each time.

Add core::hint::must_use

The example code in this documentation is minimized from a real-world situation in the `anyhow` crate where this function would have been valuable.

Having this provided by the standard library is especially useful for proc macros, even more than for macro_rules. That's because proc macro crates aren't allowed to export anything other than macros, so they couldn't make their own `must_use` function for their macro-generated code to call.

<br>

## Rendered documentation

> An identity function that causes an `unused_must_use` warning to be triggered if the given value is not used (returned, stored in a variable, etc) by the caller.
>
> This is primarily intended for use in macro-generated code, in which a [`#[must_use]` attribute][must_use] either on a type or a function would not be convenient.
>
> [must_use]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-must_use-attribute
>
> ### Example
>
> ```rust
> #![feature(hint_must_use)]
>
> use core::fmt;
>
> pub struct Error(/* ... */);
>
> #[macro_export]
> macro_rules! make_error {
>     ($($args:expr),*) => {
>         core::hint::must_use({
>             let error = $crate::make_error(core::format_args!($($args),*));
>             error
>         })
>     };
> }
>
> // Implementation detail of make_error! macro.
> #[doc(hidden)]
> pub fn make_error(args: fmt::Arguments<'_>) -> Error {
>     Error(/* ... */)
> }
>
> fn demo() -> Option<Error> {
>     if true {
>         // Oops, meant to write `return Some(make_error!("..."));`
>         Some(make_error!("..."));
>     }
>     None
> }
> ```
>
> In the above example, we'd like an `unused_must_use` lint to apply to the value created by `make_error!`. However, neither `#[must_use]` on a struct nor `#[must_use]` on a function is appropriate here, so the macro expands using `core::hint::must_use` instead.
>
> - We wouldn't want `#[must_use]` on the `struct Error` because that would make the following unproblematic code trigger a warning:
>
>   ```rust
>   fn f(arg: &str) -> Result<(), Error>
>
>   #[test]
>   fn t() {
>       // Assert that `f` returns error if passed an empty string.
>       // A value of type `Error` is unused here but that's not a problem.
>       f("").unwrap_err();
>   }
>   ```
>
> - Using `#[must_use]` on `fn make_error` can't help because the return value *is* used, as the right-hand side of a `let` statement. The `let` statement looks useless but is in fact necessary for ensuring that temporaries within the `format_args` expansion are not kept alive past the creation of the `Error`, as keeping them alive past that point can cause autotrait issues in async code:
>
>   ```rust
>   async fn f() {
>       // Using `let` inside the make_error expansion causes temporaries like
>       // `unsync()` to drop at the semicolon of that `let` statement, which
>       // is prior to the await point. They would otherwise stay around until
>       // the semicolon on *this* statement, which is after the await point,
>       // and the enclosing Future would not implement Send.
>       log(make_error!("look: {:p}", unsync())).await;
>   }
>
>   async fn log(error: Error) {/* ... */}
>
>   // Returns something without a Sync impl.
>   fn unsync() -> *const () {
>       0 as *const ()
>   }
>   ```