to be able to set a marker/id on the socket for network filtering
 (iptables/ipfw here) purpose.

I refactored the code:
- Removed handling of methods, as it felt entirely unnecessary
- Removed clippy utils (obviously...)
- Used some shiny compiler features
  (let-else is very handy for lints 👀)
- I also renamed the lint to `for_loop_over_fallibles` (note: no `s`).
  I'm not sure what's the naming convention here, so maybe I'm wrong.

if the iterator is used after the loop, we need to use `.by_ref()`

The loop could contain `break;` that won't work with an `if let`

Those are basically the same but the first one seems to fit better

The macro warn_ was named like that because it the
keyword warn is a built-in attribute and at the time
this macro was created the word 'warning' was also
taken.

However it is no longer the case and we can rename
warn_ to warning.

…rminal

The UNIX and WASI implementations use `isatty`. The Windows
implementation uses the same logic the `atty` crate uses, including the
hack needed to detect msys terminals.

Implement this trait for `File` and for `Stdin`/`Stdout`/`Stderr` and
their locked counterparts on all platforms. On UNIX and WASI, implement
it for `BorrowedFd`/`OwnedFd`. On Windows, implement it for
`BorrowedHandle`/`OwnedHandle`.

Based on rust-lang#91121

Co-authored-by: Matt Wilkinson <[email protected]>

If a process has no console, it'll have NULL in place of a console
handle, so return early with `false` in that case without making any OS
calls.

Rather than referencing a slice's pointer and then creating a new slice
with a longer length, offset from the base structure pointer instead.
This makes some choices of Rust semantics happier.

… r=joshtriplett

Support parsing IP addresses from a byte string

Fixes rust-lang#94821

The goal is to be able to parse addresses from a byte string without requiring to do any utf8 validation. Since internally the parser already works on byte strings, this should be possible and I personally already needed this in the past too.

~~I used the proposed approach from the issue by implementing `TryFrom<&'a [u8]>` for all 6 address types (3 ip address types and 3 socket address types). I believe implementing stable traits for stable types is insta-stable so this will probably need an FCP?~~

Switched to an unstable inherent method approach called `parse_ascii` as requested.

cc `@jyn514`

socket `set_mark` addition.

to be able to set a marker/id on the socket for network filtering
 (iptables/ipfw here) purpose.

… r=thomcc

Add `IsTerminal` trait to determine if a descriptor or handle is a terminal

The UNIX implementation uses `isatty`. The Windows implementation uses
the same logic the `atty` crate uses, including the hack needed to
detect msys terminals.

Implement this trait for `Stdin`/`Stdout`/`Stderr`/`File` on all
platforms. On Unix, implement it for `BorrowedFd`/`OwnedFd`. On Windows,
implement it for `BorrowedHandle`/`OwnedHandle`.

Based on rust-lang#91121

Co-authored-by: Matt Wilkinson <[email protected]>

Replace `Body::basic_blocks()` with field access

Since the refactoring in rust-lang#98930, it is possible to borrow the basic blocks
independently from other parts of MIR by accessing the `basic_blocks` field
directly.

Replace unnecessary `Body::basic_blocks()` method with a direct field access,
which has an additional benefit of borrowing the basic blocks only.

Uplift `clippy::for_loops_over_fallibles` lint into rustc

This PR, as the title suggests, uplifts [`clippy::for_loops_over_fallibles`] lint into rustc. This lint warns for code like this:
```rust
for _ in Some(1) {}
for _ in Ok::<_, ()>(1) {}
```
i.e. directly iterating over `Option` and `Result` using `for` loop.

There are a number of suggestions that this PR adds (on top of what clippy suggested):
1. If the argument (? is there a better name for that expression) of a `for` loop is a `.next()` call, then we can suggest removing it (or rather replacing with `.by_ref()` to allow iterator being used later)
   ```rust
    for _ in iter.next() {}
    // turns into
    for _ in iter.by_ref() {}
    ```
2. (otherwise) We can suggest using `while let`, this is useful for non-iterator, iterator-like things like [async] channels
   ```rust
   for _ in rx.recv() {}
   // turns into
   while let Some(_) = rx.recv() {}
   ```
3. If the argument type is `Result<impl IntoIterator, _>` and the body has a `Result<_, _>` type, we can suggest using `?`
   ```rust
   for _ in f() {}
   // turns into
   for _ in f()? {}
   ```
4. To preserve the original behavior and clear intent, we can suggest using `if let`
   ```rust
   for _ in f() {}
   // turns into
   if let Some(_) = f() {}
   ```
(P.S. `Some` and `Ok` are interchangeable depending on the type)

I still feel that the lint wording/look is somewhat off, so I'll be happy to hear suggestions (on how to improve suggestions :D)!

Resolves rust-lang#99272

[`clippy::for_loops_over_fallibles`]: https://rust-lang.github.io/rust-clippy/master/index.html#for_loops_over_fallibles

…tch-err, r=oli-obk

Improve const mismatch `FulfillmentError`

Fixes rust-lang#100414

…piler-errors

Migrate part of rustc_infer to session diagnostic

…name-attr-warning, r=davidtwco

translations: rename warn_ to warning

## Description

This MR renames the the macro `warn_` to `warning`.

To give a little bit of context, as [explained](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20diag.20translation/near/295074146) by ``@davidtwco`` in the Zulip channel, `warn_`  was named like that because the keyword `warn` is a built-in attribute and at the time this macro was created the word `warning` was also
taken.

However, it is no longer the case and we can rename `warn_` to `warning`.