Handle TyAlias in projected_ty #15288
Conversation
rustbot
added
the
S-waiting-on-review
crates/hir-ty/src/mir.rs
Outdated
| @@ -151,6 +151,7 @@ impl<V, T> ProjectionElem<V, T> { | |||
| TyKind::Adt(_, subst) => { | |||
| db.field_types(f.parent)[f.local_id].clone().substitute(Interner, subst) | |||
| } | |||
| TyKind::Alias(al) => al.clone().intern(Interner), | |||
There was a problem hiding this comment.
| TyKind::Alias(al) => al.clone().intern(Interner), | |
| TyKind::Alias(inner) => al.clone().intern(Interner), |
crates/hir-ty/src/mir.rs
Outdated
| @@ -167,6 +168,7 @@ impl<V, T> ProjectionElem<V, T> { | |||
| TyKind::Error.intern(Interner) | |||
| }), | |||
| TyKind::Closure(id, subst) => closure_field(*id, subst, *f), | |||
| TyKind::Alias(al) => al.clone().intern(Interner), | |||
There was a problem hiding this comment.
| TyKind::Alias(al) => al.clone().intern(Interner), | |
| TyKind::Alias(inner) => al.clone().intern(Interner), |
|
I'm not completely sure this is correct, but it can't be worse than crashing, right? :-). Can you also find a place to add a test? |
This was my exact line of thought 😄 . I don't seem to understand why the enclosing function is invoked and I do not see a testing infrastructure that isolates mir from the rest. I would be happy to do it if you could maybe guide me ? |
|
@bors r+ |
|
☀️ Test successful - checks-actions |
|
I don't think this PR makes any sense. The But what is the problem here? In this code (which hits the trait Tr {
type Ty;
}
struct A;
impl Tr for A {
type Ty = (u32, i64);
}
struct B<T: Tr> {
f: <T as Tr>::Ty,
}
fn x(b: B<A>) {
let f = b.f.0; // here
}
|
|
Oh, sorry, let's revert this and tell people to use a binary build, if possible. EDIT: I can't find the revert button, will to it tomorrow. |
Revert "Handle TyAlias in projected_ty" Reverts #15288
First of all I still have no idea how MIR works but #15143 has been an issue that constantly made RA crash so I have been looking for a way to make RA stop panicking. I have zero claims that what I want to merge has any sense or is correct 😄 but there isn't any more panicking. Even if it is wrong may this be at least a step towards resolving this issue.
As is customary this PR fixes #15143