Add filter with following segment while lookup typo for path
From the discussion: https://github.com/rust-lang/rust/pull/112917#discussion_r1239150173
Seems we can not get the assoc items for `Struct`, `Enum` in the resolving phase.
A obvious filter is avoid suggesting the same name with the following segment path.
Use `following_seg` can extend the function `smart_resolve_partial_mod_path_errors` for more scenarios, such as `std::sync_error::atomic::AtomicBool` in test case.
r? `@estebank`
Always name the return place.
MIR opts more and more consider `_0` as just another local, so there is no point in keeping the special case in debug-info logic.
Don't call `query_normalize` when reporting similar impls
Firstly, It's sketchy to be using `query_normalize` at all during HIR typeck -- it's asking for an ICE 😅. Secondly, we're normalizing an impl trait ref that potentially has parameter types in `ty::ParamEnv::empty()`, which is kinda sketchy as well.
The only UI test change from removing this normalization is that we don't evaluate anonymous constants in impls, which end up giving us really ugly suggestions:
```
error[E0277]: the trait bound `[X; 35]: Default` is not satisfied
--> /home/gh-compiler-errors/test.rs:4:5
|
4 | <[X; 35] as Default>::default();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Default` is not implemented for `[X; 35]`
|
= help: the following other types implement trait `Default`:
&[T]
&mut [T]
[T; 32]
[T; core::::array::{impl#30}::{constant#0}]
[T; core::::array::{impl#31}::{constant#0}]
[T; core::::array::{impl#32}::{constant#0}]
[T; core::::array::{impl#33}::{constant#0}]
[T; core::::array::{impl#34}::{constant#0}]
and 27 others
```
So just fold the impls with a `BottomUpFolder` that calls `ty::Const::eval`. This doesn't work totally correctly with generic-const-exprs, but it's fine for stable code, and this is error reporting after all.
Rollup of 7 pull requests
Successful merges:
- #112931 (Enable zlib in LLVM on aarch64-apple-darwin)
- #113158 (tests: unset `RUSTC_LOG_COLOR` in a test)
- #113173 (CI: include workflow name in concurrency group)
- #113335 (Reveal opaques in new solver)
- #113390 (CGU formation tweaks)
- #113399 (Structurally normalize again for byte string lit pat checking)
- #113412 (Add basic types to SMIR)
r? `@ghost`
`@rustbot` modify labels: rollup
Structurally normalize again for byte string lit pat checking
We need to structurally normalize the pointee of a match scrutinee when trying to match byte string patterns -- we used[^1] to call `structurally_resolve_type`, which errors for type vars[^2], but lcnr added `try_structurally_resolve_type`[^3] in the mean time, which is the right thing to use here since it's totally opportunistic.
Fixes rust-lang/trait-system-refactor-initiative#38
[^1]: #112428
[^2]: #112993
[^3]: #113086
Reveal opaques in new solver
We were testing against the wrong reveal mode 😨
Also a couple of misc commits that I don't want to really put in separate prs
r? ``@lcnr``
Rename `adjustment::PointerCast` and variants using it to `PointerCoercion`
It makes it sounds like the `ExprKind` and `Rvalue` are supposed to represent all pointer related casts, when in reality their just used to share a little enum variants. Make it clear there these are only coercions and that people who see this and think "why are so many pointer related casts not in these variants" aren't insane.
This enum was added in #59987. I'm not sure whether the variant sharing is actually worth it, but this at least makes it less confusing.
r? oli-obk
Rollup of 8 pull requests
Successful merges:
- #113413 (Add needs-triage to all new issues)
- #113426 (Don't ICE in `resolve_bound_vars` when associated return-type bounds are in bad positions)
- #113427 (Remove `variances_of` on RPITIT GATs, remove its one use-case)
- #113441 (miri: check that assignments do not self-overlap)
- #113453 (Remove unused from_method from rustc_on_unimplemented)
- #113456 (Avoid calling report_forbidden_specialization for RPITITs)
- #113466 (Update cargo)
- #113467 (Fix comment of `fn_can_unwind`)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove unused from_method from rustc_on_unimplemented
Fixes#113439
`on_unimplemented_note` was calling `item_name` for RPITITs and that produced ICEs. I've added a regression test for that but also have removed `from_method` symbol entirely because it wasn't even used and by doing that the `item_name` call was also removed.
r? ``@compiler-errors``
Remove `variances_of` on RPITIT GATs, remove its one use-case
It doesn't make sense to implement variances on a GAT anyways, since we don't relate GATs with variance:
85bf07972a/compiler/rustc_middle/src/ty/relate.rs (L569-L579)
r? ``@spastorino``
It makes it sound like the `ExprKind` and `Rvalue` are supposed to represent all pointer related
casts, when in reality their just used to share a some enum variants. Make it clear there these
are only coercion to make it clear why only some pointer related "casts" are in the enum.
Split `SelectionContext::select` into fns that take a binder and don't
*most* usages of `SelectionContext::select` don't need to use a binder, but wrap them in a dummy because of the signature. Let's split this out into `SelectionContext::{select,poly_select}` and limit the usages of the latter.
Right now, we only have 3 places where we're calling `poly_select` -- fulfillment, internally within the old solver, and the auto-trait finder.
r? `@lcnr`
Do not assert >1 RPITITs on collect_return_position_impl_trait_in_trait_tys
Fixes#113403
Assert on collect_return_position_impl_trait_in_trait_tys is not correct when we call it from type_of(GAT). The included test is an example of a situation that collector collects 0 types.
r? `@compiler-errors`
Prefer object candidates in new selection
`dyn Any` shouldn't be using [this implementation](https://doc.rust-lang.org/std/any/trait.Any.html#impl-Any-for-T) during codegen.
Prefer object candidates over other candidates, except for other object candidates.
Don't call `type_of` on TAIT in defining scope in new solver
It's *never* productive to call `consider_auto_trait_candidate` on a TAIT in the defining scope, since it will always lead to a query cycle since we call `type_of` on the TAIT. So let's just don't.
I've reserved this behavior just to `SolverMode::Normal` just to avoid any future problems, since this is *technically* incomplete since we're discarding a candidate that could *theoretically* apply. But given such candidate assembly *always* leads to a query cycle, I think it's relatively low risk, and I could be convinced otherwise and make this apply to both solver mode. I assume it's far less likely to be encountered in coherence, though.
This is much more likely to encounter in the new solver, though it can also be encountered in the old solver too, so I'm happy to discuss whether this new behavior we even want in the first place...
I encountered this in a couple of failing UI tests:
* `tests/ui/type-alias-impl-trait/issue-62000-associate-impl-trait-lifetimes.rs`
* `tests/ui/type-alias-impl-trait/issue-93411.rs`
r? `@lcnr`
