PR rust-lang#93918 made it so that `-static-libstdc++` was only set in one place,
and was only set during linking, but accidentally also made it so that
it is no longer passed when building LLD or sanitizers, only when
building LLVM itself. This moves the logic for setting
`-static-libstdc++` in the linker flags back to `configure_cmake` so
that it takes effect for all CMake invocations in `native.rs`.

As a side-effect, this also causes libstdc++ to be statically compiled
into sanitizers and LLD if `llvm-tools-enabled` is set but
`llvm-static-stdcpp` is not, even though previously it was only linked
statically if `llvm-static-stdcpp` was set explicitly. But that seems
more like the expected behavior anyway.

Signed-off-by: JmPotato <[email protected]>

Make some `Clone` impls `const`

Tracking issue: rust-lang#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>
```

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.

Add Iterator::collect_into

This PR adds `Iterator::collect_into` as proposed by `@cormacrelf` in rust-lang#48597 (see rust-lang#48597 (comment)).
Followup of rust-lang#92982.

This adds the following method to the Iterator trait:

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

…tion, r=lcnr

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`

…aaaa, r=petrochenkov

[1/2] Implement macro meta-variable expressions

See rust-lang#93545 (comment)

The logic behind `length`, `index` and `count` was removed but the parsing code is still present, i.e., everything is simply ignored like `ignored`.

r? `@petrochenkov`

…ue, r=m-ou-se

Use MaybeUninit in VecDeque to remove the undefined behavior of slice

Signed-off-by: JmPotato <[email protected]>

Ref rust-lang#74189. Adjust the code to follow the [doc.rust-lang.org/reference/behavior-considered-undefined.html](https://doc.rust-lang.org/reference/behavior-considered-undefined.html).

* Change the return type of `buffer_as_slice` from `&[T]` to `&[MaybeUninit<T>]`.
* Add some corresponding safety comments.

Benchmark results:

master 8d6f527

```rust
test collections::vec_deque::tests::bench_pop_back_100       ... bench:          47 ns/iter (+/- 1)
test collections::vec_deque::tests::bench_pop_front_100      ... bench:          50 ns/iter (+/- 4)
test collections::vec_deque::tests::bench_push_back_100      ... bench:          69 ns/iter (+/- 10)
test collections::vec_deque::tests::bench_push_front_100     ... bench:          72 ns/iter (+/- 6)
test collections::vec_deque::tests::bench_retain_half_10000  ... bench:     145,891 ns/iter (+/- 7,975)
test collections::vec_deque::tests::bench_retain_odd_10000   ... bench:     141,647 ns/iter (+/- 3,711)
test collections::vec_deque::tests::bench_retain_whole_10000 ... bench:     120,132 ns/iter (+/- 4,078)
```

This PR

```rust
test collections::vec_deque::tests::bench_pop_back_100       ... bench:          48 ns/iter (+/- 2)
test collections::vec_deque::tests::bench_pop_front_100      ... bench:          51 ns/iter (+/- 3)
test collections::vec_deque::tests::bench_push_back_100      ... bench:          73 ns/iter (+/- 2)
test collections::vec_deque::tests::bench_push_front_100     ... bench:          73 ns/iter (+/- 2)
test collections::vec_deque::tests::bench_retain_half_10000  ... bench:     131,796 ns/iter (+/- 5,440)
test collections::vec_deque::tests::bench_retain_odd_10000   ... bench:     137,563 ns/iter (+/- 3,349)
test collections::vec_deque::tests::bench_retain_whole_10000 ... bench:     128,815 ns/iter (+/- 3,289)
```

…ss, r=joshtriplett

Fix soundness issue in scoped threads.

This was discovered in rust-lang#94559 (comment)

The `scope()` function returns when all threads are finished, but I accidentally considered a thread 'finished' before dropping their panic payload or ignored return value.

So if a thread returned (or panics with) something that in its `Drop` implementation still uses borrowed stuff, it goes wrong.

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=2a1f19ac4676cdabe43e24e536ff9358

Constify `Index{,Mut}` for `[T]`, `str`, and `[T; N]`

Several panic functions were rewired (via `const_eval_select`) to simpler implementations that do not require formatting for compile-time usage.

r? ``@oli-obk``

…mulacrum

Statically compile libstdc++ everywhere if asked

PR rust-lang#93918 made it so that `-static-libstdc++` was only set in one place,
and was only set during linking, but accidentally also made it so that
it is no longer passed when building LLD, only when building LLVM
itself. This moves the logic for setting `-static-libstdc++` in the
linker flags to `configure_cmake` so that it takes effect for all CMake
invocations in `native.rs`.

As a side-effect, this also causes libstdc++ to be statically compiled
into sanitizers, whereas previously the `llvm-static-stdcpp` flag had no
effect on sanitizers. It also makes it so that LLD will be compiled
statically if `llvm-tools-enabled` is set, even though previously it was
only linked statically if `llvm-static-stdcpp` was set explicitly. Both
of these seem like they match expected behavior than what was there
prior to rust-lang#93918.

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

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

…=notriddle

Unify impl blocks by wrapping them into a div

The blanket and "auto traits" sections are wrapped into a `div` with an ID. This PR fixes this incoherence by wrapping each impl section (the "deref impl" and the "inherent impl" sections were missing it). It'll also make some tests simpler to write.

r? ```@notriddle```

…GuillaumeGomez

Improve rustdoc book

This pull-request improves the `rustdoc` book by doing some (light) cleanup, by merging some stuff, by adding some missing stuff (like tracking issues links, for those who had one) and also by moving some chapter's into sub-chapter's to improve the flow of the book.

~~Note that I locally tested with `mdbook-lintcheck` that no links became accidentally broken.~~ (Not enough, ;-))

r? ```@GuillaumeGomez```

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 rust-lang#53667
cc `@matthewjasper`

…s, r=Mark-Simulacrum

Add documentation about lifetimes to thread::scope.

This resolves the last unresolved question of rust-lang#93203

This was brought up in rust-lang#94559 (comment)

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

…_up_test_sgx_platform, r=dtolnay

Ignore `close_read_wakes_up` test on SGX platform

PR rust-lang#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 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`