`codegen_switchint_terminator` already uses `br` instead of `switch`
when there is one normal target plus the `otherwise` target. But there's
another common case with two normal targets and an `otherwise` target
that points to an empty unreachable BB. This comes up a lot when
switching on the tags of enums that use niches.
The pattern looks like this:
```
bb1: ; preds = %bb6
%3 = load i8, ptr %_2, align 1, !range !9, !noundef !4
%4 = sub i8 %3, 2
%5 = icmp eq i8 %4, 0
%_6 = select i1 %5, i64 0, i64 1
switch i64 %_6, label %bb3 [
i64 0, label %bb4
i64 1, label %bb2
]
bb3: ; preds = %bb1
unreachable
```
This commit adds code to convert the `switch` to a `br`:
```
bb1: ; preds = %bb6
%3 = load i8, ptr %_2, align 1, !range !9, !noundef !4
%4 = sub i8 %3, 2
%5 = icmp eq i8 %4, 0
%_6 = select i1 %5, i64 0, i64 1
%6 = icmp eq i64 %_6, 0
br i1 %6, label %bb4, label %bb2
bb3: ; No predecessors!
unreachable
```
This has a surprisingly large effect on compile times, with reductions
of 5% on debug builds of some crates. The reduction is all due to LLVM
taking less time. Maybe LLVM is just much better at handling `br` than
`switch`.
The resulting code is still suboptimal.
- The `icmp`, `select`, `icmp` sequence is silly, converting an `i1` to an `i64`
and back to an `i1`. But with the current code structure it's hard to avoid,
and LLVM will easily clean it up, in opt builds at least.
- `bb3` is usually now truly dead code (though not always, so it can't
be removed universally).
Don't use usub.with.overflow intrinsic
The canonical form of a usub.with.overflow check in LLVM are separate sub + icmp instructions, rather than a usub.with.overflow intrinsic. Using usub.with.overflow will generally result in worse optimization potential.
The backend will attempt to form usub.with.overflow when it comes to actual instruction selection. This is not fully reliable, but I believe this is a better tradeoff than using the intrinsic in IR.
Fixes#103285.
rustdoc: Simplify modifications of effective visibility table
It is now obvious that rustdoc only calls `set_access_level` with foreign def ids and `AccessLevel::Public`.
The second commit makes one more step and separates effective visibilities coming from rustc from similar data collected by rustdoc for extern `DefId`s.
The original table is no longer modified and now only contains local def ids as populated by rustc.
cc https://github.com/rust-lang/rust/pull/102026 `@Bryanskiy`
Point only to the identifiers in the typo suggestions of shadowed names instead of the entire struct
Fixes#103358.
As discussed in the issue, the `Span` of the candidate `Ident` for a typo replacement is stored alongside its `Symbol` in `TypoSuggestion`. Then, the span of the identifier is what the "you might have meant to refer to" note is pointed at, rather than the entire struct definition.
Comments in #103111 and the issue both suggest that it is desirable to:
1. include names defined in the same crate as the typo,
2. ignore names defined elsewhere such as in `std`, _and_
3. include names introduced indirectly via `use`.
Since a name from another crate but introduced via `use` has non-local `def_id`, to achieve this, a suggestion is displayed if either the `def_id` of the suggested name is local, or the `span` of the suggested name is in the same file as the typo itself.
Some UI tests have also been modified to reflect this change.
r? `@cjgillot`
Allow `impl Fn() -> impl Trait` in return position
_This was originally proposed as part of #93082 which was [closed](https://github.com/rust-lang/rust/pull/93082#issuecomment-1027225715) due to allowing `impl Fn() -> impl Trait` in argument position._
This allows writing the following function signatures:
```rust
fn f0() -> impl Fn() -> impl Trait;
fn f3() -> &'static dyn Fn() -> impl Trait;
```
These signatures were already allowed for common traits and associated types, there is no reason why `Fn*` traits should be special in this regard.
`impl Trait` in both `f0` and `f3` means "new existential type", just like with `-> impl Iterator<Item = impl Trait>` and such.
Arrow in `impl Fn() ->` is right-associative and binds from right to left, it's tested by [this test](a819fecb8d/src/test/ui/impl-trait/impl_fn_associativity.rs).
There even is a test that `f0` compiles:
2f004d2d40/src/test/ui/impl-trait/nested_impl_trait.rs (L25-L28)
But it was changed in [PR 48084 (lines)](https://github.com/rust-lang/rust/pull/48084/files#diff-ccecca938872d65ffe8cd1c3ef1956e309fac83bcda547d8b16b89257e53a437R37) to test the opposite, probably unintentionally given [PR 48084 (lines)](https://github.com/rust-lang/rust/pull/48084/files#diff-5a02f1ed43debed1fd24f7aad72490064f795b9420f15d847bac822aa4621a1cR476-R477).
r? `@nikomatsakis`
----
This limitation is especially annoying with async code, since it forces one to write this:
```rust
trait AsyncFn3<A, B, C>: Fn(A, B, C) -> <Self as AsyncFn3<A, B, C>>::Future {
type Future: Future<Output = Self::Out>;
type Out;
}
impl<A, B, C, Fut, F> AsyncFn3<A, B, C> for F
where
F: Fn(A, B, C) -> Fut,
Fut: Future,
{
type Future = Fut;
type Out = Fut::Output;
}
fn async_closure() -> impl AsyncFn3<i32, i32, i32, Out = u32> {
|a, b, c| async move { (a + b + c) as u32 }
}
```
Instead of:
```rust
fn async_closure() -> impl Fn(i32, i32, i32) -> impl Future<Output = u32> {
|a, b, c| async move { (a + b + c) as u32 }
}
```
Accept `TyCtxt` instead of `TyCtxtAt` in `Ty::is_*` functions
Functions in answer:
- `Ty::is_freeze`
- `Ty::is_sized`
- `Ty::is_unpin`
- `Ty::is_copy_modulo_regions`
This allows to remove a lot of useless `.at(DUMMY_SP)`, making the code a bit nicer :3
r? `@compiler-errors`
Rename some `OwnerId` fields.
`@spastorino` noticed some silly expressions like `item_id.def_id.def_id`.
This commit renames several `def_id: OwnerId` fields as `owner_id`, so those expressions become `item_id.owner_id.def_id`.
`item_id.owner_id.local_def_id` would be even clearer, but the use of `def_id` for values of type `LocalDefId` is *very* widespread, so I left that alone.
r? `@compiler-errors`
filter candidates in pick probe for diagnostics
Fixes#103411, though also fine with closing this PR if my opinion (https://github.com/rust-lang/rust/issues/103411#issuecomment-1287900069) is shared that this doesn't need to be fixed.
```
~/rust3$ time rustc +nightly ~/test.rs 2>/dev/null
real 0m4.853s
user 0m4.837s
sys 0m0.016s
~/rust3$ time rustc +rust3 ~/test.rs 2>/dev/null
real 0m0.193s
user 0m0.169s
sys 0m0.024s
```
Also fixes#103427.
spastorino noticed some silly expressions like `item_id.def_id.def_id`.
This commit renames several `def_id: OwnerId` fields as `owner_id`, so
those expressions become `item_id.owner_id.def_id`.
`item_id.owner_id.local_def_id` would be even clearer, but the use of
`def_id` for values of type `LocalDefId` is *very* widespread, so I left
that alone.
Note scope of TAIT more accurately
This maybe explains why the person was confused in #101897, since we say "same module" but really should've said "same impl".
r? ``@oli-obk``
Introduce UnordMap, UnordSet, and UnordBag (MCP 533)
This is the start of implementing [MCP 533](https://github.com/rust-lang/compiler-team/issues/533).
I followed `@eddyb's` suggestion of naming the collection types `Unord(Map/Set/Bag)` which is a bit easier to type than `Unordered(Map/Set/Bag)`
r? `@eddyb`
privacy: Rename "accessibility levels" to "effective visibilities"
And a couple of other naming and comment tweaks.
Related to https://github.com/rust-lang/rust/issues/48054
For `enum Level` I initially used naming `enum EffectiveVisibilityLevel`, but it was too long and inconvenient because it's used pretty often.
So I shortened it to just `Level`, if it needs to be used from some context where this name would be ambiguous, then it can be imported with renaming like `use rustc_middle::privacy::Level as EffVisLevel` or something.
Fix line numbers for MIR inlined code
`should_collapse_debuginfo` detects if the specified span is part of a
macro expansion however it does this by checking if the span is anything
other than a normal (non-expanded) kind, then the span sequence is
walked backwards to the root span.
This doesn't work when the MIR inliner inlines code as it creates spans
with expansion information set to `ExprKind::Inlined` and results in the
line number being attributed to the inline callsite rather than the
normal line number of the inlined code.
Fixes#103068
Change reported_violations to use IndexSet
It is being used to iterate and to insert, without a lot of lookups
so hopefully it won't be a perf hit
Change MiniGraph.nodes to use IndexSet
It is being used to iterate and to insert, without performing lookups
so hopefully it won't be a perf hit
Change RegionConstraintData.givens to a FxIndexSet
This might result in a perf hit. Remove was being used in `givens`,
and `FxIndexSet` doesn't allow calling remove without losing the
fixed iteration order. So it was necessary to change remove to
`shift_remove`, but this method is slower.
Change OpaqueTypesVisitor to use stable sets and maps
This could also be a perf hit.
Make TraitObject visitor use a stable set
Emit a nicer error on `impl Self {`
currently it emits a "cycle detected error" but this PR makes it emit a more user friendly error specifically saying that `Self` is disallowed in that position. this is a pretty hacky fix so i dont expect this to be merged (I basically only made this PR because i wanted to see if CI passes)
r? ``@compiler-errors``
Remap early bound lifetimes in return-position `impl Trait` in traits too
Fixes part of #103457
r? ``@cjgillot,`` though feel free to reassign, just thought you'd have sufficient context to review.
Don't carry MIR location in `ConstraintCategory::CallArgument`
It turns out that `ConstraintCategory::CallArgument` cannot just carry a MIR location in it, since we may bubble them up to totally different MIR bodies.
So instead, revert the commit a6b5f95fb0, and instead just erase regions from the original `Option<Ty<'tcx>>` that it carried, so that it doesn't ICE with the changes in #103220.
Best reviewed in parts -- the first is just a revert, and the second is where the meaningful changes happen.
Fixes#103624
diagnostics: do not suggest static candidates as traits to import
If it's a static candidate, then it's already implemented. Do not suggest it a second time for implementing.
Partial fix for #102354
