UnreachableProp: Preserve unreachable branches for multiple targets
Before, UnreachablePropagation removed all unreachable branches. This was a pessimization, as it removed information about reachability that was used later in the optimization pipeline.
For example, this code
```rust
pub enum Two { A, B }
pub fn identity(x: Two) -> Two {
match x {
Two::A => Two::A,
Two::B => Two::B,
}
}
```
basically has `switchInt() -> [0: 0, 1: 1, otherwise: unreachable]` for the match. This allows it to be transformed into a simple `x`. If we remove the unreachable branch, the transformation becomes illegal.
This was the problem keeping `UnreachablePropagation` from being enabled, so we can enable it now.
Something similar already happened in #77800, but it did not show a perf improvement there. Let's try it again anyways!
Fixes#68105, although that issue has been fixed for a long time (see #77680).
Add guarantee that Vec::default() does not alloc
Currently `Vec::new()` is guaranteed to not allocate until elements are pushed onto the `Vec`, but such a guarantee is missing for `Vec`'s implementation of `Default::default`.
This adds such a guarantee for `Vec::default()` to the API reference.
See also [this discussion on URLO](https://users.rust-lang.org/t/guarantee-that-vec-default-does-not-allocate/79903).
Use pointer `is_aligned*` methods
This PR replaces some manual alignment checks with calls to `pointer::{is_aligned, is_aligned_to}` and removes a useless pointer cast.
r? `@scottmcm`
_split off from #100746_
Convert diagnostics in parser/expr to SessionDiagnostic
This migrates all the easy cases in `rustc_parse::parser::expr` to `SessionDiagnostic`s, I've left things such as `multipart_suggestion`s out for now in the hopes of a derive API being developed soon.
Guarantee `try_reserve` preserves the contents on error
Update doc comments to make the guarantee explicit. However, some
implementations does not have the statement though.
* `HashMap`, `HashSet`: require guarantees on hashbrown side.
* `PathBuf`: simply redirecting to `OsString`.
Fixes#99606.
Rework Ipv6Addr::is_global to check for global reachability rather than global scope - rebase
Rebasing of pull request #86634 off of master to try and get the feature "ip" stabilized.
I also found a test failure in the rebase that is_global was considering the benchmark space to be globally reachable.
This is related to my other rebasing pull request #99947
Make some const prop mir-opt tests `unit-test`s
Most of these have no or only tiny diffs beyond line numbers being changed (would it make sense to not have line numbers in mir-opt tests?). Some things changed a bit, but I think it should all be fine, not sure though.
Expand potential inner `Or` pattern for THIR
Code assumed there wouldn't be a deeper `Or` pattern inside expanded `PatStack` this fixes it by looking for the `Or` pattern inside expanded `PatStack`.
A more ideal solution would be recursively doing this but I haven't found a good way to do that.
_fixes #97898_
Show absolute line numbers if span is outside relative span
In the MIR pretty printing, it can sometimes happen that the span of the statement is outside the span of the body (for example through inlining). In this case, don't display a relative span but an absolute span. This will make the mir-opt-tests a little more prone to diffs again, but the impact should be small.
Fixes#99854
r? `@oli-obk`
In the MIR pretty printing, it can sometimes happen that the span of the
statement is outside the span of the body (for example through
inlining). In this case, don't display a relative span but an absolute
span. This will make the mir-opt-tests a little more prone to diffs
again, but the impact should be small.
get rid of `RefCell` in `TransitiveRelation`
This is one of the jobs in `Pending refactorings` in #48685. The parallel-compiler's work has been suspended for quite some time, but I think I can pick it up gradually. I think this PR should be a start.
Regarding the refactoring of `TransitiveRelation`, `@nikomatsakis` has proposed [two(three?) schemes](https://github.com/rust-lang/rust/pull/48587#issuecomment-369336651). In order to satisfy both compilation efficiency and robustness, I think adding the `freeze` method may be the best solution, although it requires relatively more code changes.
Currently `Vec::new()` is guaranteed to not allocate until elements are
pushed onto the `Vec`, but such a guarantee is missing for `Vec`'s
implementation of `Default::default`. This adds such a guarantee for
`Vec::default()` to the API reference.
