Auto merge of #85391 - Mark-Simulacrum:opt-tostring, r=scottmcm

Avoid zero-length memcpy in formatting

This has two separate and somewhat orthogonal commits. The first change adjusts the ToString general impl for all types that implement Display; it no longer uses the full format machinery, rather directly falling onto a `std::fmt::Display::fmt` call. The second change directly adjusts the general core::fmt::write function which handles the production of format_args! to avoid zero-length push_str calls.

Both changes target the fact that push_str will still call memmove internally (or a similar function), as it doesn't know the length of the passed string. For zero-length strings in particular, this is quite expensive, and even for very short (several bytes long) strings, this is also expensive. Future work in this area may wish to have us fallback to write_char or similar, which may be cheaper on the (typically) short strings between the interpolated pieces in format_args!.

Auto merge of #85340 - the8472:no-inplaceiterable-on-peekable, r=yaahc

remove InPlaceIterable marker from Peekable due to unsoundness

The unsoundness is not in Peekable per se, it rather is due to the
interaction between Peekable being able to hold an extra item
and vec::IntoIter's clone implementation shortening the allocation.

An alternative solution would be to change IntoIter's clone implementation
to keep enough spare capacity available.

fixes #85322

Auto merge of #83842 - LeSeulArtichaut:thir-vec, r=nikomatsakis

Store THIR in `IndexVec`s instead of an `Arena`

This is a necessary step to store the THIR in a query: #85273. See [relevant discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/278509-project-thir-unsafeck/topic/THIR-dependent.20queries.20design).

r? `@ghost` cc `@cjgillot` `@nikomatsakis`

Auto merge of #84876 - alexcrichton:inline-thread-locals-cross-crate, r=Mark-Simulacrum

std: Attempt again to inline thread-local-init across crates

Issue #25088 has been part of `thread_local!` for quite some time now.
Historical attempts have been made to add `#[inline]` to `__getit`
in #43931, #50252, and #59720, but these attempts ended up not landing
at the time due to segfaults on Windows.

In the interim though with `const`-initialized thread locals AFAIK this
is the only remaining bug which is why you might want to use
`#[thread_local]` over `thread_local!`. As a result I figured it was
time to resubmit this and see how it fares on CI and if I can help
debugging any issues that crop up.

Closes #25088

Adapt the THIR visitor to the vec-stored THIR

Store THIR in `IndexVec`s instead of an `Arena`

Auto merge of #85376 - RalfJung:ptrless-allocs, r=oli-obk

CTFE core engine allocation & memory API improvemenets

This is a first step towards https://github.com/rust-lang/miri/issues/841.
- make `Allocation` API offset-based (no more making up `Pointer`s just to access an `Allocation`)
- make `Memory` API higher-level (combine checking for access and getting access into one operation)

The Miri-side PR is at https://github.com/rust-lang/miri/pull/1804.
r? `@oli-obk`

Auto merge of #85276 - Bobo1239:more_dso_local, r=nagisa

Set dso_local for more items

Related to https://github.com/rust-lang/rust/pull/83592. (cc `@nagisa)`

Noticed that on x86_64 with `relocation-model: static` `R_X86_64_GOTPCREL` relocations were still generated in some cases. (related: https://github.com/Rust-for-Linux/linux/issues/135; Rust-for-Linux needs these fixes to successfully build)

First time doing anything with LLVM so not sure whether this is correct but the following are some of the things I've tried to convince myself.

## C equivalent

Example from clang which also sets `dso_local` in these cases:
`clang-12 -fno-PIC -S -emit-llvm test.c`
```C
extern int A;

int* a() {
    return &A;
}

int B;

int* b() {
    return &B;
}
```
```
; ModuleID = 'test.c'
source_filename = "test.c"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

`@A` = external dso_local global i32, align 4
`@B` = dso_local global i32 0, align 4

; Function Attrs: noinline nounwind optnone uwtable
define dso_local i32* `@a()` #0 {
  ret i32* `@A`
}

; Function Attrs: noinline nounwind optnone uwtable
define dso_local i32* `@b()` #0 {
  ret i32* `@B`
}

attributes #0 = { noinline nounwind optnone uwtable "disable-tail-calls"="false" "frame-pointer"="all" "less-precise-fpmad"="false" "min-legal-vector-width"="0" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "unsafe-fp-math"="false" "use-soft-float"="false" }

!llvm.module.flags = !{!0}
!llvm.ident = !{!1}

!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{!"clang version 12.0.0 (https://github.com/llvm/llvm-project/ b978a93635b584db380274d7c8963c73989944a1)"}
```
`clang-12 -fno-PIC -c test.c`
`objdump test.o -r`:
```
test.o:     file format elf64-x86-64

RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE              VALUE
0000000000000006 R_X86_64_64       A
0000000000000016 R_X86_64_64       B

RELOCATION RECORDS FOR [.eh_frame]:
OFFSET           TYPE              VALUE
0000000000000020 R_X86_64_PC32     .text
0000000000000040 R_X86_64_PC32     .text+0x0000000000000010
```

## Comparison to pre-LLVM 12 output

`rustc --emit=obj,llvm-ir --target=x86_64-unknown-none-linuxkernel --crate-type rlib test.rs`
```Rust
#![feature(no_core, lang_items)]
#![no_core]

#[lang="sized"]
trait Sized {}

#[lang="sync"]
trait Sync {}

#[lang = "drop_in_place"]
pub unsafe fn drop_in_place<T: ?Sized>(_: *mut T) {}

impl Sync for i32 {}

pub static STATIC: i32 = 32;

extern {
    pub static EXT_STATIC: i32;
}

pub fn a() -> &'static i32 {
    &STATIC
}
pub fn b() -> &'static i32 {
    unsafe {&EXT_STATIC}
}
```
`objdump test.o -r`
nightly-2021-02-20 (rustc target is `x86_64-linux-kernel`):
```
RELOCATION RECORDS FOR [.text._ZN4test1a17h1024ba65f3424175E]:
OFFSET           TYPE              VALUE
0000000000000007 R_X86_64_32S      _ZN4test6STATIC17h3adc41a83746c9ffE

RELOCATION RECORDS FOR [.text._ZN4test1b17h86a6a80c1190ac8dE]:
OFFSET           TYPE              VALUE
0000000000000007 R_X86_64_32S      EXT_STATIC
```
nightly-2021-05-10:
```
RELOCATION RECORDS FOR [.text._ZN4test1a17he846f03bf37b2d20E]:
OFFSET           TYPE              VALUE
0000000000000007 R_X86_64_GOTPCREL  _ZN4test6STATIC17h5a059515bf3d4968E-0x0000000000000004

RELOCATION RECORDS FOR [.text._ZN4test1b17h7e0f7f80fbd91125E]:
OFFSET           TYPE              VALUE
0000000000000007 R_X86_64_GOTPCREL  EXT_STATIC-0x0000000000000004
```
This PR:
```
RELOCATION RECORDS FOR [.text._ZN4test1a17he846f03bf37b2d20E]:
OFFSET           TYPE              VALUE
0000000000000007 R_X86_64_32S      _ZN4test6STATIC17h5a059515bf3d4968E

RELOCATION RECORDS FOR [.text._ZN4test1b17h7e0f7f80fbd91125E]:
OFFSET           TYPE              VALUE
0000000000000007 R_X86_64_32S      EXT_STATIC
```

Auto merge of #85458 - jackh726:rollup-zvvybmt, r=jackh726

Rollup of 8 pull requests

Successful merges:

 - #83366 (Stabilize extended_key_value_attributes)
 - #83767 (Fix v0 symbol mangling bug)
 - #84883 (compiletest: "fix" FileCheck with --allow-unused-prefixes)
 - #85274 (Only pass --[no-]gc-sections if linker is GNU ld.)
 - #85297 (bootstrap: build cargo only if requested in tools)
 - #85396 (rustdoc: restore header sizes)
 - #85425 (Fix must_use on `Option::is_none`)
 - #85438 (Fix escape handling)

Failed merges:

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

Rollup merge of #85438 - GuillaumeGomez:fix-escape-handling, r=jsha

Fix escape handling

Currently, when we press Escape while on the search results, nothing is happening, this PR fixes it.

More information: it's because in case the element doesn't exist, `hasClass` will return `null`, which coerces into `false` with the `!` comparison operator. But even if it returned `false`, it would still be an issue because if the element doesn't exist, it means it's hidden so in this case it's just as good, hence the additional check I added.

r? ``@jsha``

Rollup merge of #85425 - mbartlett21:patch-1, r=scottmcm

Fix must_use on `Option::is_none`

This fixes the `#[must_use = ...]` on `Option::is_none` to have a working suggestion.

Rollup merge of #85396 - jsha:top-doc-font-sizes, r=GuillaumeGomez

rustdoc: restore header sizes

The `<details>` toggle work changed the relationship from #main to the top-doc docblock so it was no longer a parent relationship but a great-grandparent relationship. This updates the CSS rules that set the heading sizes so they still apply.

Fixes #85389

r? ``@camelid``

Rollup merge of #85297 - infinity0:master, r=Mark-Simulacrum

bootstrap: build cargo only if requested in tools

In Debian we'd like to build rustfmt and clippy alongside rustc, but we're still excluding cargo from the rustc build and doing that separately. This patch makes that possible.

Rollup merge of #85274 - luqmana:linker-is-gnu-gc-sections, r=petrochenkov

Only pass --[no-]gc-sections if linker is GNU ld.

Fixes a regression from #84468 where linking now fails with solaris linkers. LinkerFlavor::Gcc does not always mean GNU ld specifically. And in the case of at least the solaris ld in illumos, that flag is unrecognized and will cause the linking step to fail.

Even though removing the `is_like_solaris` branch from `gc_sections` in #84468 made sense as `-z ignore/record` are more analogous to the `--[no-]-as-needed` flags, it inadvertently caused solaris linkers to be passed the `--gc-sections` flag. So let's just change it to be more explicit about when we pass those flags.

Rollup merge of #84883 - durin42:allow-unused-prefixes, r=nikic

compiletest: "fix" FileCheck with --allow-unused-prefixes

The default of --allow-unused-prefixes used to be false, but in LLVM
change 87dbdd2e3b (https://reviews.llvm.org/D95849) the default became
true. I'm not quite sure how we could do better here (specifically not
providing the CHECK prefix when it's not needed), but this seems to work
for now.

This reduces codegen test failures against LLVM HEAD from 31 cases to 5.

Rollup merge of #83767 - camelid:mangle-v0-fix, r=nikomatsakis

Fix v0 symbol mangling bug

Fixes #83611.

r? ``@jackh726``

Rollup merge of #83366 - jyn514:stabilize-key-value-attrs, r=petrochenkov

Stabilize extended_key_value_attributes

Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant).

 # Stabilization report

 ## Summary

This stabilizes using macro expansion in key-value attributes, like so:

 ```rust
 #[doc = include_str!("my_doc.md")]
 struct S;

 #[path = concat!(env!("OUT_DIR"), "/generated.rs")]
 mod m;
 ```

See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455)
for alternatives that were considered and rejected ("why accept no more and no less?")

This has been available on nightly since 1.50 with no major issues.

## Notes

### Accepted syntax

The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`).  Note that decorators and the like may be able to observe other expression forms.

### Expansion ordering

Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input.

There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work).

## Test cases

 - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs
 - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs

The feature has also been dogfooded extensively in the compiler and
standard library:

- https://github.com/rust-lang/rust/pull/83329
- https://github.com/rust-lang/rust/pull/83230
- https://github.com/rust-lang/rust/pull/82641
- https://github.com/rust-lang/rust/pull/80534

## Implementation history

- Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412
- Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121
- Preliminary work to restrict expansion that would conflict with this
feature: https://github.com/rust-lang/rust/pull/77271
- Initial implementation: https://github.com/rust-lang/rust/pull/78837
- Fix for an ICE: https://github.com/rust-lang/rust/pull/80563

## Unresolved Questions

~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns, but they have been resolved as of this final report.~~

 ## Additional Information

 There are two workarounds that have a similar effect for `#[doc]`
attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons:

```rust
macro_rules! forward_inner_docs {
    ($e:expr => $i:item) => {
        #[doc = $e]
        $i
    };
}

forward_inner_docs!(include_str!("lib.rs") => struct S {});
```

This also works for other attributes (like `#[path = concat!(...)]`).
The other is to use `doc(include)`:

```rust
 #![feature(external_doc)]
 #[doc(include = "lib.rs")]
 struct S {}
```

The first works, but is non-trivial for people to discover, and
difficult to read and maintain. The second is a strange special-case for
a particular use of the macro. This generalizes it to work for any use
case, not just including files.

I plan to remove `doc(include)` when this is stabilized
(https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs`
workaround will still compile without warnings, but I expect it to be
used less once it's no longer necessary.

Auto merge of #85176 - a1phyr:impl_clone_from, r=yaahc

Override `clone_from` for some types

Override `clone_from` method of the `Clone` trait for:
- `cell::RefCell`
- `cmp::Reverse`
- `io::Cursor`
- `mem::ManuallyDrop`

This can bring performance improvements.

from review: more robust test

This also checks the contents and not only the capacity in case IntoIter's clone implementation is changed to add capacity at the end. Extra capacity at the beginning would be needed to make InPlaceIterable work.

Co-authored-by: Giacomo Stevanato <giaco.stevanato@gmail.com>

add regression test

remove InPlaceIterable marker from Peekable due to unsoundness

The unsoundness is not in Peekable per se, it rather is due to the
interaction between Peekable being able to hold an extra item
and vec::IntoIter's clone implementation shortening the allocation.

An alternative solution would be to change IntoIter's clone implementation
to keep enough spare capacity available.

Auto merge of #84767 - scottmcm:try_trait_actual, r=lcnr

Implement the new desugaring from `try_trait_v2`

~~Currently blocked on https://github.com/rust-lang/rust/issues/84782, which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix.

`try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277

Unfortunately this is already touching a ton of things, so if you have suggestions for good ways to split it up, I'd be happy to hear them.  (The combination between the use in the library, the compiler changes, the corresponding diagnostic differences, even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits.

r? `@ghost`

~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.

No matter how trivial the change, tidy always finds a way to complain...

Mention the issue number for the new mir-opt in the FIXMEs

Thanks for the suggestions, lcnr!

Co-authored-by: lcnr <rust@lcnr.de>

std: Attempt again to inline thread-local-init across crates

Issue #25088 has been part of `thread_local!` for quite some time now.
Historical attempts have been made to add `#[inline]` to `__getit`
in #43931, #50252, and #59720, but these attempts ended up not landing
at the time due to segfaults on Windows.

In the interim though with `const`-initialized thread locals AFAIK this
is the only remaining bug which is why you might want to use
`#[thread_local]` over `thread_local!`. As a result I figured it was
time to resubmit this and see how it fares on CI and if I can help
debugging any issues that crop up.

Closes #25088

Set dso_local for more items

Fix assembly test from #83592

The test case wasn't actually checked for x64 due to a small difference in the name.

Auto merge of #85443 - RalfJung:rollup-d9gd64t, r=RalfJung

Rollup of 7 pull requests

Successful merges:

 - #84462 (rustdoc: use focus for search navigation)
 - #85251 (Make `const_generics_defaults` not an incomplete feature)
 - #85404 (Backport 1.52.1 release notes)
 - #85407 (Improve display for "copy-path" button, making it more discreet)
 - #85423 (Don't require cmake on Windows when LLVM isn't being built)
 - #85428 (Add x.py pre-setup instructions)
 - #85442 (fix typo)

Failed merges:

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

Rollup merge of #85442 - imjorge:patch-1, r=jonas-schievink

fix typo

Rollup merge of #85428 - leebradley:add-xpy-presetup-instructions, r=Mark-Simulacrum

Add x.py pre-setup instructions

This change adds pre-setup instructions that outline how x.py requires
python to be setup and how to work around the problem of x.py failing to
locate python, especially now that Ubuntu 20.04's dropped default python
command is causing people to encounter this issue regularly.

See also: #71818

Rollup merge of #85423 - jyn514:cmake, r=Mark-Simulacrum

Don't require cmake on Windows when LLVM isn't being built

Previously, setting `download-ci-llvm = true` when cmake wasn't
installed would give the following error:

```
failed to execute command: "cmake" "--help"
error: The system cannot find the file specified. (os error 2)
```

Rollup merge of #85407 - GuillaumeGomez:copy-path-display-improvement, r=jsha

Improve display for "copy-path" button, making it more discreet

As suggested by `@Nemo157` [here](https://github.com/rust-lang/rust/pull/85118#issuecomment-838887670):


r? `@jsha`

Rollup merge of #85404 - pietroalbini:relnotes-1.52.1, r=Mark-Simulacrum

Backport 1.52.1 release notes

This PR backports the 1.52.1 release notes to master, fixing https://github.com/rust-lang/rust/issues/85235.

r? `@Mark-Simulacrum`
`@rustbot` modify-labels: beta-accepted beta-nominated T-release

Rollup merge of #85251 - BoxyUwU:constparamdefaultsany%, r=lcnr

Make `const_generics_defaults` not an incomplete feature

r? `@lcnr`

Rollup merge of #84462 - jsha:focus-search-results2, r=GuillaumeGomez

rustdoc: use focus for search navigation

Rather than keeping track of highlighted element inside the JS, take advantage of `.focus()` and the :focus CSS pseudo-class.

This required wrapping each row of results in one big `<a>` tag (because anchors can be focused, but table rows cannot). That in turn required moving from a table layout to a div layout with float.

This makes it so Ctrl+Enter opens links in new tabs, and using the arrow keys to navigate off the bottom of the page scrolls the rest of the page into view. It also simplifies the keyboard event handling. It eliminates the need for click handlers on the search results, and for tracking mouse movements.

This changes the UI treatment of mouse hovering. A hovered element now gets a light grey background, but does not change the focus. It's possible to have two highlighted search results: one that is focused (via keyboard) and one that is hovered (via mouse). Pressing enter will activate the focused link; clicking will activate the hovered link. This matches up with how Firefox and Chrome handle suggestions in their URL bar, and avoids stray mouse movements changing the focus.

Selecting tabs is now done with left/right arrows while any search result is focused. The visibility of results on each search tab is
controlled with the "active" class, rather than by setting display: none directly. Note that the old code kept track of highlighted search element when tabbing back and forth. The new code doesn't.

Demo at https://hoffman-andrews.com/rust/focus-search-results2/std/?search=fn

Fixes #84384
Fixes #79962
Fixes #79872

fix mplace_access_checked with forced alignment

add Align::ONE; add methods to access alloc.extra

reduce number of allocation lookups during copy

CTFE core engine allocation & memory API improvemenets

- make Allocation API offset-based (no more Pointer)
- make Memory API higher-level (combine checking for access and getting access into one operation)

fix typo

Auto merge of #85437 - GuillaumeGomez:rollup-3jcirty, r=GuillaumeGomez

Rollup of 7 pull requests

Successful merges:

 - #84587 (rustdoc: Make "rust code block is empty" and "could not parse code block" warnings a lint (`INVALID_RUST_CODEBLOCKS`))
 - #85280 (Toggle-wrap items differently than top-doc.)
 - #85338 (Implement more Iterator methods on core::iter::Repeat)
 - #85339 (Report an error if a lang item has the wrong number of generic arguments)
 - #85369 (Suggest borrowing if a trait implementation is found for &/&mut <type>)
 - #85393 (Suppress spurious errors inside `async fn`)
 - #85415 (Clean up remnants of BorrowOfPackedField)

Failed merges:

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

Add GUI tests for escape handling

Fix escape handling on search results

Rollup merge of #85415 - LeSeulArtichaut:no-packed-borrow-unsafeck, r=RalfJung

Clean up remnants of BorrowOfPackedField

cc #82525 which removed `BorrowOfPackedField` from unsafety-checking
r? `@RalfJung`

Rollup merge of #85393 - Aaron1011:async-type-err, r=varkor

Suppress spurious errors inside `async fn`

Fixes #73741

Rollup merge of #85369 - FabianWolff:issue-84973, r=jackh726

Suggest borrowing if a trait implementation is found for &/&mut <type>

This pull request fixes #84973 by suggesting to borrow if a trait is not implemented for some type `T`, but it is for `&T` or `&mut T`. For instance:
```rust
trait Ti {}
impl<T> Ti for &T {}
fn foo<T: Ti>(_: T) {}

trait Tm {}
impl<T> Tm for &mut T {}
fn bar<T: Tm>(_: T) {}

fn main() {
    let a: i32 = 5;
    foo(a);

    let b: Box<i32> = Box::new(42);
    bar(b);
}
```
gives, on current nightly:
```
error[E0277]: the trait bound `i32: Ti` is not satisfied
  --> t2.rs:11:9
   |
3  | fn foo<T: Ti>(_: T) {}
   |           -- required by this bound in `foo`
...
11 |     foo(a);
   |         ^ the trait `Ti` is not implemented for `i32`

error[E0277]: the trait bound `Box<i32>: Tm` is not satisfied
  --> t2.rs:14:9
   |
7  | fn bar<T: Tm>(_: T) {}
   |           -- required by this bound in `bar`
...
14 |     bar(b);
   |         ^ the trait `Tm` is not implemented for `Box<i32>`

error: aborting due to 2 previous errors
```
whereas with my changes, I get:
```
error[E0277]: the trait bound `i32: Ti` is not satisfied
  --> t2.rs:11:9
   |
3  | fn foo<T: Ti>(_: T) {}
   |           -- required by this bound in `foo`
...
11 |     foo(a);
   |         ^
   |         |
   |         expected an implementor of trait `Ti`
   |         help: consider borrowing here: `&a`

error[E0277]: the trait bound `Box<i32>: Tm` is not satisfied
  --> t2.rs:14:9
   |
7  | fn bar<T: Tm>(_: T) {}
   |           -- required by this bound in `bar`
...
14 |     bar(b);
   |         ^
   |         |
   |         expected an implementor of trait `Tm`
   |         help: consider borrowing mutably here: `&mut b`

error: aborting due to 2 previous errors
```
In my implementation, I have added a "blacklist" to make these suggestions flexible. In particular, suggesting to borrow can interfere with other suggestions, such as to add another trait bound to a generic argument. I have tried to configure this blacklist to cause the least amount of test case failures, i.e. to model the current behavior as closely as possible (I only had to change one existing test case, and this change was quite clearly an improvement).

Rollup merge of #85339 - FabianWolff:issue-83893, r=varkor

Report an error if a lang item has the wrong number of generic arguments

This pull request fixes #83893. The issue is that the lang item code currently checks whether the lang item has the correct item kind (e.g. a `#[lang="add"]` has to be a trait), but not whether the item has the correct number of generic arguments.

This can lead to an "index out of bounds" ICE when the compiler tries to create more substitutions than there are suitable types available (if the lang item was declared with too many generic arguments).

For instance, here is a reduced ("reduced" in the sense that it does not trigger additional errors) version of the example given in #83893:
```rust
#![feature(lang_items,no_core)]
#![no_core]
#![crate_type="lib"]

#[lang = "sized"]
trait MySized {}

#[lang = "add"]
trait MyAdd<'a, T> {}

fn ice() {
    let r = 5;
    let a = 6;
    r + a
}
```
On current nightly, this immediately causes an ICE without any warnings or errors emitted. With the changes in this PR, however, I get no ICE and two errors:
```
error[E0718]: `add` language item must be applied to a trait with 1 generic argument
 --> pr-ex.rs:8:1
  |
8 | #[lang = "add"]
  | ^^^^^^^^^^^^^^^
9 | trait MyAdd<'a, T> {}
  |            ------- this trait has 2 generic arguments, not 1

error[E0369]: cannot add `{integer}` to `{integer}`
  --> pr-ex.rs:14:7
   |
14 |     r + a
   |     - ^ - {integer}
   |     |
   |     {integer}

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0369, E0718.
For more information about an error, try `rustc --explain E0369`.
```

Rollup merge of #85338 - lopopolo:core-iter-repeat-gh-81292, r=joshtriplett

Implement more Iterator methods on core::iter::Repeat

`core::iter::Repeat` always returns the same element, which means we can
do better than implementing most `Iterator` methods in terms of
`Iterator::next`.

Fixes #81292.

#81292 raises the question of whether these changes violate the contract of `core::iter::Repeat`, but as far as I can tell `core::iter::repeat` doesn't make any guarantees around how it calls `Clone::clone`.

Rollup merge of #85280 - jsha:move-trait-toggles, r=GuillaumeGomez

Toggle-wrap items differently than top-doc.

This makes sure things like trait methods get wrapped at the
`<h3><code>` level rather than at the `.docblock` level. Also it ensures
that only the actual top documentation gets the `.top-doc` class.

Fixes #85167

Before:


https://doc.rust-lang.org/nightly/std/io/trait.Read.html#tymethod.read

After:


Rollup merge of #84587 - jyn514:rustdoc-lint-block, r=CraftSpider

rustdoc: Make "rust code block is empty" and "could not parse code block" warnings a lint (`INVALID_RUST_CODEBLOCKS`)

Fixes https://github.com/rust-lang/rust/issues/79792. This already went through FCP in https://github.com/rust-lang/rust/pull/79816, so it only needs final review.

This is mostly a rebase of https://github.com/rust-lang/rust/pull/79816 - thank you ``@poliorcetics`` for doing most of the work!

Auto merge of #85313 - jackh726:region_eq, r=nikomatsakis

Unify Regions with RegionVids in UnificationTable

A few test output changes; might be able to revert those but figured I would open this for perf and comments.

r? `@nikomatsakis`

Don't pass -pie to linker on windows targets.

Undo unnecessary changes.

Improve display for "copy-path" button, making it more discrete

Auto merge of #82973 - ijackson:exitstatuserror, r=yaahc

Provide ExitStatusError

Closes #73125

In MR #81452 "Add #[must_use] to [...] process::ExitStatus" we concluded that the existing arrangements in are too awkward so adding that `#[must_use]` is blocked on improving the ergonomics.

I wrote a mini-RFC-style discusion of the approach in https://github.com/rust-lang/rust/issues/73125#issuecomment-771092741

Add x.py pre-setup instructions

This change adds pre-setup instructions that outline how x.py requires
python to be setup and how to work around the problem of x.py failing to
locate python, especially now that Ubuntu 20.04's dropped default python
command is causing people to encounter this issue regularly.

See also: #71818

Stabilize extended_key_value_attributes

 # Stabilization report

 ## Summary

This stabilizes using macro expansion in key-value attributes, like so:

 ```rust
 #[doc = include_str!("my_doc.md")]
 struct S;

 #[path = concat!(env!("OUT_DIR"), "/generated.rs")]
 mod m;
 ```

See the changes to the reference for details on what macros are allowed;
see Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455)
for alternatives that were considered and rejected ("why accept no more
and no less?")

This has been available on nightly since 1.50 with no major issues.

 ## Notes

 ### Accepted syntax

The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`).  Note that decorators and the like may be able to observe other expression forms.

 ### Expansion ordering

Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input.

There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work).

 ## Test cases

 - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs
 - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs

The feature has also been dogfooded extensively in the compiler and
standard library:

- https://github.com/rust-lang/rust/pull/83329
- https://github.com/rust-lang/rust/pull/83230
- https://github.com/rust-lang/rust/pull/82641
- https://github.com/rust-lang/rust/pull/80534

 ## Implementation history

- Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412
- Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121
- Preliminary work to restrict expansion that would conflict with this
feature: https://github.com/rust-lang/rust/pull/77271
- Initial implementation: https://github.com/rust-lang/rust/pull/78837
- Fix for an ICE: https://github.com/rust-lang/rust/pull/80563

 ## Unresolved Questions

~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns, but they have been resolved as of this final report.~~

 ## Additional Information

 There are two workarounds that have a similar effect for `#[doc]`
attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons:

```rust
macro_rules! forward_inner_docs {
    ($e:expr => $i:item) => {
        #[doc = $e]
        $i
    };
}

forward_inner_docs!(include_str!("lib.rs") => struct S {});
```

This also works for other attributes (like `#[path = concat!(...)]`).
The other is to use `doc(include)`:

```rust
 #![feature(external_doc)]
 #[doc(include = "lib.rs")]
 struct S {}
```

The first works, but is non-trivial for people to discover, and
difficult to read and maintain. The second is a strange special-case for
a particular use of the macro. This generalizes it to work for any use
case, not just including files.

I plan to remove `doc(include)` when this is stabilized. The
`forward_inner_docs` workaround will still compile without warnings, but
I expect it to be used less once it's no longer necessary.

Fix must_use on `Option::is_none`

This fixes the `#[must_use = ...]` on `Option::is_none` to have a working suggestion.

Fix rebase conflicts

Don't require cmake on Windows when LLVM isn't being built

Previously, setting `download-ci-llvm = true` when cmake wasn't
installed would give the following error:

```
failed to execute command: "cmake" "--help"
error: The system cannot find the file specified. (os error 2)
```

Address review comments

- Simplify boolean expression
- Give an example of invalid syntax
- Remove explanation of why code block is text

Rename INVALID_RUST_CODEBLOCK{,S}

Add back missing help for ignore blocks

This also gives a better error message when a span is missing.

New rustdoc lint to respect -Dwarnings correctly

This adds a new lint to `rustc` that is used in rustdoc when a code
block is empty or cannot be parsed as valid Rust code.

Previously this was unconditionally a warning. As such some
documentation comments were (unknowingly) abusing this to pass despite
the `-Dwarnings` used when compiling `rustc`, this should not be the
case anymore.

Auto merge of #85402 - RalfJung:miri, r=RalfJung

update Miri

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

Adjust linker_is_gnu branches for cases that don't work on windows.

update Miri

Implement jackh726's suggestions

Auto merge of #85414 - RalfJung:rollup-ueqcik4, r=RalfJung

Rollup of 8 pull requests

Successful merges:

 - #85087 (`eval_fn_call`: check the ABI of `body.source`)
 - #85302 (Expand WASI abbreviation in docs)
 - #85355 (More tests for issue-85255)
 - #85367 (Fix invalid input:disabled CSS selector)
 - #85374 (mark internal inplace_iteration traits as hidden)
 - #85408 (remove size field from Allocation)
 - #85409 (Simplify `cfg(any(unix, target_os="redox"))` in example to just `cfg(unix)`)
 - #85412 (remove some functions that were only used by Miri)

Failed merges:

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

Remove remnants of BorrowOfPackedField

runtest: correctly guard against LLVM version 13

Rollup merge of #85412 - RalfJung:c_str, r=oli-obk

remove some functions that were only used by Miri

and Miri does not need them any more with https://github.com/rust-lang/miri/pull/1805.

r? ``@oli-obk``

Rollup merge of #85409 - CDirkx:cfg_redox, r=nagisa

Simplify `cfg(any(unix, target_os="redox"))` in example to just `cfg(unix)`

Update example for `OsString` that handled `redox` seperately from `unix`: Redox has been completely integrated under `target_family="unix"`, so `cfg(unix)` implies `target_os="redox"`

https://github.com/rust-lang/rust/blob/35dbef235048f9a2939dc20effe083ca483c37ff/compiler/rustc_target/src/spec/redox_base.rs#L26

Rollup merge of #85408 - RalfJung:alloc-size, r=oli-obk

remove size field from Allocation

This is a part of https://github.com/rust-lang/rust/pull/85376 that can be easily split out.
r? ``@oli-obk``

Rollup merge of #85374 - the8472:hide-internal-traits, r=SimonSapin

mark internal inplace_iteration traits as hidden

resolves #85373

r? ``@SimonSapin``

Rollup merge of #85367 - GuillaumeGomez:fix-css-rule, r=jsha

Fix invalid input:disabled CSS selector

For some reason, we used "search-focus" instead of "search-input"...

r? ``@jsha``

Rollup merge of #85355 - hi-rustin:rustin-patch-issue-85255, r=varkor

More tests for issue-85255

Add more test for `pub(crate)`.

r? ``@varkor``

Rollup merge of #85302 - r00ster91:patch-7, r=joshtriplett

Expand WASI abbreviation in docs

I was pretty sure this was related to something for WebAssembly but wasn't 100% sure so I checked but even on these top-level docs I couldn't find the abbreviation expanded. I'm normally used to Rust docs being detailed and explanatory and writing abbreviations like this out in full at least once so I thought it was worth the change. Feel free to close this if it's too much.

Rollup merge of #85087 - hyd-dev:lots-of-abis, r=RalfJung

`eval_fn_call`: check the ABI of `body.source`

And stop checking `instance_ty.fn_sig(*self.tcx).abi()`, if the function is not an intrinsic.
Addresses https://github.com/rust-lang/miri/pull/1776#discussion_r615381169.
No idea how to test this without Miri...

Auto merge of #85352 - Xanewok:update-rls, r=Xanewok

Update RLS

Contains https://github.com/rust-lang/rls/pull/1736. With #82208 merged, this should now close https://github.com/rust-lang/rust/issues/85225. Tested locally with `./x.py test src/tools/rls` and seems to be working as expected.

I noticed the rustfmt merge didn't trigger toolstate upgrade (because we pruned most but not all of the related machinery?), so I'd rather get this rubber-stamped by someone more knowledgeable with infra/the merged changes in case I missed something and need to include something else here to unbreak the RLS toolstate.

r? `@Mark-Simulacrum`

Avoid zero-length write_str in fmt::write

Optimize default ToString impl

This avoids a zero-length write_str call, which boils down to a zero-length
memmove and ultimately costs quite a few instructions on some workloads.

This is approximately a 0.33% instruction count win on diesel-check.

Remove legacy for trait object mangling test and replace crate hash

Add a comment for `check_abi()`

remove some functions that were only used by Miri

Auto merge of #84571 - jedel1043:issue-49804-impl, r=petrochenkov

Parse unnamed fields of struct and union type

Added the `unnamed_fields` feature gate.

This is a prototype of [RFC 2102](https://github.com/rust-lang/rust/issues/49804), so any suggestions are greatly appreciated.

r? `@petrochenkov`

Two minor changes for readability and efficiency

Simplify `cfg(any(unix, target_os="redox"))` to just `cfg(unix)`

mir-opt bless for Size field being removed from Allocation

remove size field from Allocation

backport 1.52.1 release notes

Auto merge of #85353 - jonas-schievink:async-blocks-in-ctfe, r=oli-obk

Allow `async {}` expressions in const contexts

Gated behind a new `const_async_blocks` feature.

rustdoc: restore header sizes

Allow formatting `Anonymous{Struct, Union}` declarations

Suppress spurious errors inside `async fn`

Fixes #73741

Auto merge of #85178 - cjgillot:local-crate, r=oli-obk

Remove CrateNum parameter for queries that only work on local crate

The pervasive `CrateNum` parameter is a remnant of the multi-crate rustc idea.

Using `()` as query key in those cases avoids having to worry about the validity of the query key.

Auto merge of #84993 - eddyb:cg-ssa-on-demand-blocks, r=nagisa

rustc_codegen_ssa: only create backend `BasicBlock`s as-needed.

Instead of creating one backend (e.g. LLVM) block per MIR block ahead of time, and then deleting the ones that weren't visited, this PR moves to creating the blocks as they're needed (either reached via the RPO visit, or used as the target of a branch from a different block).

As deleting a block was the only `unsafe` builder method (generally we only *create* backend objects, not *remove* them), that's gone now and codegen is overall a bit safer.

The only change in output is the order of LLVM blocks (which AFAIK has no semantic meaning, other than the first block being the entry block). This happens because the blocks are now created due to control-flow edges, rather than MIR block order.

I'm making this a standalone PR because I keep getting wild perf results when I change *anything* in codegen, but if you want to read more about my plans in this area, see https://github.com/rust-lang/rust/pull/84771#issuecomment-830636256 (and https://github.com/rust-lang/rust/pull/84771#issue-628295651 - but that may be a bit outdated).

(You may notice some of the APIs in this PR, like `append_block`, don't help with the future plans - but I didn't want to include the necessary refactors that pass a build around everywhere, in this PR, so it's a small compromise)

r? `@nagisa` `@bjorn3`

rustc_codegen_ssa: append blocks to functions w/o creating a builder.

rustc_codegen_ssa: only create backend `BasicBlock`s as-needed.

Auto merge of #85312 - ehuss:macro_use-unused-attr, r=petrochenkov

Fix unused attributes on macro_rules.

The `unused_attributes` lint wasn't firing on attributes of `macro_rules` definitions. The consequence is that many attributes are silently ignored on `macro_rules`. The reason is that `unused_attributes` is a late-lint pass, and only has access to the HIR, which does not have macro_rules definitions.

My solution here is to change `non_exported_macro_attrs` to be `macro_attrs` (a list of all attributes used for `macro_rules`, instead of just those for `macro_export`), and then to check this list in the `unused_attributes` lint. There are a number of alternate approaches, but this seemed the most reliable and least invasive. I am open to completely different approaches, though.

One concern is that I don't fully understand the implications of extending `non_exported_macro_attrs` to include non-exported macros. That list was originally added in #62042 to handle stability attributes, so I suspect it was just an optimization since that was all that was needed. It was later extended to be included in SVH in #83901. #80641 also added a use to check for `invalid` attributes, which seems a little odd to me (it didn't validate non-exported macros, and seems highly specific).

Overall, there doesn't seem to be a clear story of when `unused_attributes` should be used versus an error like E0518. I considered alternatively using an "allow list" of built-in attributes that can be used on macro_rules (allow, warn, deny, forbid, cfg, cfg_attr, macro_export, deprecated, doc), but I feel like that could be a pain to maintain.

Some built-in attributes already present hard-errors when used with macro_rules. These are each hard-coded in various places:
- `derive`
- `test` and `bench`
- `proc_macro` and `proc_macro_derive`
- `inline`
- `global_allocator`

The primary motivation is that I sometimes see people use `#[macro_use]` in front of `macro_rules`, which indicates there is some confusion out there (evident that there was even a case of it in rustc).