Improve and fix diagnostics of exhaustiveness checking
Primarily, this fixes https://github.com/rust-lang/rust/issues/56379. This also fixes incorrect interactions between or-patterns and slice patterns that I discovered while working on #56379. Those two examples show the incorrect diagnostics:
```rust
match &[][..] {
[true] => {}
[true // detected as unreachable but that's not true
| false, ..] => {}
_ => {}
}
match (true, None) {
(true, Some(_)) => {}
(false, Some(true)) => {}
(true | false, None | Some(true // should be detected as unreachable
| false)) => {}
}
```
I did not measure any perf impact. However, I suspect that [`616ba9f`](616ba9f9f7) should have a negative impact on large or-patterns. I'll see what the perf run says; I have optimization ideas up my sleeve if needed.
EDIT: I initially had a noticeable perf impact that I thought unavoidable. I then proceeded to avoid it x)
r? `@varkor`
`@rustbot` label +A-exhaustiveness-checking
UI Tests: Separate suspicious_else_formatting tests
Was briefly looking into https://github.com/rust-lang/rust-clippy/issues/3864 when I saw that the tests could benefit from being in their own file.
---
changelog: none
Stabilize all stable methods of `Ipv4Addr`, `Ipv6Addr` and `IpAddr` as const
This PR stabilizes all currently stable methods of `Ipv4Addr`, `Ipv6Addr` and `IpAddr` as const.
Tracking issue: #76205
`Ipv4Addr` (`const_ipv4`):
- `octets`
- `is_loopback`
- `is_private`
- `is_link_local`
- `is_multicast`
- `is_broadcast`
- `is_docmentation`
- `to_ipv6_compatible`
- `to_ipv6_mapped`
`Ipv6Addr` (`const_ipv6`):
- `segments`
- `is_unspecified`
- `is_loopback`
- `is_multicast`
- `to_ipv4`
`IpAddr` (`const_ip`):
- `is_unspecified`
- `is_loopback`
- `is_multicast`
## Motivation
The ip methods seem like prime candidates to be made const: their behavior is defined by an external spec, and based solely on the byte contents of an address. These methods have been made unstable const in the beginning of September, after the necessary const integer arithmetic was stabilized.
There is currently a PR open (#78802) to change the internal representation of `IpAddr{4,6}` from `libc` types to a byte array. This does not have any impact on the constness of the methods.
## Implementation
Most of the stabilizations are straightforward, with the exception of `Ipv6Addr::segments`, which uses the unstable feature `const_fn_transmute`. The code could be rewritten to equivalent stable code, but this leads to worse code generation (#75085).
This is why `segments` gets marked with `#[rustc_allow_const_fn_unstable(const_fn_transmute)]`, like the already const-stable `Ipv6Addr::new`, the justification being that a const-stable alternative implementation exists https://github.com/rust-lang/rust/pull/76206#issuecomment-685044184.
## Future posibilities
This PR const-stabilizes all currently stable ip methods, however there are also a number of unstable methods under the `ip` feature (#27709). These methods are already unstable const. There is a PR open (#76098) to stabilize those methods, which could include const-stabilization. However, stabilizing those methods as const is dependent on `Ipv4Addr::octets` and `Ipv6Addr::segments` (covered by this PR).
Fix blessing of new reference files
Adding of new reference files wasn't handled correctly. It was trying to
read a file that didn't exist yet.
Instead of unwrapping, we now treat a missing reference file as empty
(`Vec::new`). This makes the following conditional work. We then also
have to re-read the reference file after it was being copied. This
second read is technically the same as in the old shell script, but
wasn't really obvious there. The shell script did a `-s` test which
reads the file as well.
changelog: internal: Fix `cargo dev bless` when new reference files are added
Adding of new reference files wasn't handled correctly. It was trying to
read a file that didn't exist yet.
Instead of unwrapping, we now treat a missing reference file as empty
(`Vec::new`). This makes the following conditional work. We then also
have to re-read the reference file after it was being copied. This
second read is technically the same as in the old shell script, but
wasn't really obvious. The shell script did a `-s` test which reads the
file.
Add the "async" and "promise" doc aliases to `core::future::Future`
Adds the "async" and "promise" doc aliases to `core::future::Future`. This enables people who search for "async" or "promise" to find `Future`, which is Rust's core primitive for async programming. Thanks!
Stabilize or_insert_with_key
Stabilizes the `or_insert_with_key` feature from https://github.com/rust-lang/rust/issues/71024. This allows inserting key-derived values when a `HashMap`/`BTreeMap` entry is vacant.
The difference between this and `.or_insert_with(|| ... )` is that this provides a reference to the key to the closure after it is moved with `.entry(key_being_moved)`, avoiding the need to copy or clone the key.
passes: prohibit invalid attrs on generic params
Fixes#78957.
This PR modifies the `check_attr` pass so that attribute placement on generic parameters is checked for validity.
r? `@lcnr`
Continue String to Symbol conversion in rustdoc (2)
Follow-up of #80119.
This is the last one (and I actually expected more conversions but seems like it was the last one remaining...).
r? `@jyn514`
Renamed the good first issue label in CONTRIBUTING.md
Follow up from #6468
Grep found some more references to the old `good first issue`.
[CONTRIBUTING.md rendered](https://github.com/xFrednet/rust-clippy/blob/0000-rename-good-first-issue-in-docs/CONTRIBUTING.md)
<details>
<summary>grep output</summary>
```
$ grep -Ri "good first issue" rust-clippy/
rust-clippy/.git/COMMIT_EDITMSG:Renamed the good first issue label in CONTRIBUTING.md
rust-clippy/.git/logs/HEAD:896d82f7ff64644656bda7a4ed8bbd55ca3b7619 1f58c2bb8a xFrednet <xFrednet@gmail.com> 1608326295 +0000 commit: Renamed the good first issue label for rustbot
rust-clippy/.git/logs/HEAD:9be704584f05e5a6c3ba2708590f98c1f261d19a ced54f2867 xFrednet <xFrednet@gmail.com> 1608329602 +0000 commit: Renamed the good first issue label in CONTRIBUTING.md
rust-clippy/.git/logs/refs/heads/0000-rename-good-first-issue-in-docs:896d82f7ff64644656bda7a4ed8bbd55ca3b7619 1f58c2bb8a xFrednet <xFrednet@gmail.com> 1608326295 +0000 commit: Renamed the good first issue label for rustbot
rust-clippy/.git/logs/refs/heads/0000-rename-good-first-issue-in-docs:9be704584f05e5a6c3ba2708590f98c1f261d19a ced54f2867 xFrednet <xFrednet@gmail.com> 1608329602 +0000 commit: Renamed the good first issue label in CONTRIBUTING.md
rust-clippy/CONTRIBUTING.md:Some issues are easier than others. The [`good first issue`] label can be used to find the easy issues.
rust-clippy/CONTRIBUTING.md:[`E-medium`] issues are generally pretty easy too, though it's recommended you work on an [`good first issue`]
rust-clippy/CONTRIBUTING.md:[`good first issue`]: https://github.com/rust-lang/rust-clippy/labels/good%20first%20issue
```
</details>
---
changelog: None
r? `@flip1995`
This is elegant but a bit of a perf gamble. That said, or-patterns
rarely have many branches and it's easy to optimize or revert if we ever
need to. In the meantime simpler code is worth it.
Edit formatting in Rust Prelude docs
Use consistent punctuation and capitalization in the list of things re-exported in the prelude.
Also adds a (possibly missing) word.
