…d in import

When encountering a name in an import that could have come from a crate that wasn't imported, use a structured suggestion to suggest `extern crate foo;` pointing at the right place in the crate.

When encountering `_` in an import, do not suggest `extern crate _;`.

```
error[E0432]: unresolved import `spam`
  --> $DIR/import-from-missing-star-3.rs:2:9
   |
LL |     use spam::*;
   |         ^^^^ maybe a missing crate `spam`?
   |
help: consider importing the `spam` crate
   |
LL + extern crate spam;
   |
```

remove an unused boolean and then merge two big matches into one

…3, r=petrochenkov"

This reverts commit 91b18a0, reversing
changes made to 9aedec9.

…nce, r=pnkfelix"

This reverts commit a70dc29, reversing
changes made to ceae371.

…nce-2, r=pnkfelix"

This reverts commit 31fe962, reversing
changes made to f203078.

…nce, r=pnkfelix"

This reverts commit 2724aea, reversing
changes made to d929a42.

…9, r=petrochenkov"

This reverts commit 977c5fd, reversing
changes made to 24c94f0.

…nce, r=pnkfelix"

This reverts commit 13314df, reversing
changes made to 6e534c7.

…hanges

Since LLVM <https://reviews.llvm.org/D99439> (4c7f820, "Update
@llvm.powi to handle different int sizes for the exponent"), the size of
the integer can be specified for the `powi` intrinsic. Make use of this
so it is more obvious that integer size is consistent across all float
types.

This feature is available since LLVM 13 (October 2021). Based on
bootstrap we currently support >= 17.0, so there should be no support
problems.

These already exist in the compiler. Expose them in core so we can add
their library functions.

This adds missing functions for math operations on the new float types.

Platform support is pretty spotty at this point, since even platforms
with generally good support can be missing math functions.
`std/build.rs` is updated to reflect this.

`min`, `max`, and similar functions require external math routines. Add
these under the same gates as `std` math functions (`reliable_f16_math`
and `reliable_f128_math`).

Clarify what makes some operations not safe, and correct comment in the
default branch ("not safe" -> "safe").

Due to a LLVM bug, `f128` math functions link successfully but LLVM
chooses the wrong symbols (`long double` symbols rather than those for
binary128).

Since this is a notable problem that may surprise a number of users, add
a note about it.

Link: llvm/llvm-project#44744

…etrochenkov

Structured suggestion for `extern crate foo` when `foo` isn't resolved in import

When encountering a name in an import that could have come from a crate that wasn't imported, use a structured suggestion to suggest `extern crate foo;` pointing at the right place in the crate.

When encountering `_` in an import, do not suggest `extern crate _;`.

```
error[E0432]: unresolved import `spam`
  --> $DIR/import-from-missing-star-3.rs:2:9
   |
LL |     use spam::*;
   |         ^^^^ maybe a missing crate `spam`?
   |
help: consider importing the `spam` crate
   |
LL + extern crate spam;
   |
```

Cleanup sys module to match house style

This moves a test file out of sys as it's just testing std types. Also cleans up some assorted bits including making the `use` statements match the house style.

…errors

Attribute checking simplifications

remove an unused boolean and then merge two big matches into one

I was reviewing some attributes and realized we don't really check this list against the list of builtin attributes, so we "may" totally be missing some attributes that we should be checking (like the `coroutine` attribute, which you can just apply to random stuff)

```rust
#![feature(coroutines)]
#[coroutine]
struct Foo;
```

just compiles for example. Unless we check that the fallthrough match arm is never reached for builtin attributes, we're just going to keep forgetting to add them here, too. I can do that without the changes in this PR, but it seemed like a nice cleanup

…hanges, r=pnkfelix

Revert recent changes to dead code analysis

This is a revert to recent changes to dead code analysis, namely:
* efdf219 Rollup merge of rust-lang#128104 - mu001999-contrib:fix/128053, r=petrochenkov
* a70dc29 Rollup merge of rust-lang#127017 - mu001999-contrib:dead/enhance, r=pnkfelix
* 31fe962 Rollup merge of rust-lang#127107 - mu001999-contrib:dead/enhance-2, r=pnkfelix
* 2724aea Rollup merge of rust-lang#126618 - mu001999-contrib:dead/enhance, r=pnkfelix
* 977c5fd Rollup merge of rust-lang#126315 - mu001999-contrib:fix/126289, r=petrochenkov
* 13314df Rollup merge of rust-lang#125572 - mu001999-contrib:dead/enhance, r=pnkfelix

There is an additional change stacked on top, which suppresses false-negatives that were masked by this work. I believe the functions that are touched in that code are legitimately unused functions and the types are not reachable since this `AnonPipe` type is not publically reachable -- please correct me if I'm wrong cc `@NobodyXu` who added these in #rust-lang#127153.

Some of these reverts (rust-lang#126315 and rust-lang#126618) are only included because it makes the revert apply cleanly, and I think these changes were only done to fix follow-ups from the other PRs?

I apologize for the size of the PR and the churn that it has on the codebase (and for reverting `@mu001999's` work here), but I'm putting this PR up because I am concerned that we're making ad-hoc changes to fix bugs that are fallout of these PRs, and I'd like to see these changes reimplemented in a way that's more separable from the existing dead code pass. I am happy to review any code to reapply these changes in a more separable way.

cc `@mu001999`
r? `@pnkfelix`

Fixes rust-lang#128272
Fixes rust-lang#126169

Add `f16` and `f128` math functions

This adds intrinsics and math functions for `f16` and `f128` floating point types. Support is quite limited and some things are broken so tests don't run on many platforms, but this provides a starting point.