This greatly simplifies how hard it is to set a custom bug report url; previously tools had to copy
the entire hook implementation.

- Switch clippy to the new hook

  This also adds a `extra_info` callback so clippy can include its own version number, which differs
  from rustc's.

- Call `install_ice_hook` in rustfmt

When we're adding a method to a type DIE, we only want a DW_AT_declaration
there, because LLVM LTO can't unify type definitions when a child DIE is a
full subprogram definition. Now the subprogram definition gets added at the
CU level with a specification link back to the abstract declaration.

…ts with custom items

Previously, incorrect spans were reported if inline assembly contained
CRLF (Windows) line endings.

Fixes rust-lang#110885

… r=lcnr

Use fulfillment to check `Drop` impl compatibility

Use an `ObligationCtxt` to ensure that a `Drop` impl does not have stricter requirements than the ADT that it's implemented for, rather than using a `SimpleEqRelation` to (more or less) syntactically equate predicates on an ADT with predicates on an impl.

r? types

### Some background

The old code reads:

```rust
// An earlier version of this code attempted to do this checking
// via the traits::fulfill machinery. However, it ran into trouble
// since the fulfill machinery merely turns outlives-predicates
// 'a:'b and T:'b into region inference constraints. It is simpler
// just to look for all the predicates directly.
```

I'm not sure what this means, but perhaps in the 8 years since that this comment was written (cc rust-lang#23638) it's gotten easier to process region constraints after doing fulfillment? I don't know how this logic differs from anything we do in the `compare_impl_item` module. Ironically, later on it says:

```rust
// However, it may be more efficient in the future to batch
// the analysis together via the fulfill (see comment above regarding
// the usage of the fulfill machinery), rather than the
// repeated `.iter().any(..)` calls.
```

Also:
* Removes `SimpleEqRelation` which was far too syntactical in its relation.
* Fixes rust-lang#110557

Add Terminator conversion from MIR to SMIR, part #1

This adds internal MIR TerminatorKind to SMIR Terminator conversion.

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

…aber

Fix spans in LLVM-generated inline asm errors

Previously, incorrect spans were reported if inline assembly contained CRLF (Windows) line endings.

Fixes rust-lang#110885

Make the BUG_REPORT_URL configurable by tools

This greatly simplifies how hard it is to set a custom bug report url; previously tools had to copy
the entire hook implementation.

I haven't changed clippy in case they want to make the change upstream instead of the subtree, but
I'm happy to do so here if the maintainers want - cc ````@rust-lang/clippy````

Fixes rust-lang#109486.

…michaelwoerister

debuginfo: split method declaration and definition

When we're adding a method to a type DIE, we only want a DW_AT_declaration
there, because LLVM LTO can't unify type definitions when a child DIE is a
full subprogram definition. Now the subprogram definition gets added at the
CU level with a specification link back to the abstract declaration.

Both GCC and Clang write debuginfo this way for C++ class methods.

Fixes rust-lang#109730.
Fixes rust-lang#109934.

…mpiler-errors

add hint for =< as <=

Adds a compiler hint for when `=<` is typed instead of `<=`

Example hint:
```rust
fn foo() {
    if 1 =< 3 {
        println!("Hello, World!");
    }
}
```
```
error: expected type, found `3`
 --> main.rs:2:13
  |
2 |     if 1 =< 3 {
  |          -- ^ expected type
  |          |
  |          help: did you mean: `<=`
```

This PR only emits the suggestion if there is no space between the `=` and `<`.  This hopefully narrows the scope of when this error is emitted, however this still allows this error to be emitted in cases such as this:
```
error: expected expression, found `;`
 --> main.rs:2:18
  |
2 |     if 1 =< [i32;; 3]>::hello() {
  |          --      ^ expected expression
  |          |
  |          help: did you mean: `<=`
```

Which could be a good reason not to merge since I haven't been able to think of any other ways of narrowing the scope of this diagnostic.

closes rust-lang#111128

… r=cjgillot

More robust debug assertions for `Instance::resolve` on built-in traits with non-standard trait items

In rust-lang#111264, a user added a new item to the `Future` trait, but the code in [`resolve_associated_item`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ty_utils/instance/fn.resolve_associated_item.html) implicitly assumes that the `Future` trait is defined with only one method (`Future::poll`) and treats the generator body as the implementation of that method.

This PR adds some debug assertions to make sure that that new methods defined on `Future`/`Generator`/etc. don't accidentally resolve to the wrong item when they are added, and adds a helpful comment guiding a compiler dev (or curious `#![no_core]` user) to what must be done to support adding new associated items to these built-in implementations.

I am open to discuss whether a test should be added, but I chose against it because I opted to make these `bug!()`s instead of, e.g., diagnostics or fatal errors. Arguably it doesn't need a test because it's not a bug that can be triggered by an end user, and internal-facing misuses of core kind of touch on rust-lang/compiler-team#620 -- however, I think the assertions I added in this PR are still a very useful way to make sure this bug doesn't waste debugging resources down the line.

Fixes rust-lang#111264