-
Notifications
You must be signed in to change notification settings - Fork 13.4k
nll should respect lifetime annotations from multi-segment paths #54574
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
I did some investigation. I believe this problem is specific to inherent methods. There a bit of a challenge here: The substitutions on the impl are not directly given by the user. The user only gives the self-type. The rust/src/librustc_typeck/check/mod.rs Lines 5219 to 5236 in 1c5e9c6
which is pretty reasonable, but it does't work for us. The end result is that when we (later) invoke rust/src/librustc_typeck/check/mod.rs Line 5246 in 1c5e9c6
In fact, it's mildly invalid to call I don't think there's a super nice way to fix this. We might have to propagate the "user-given self type" all the way down to MIR, actually: in particular I don't think we can readily translate a "user-given self type" into a set of substitutions, due to annoying things like higher-ranked functions, for which equality is kind of complex. |
…, r=pnkfelix nll type annotations in multisegment path This turned out to be sort of tricky. The problem is that if you have a path like ``` <Foo<&'static u32>>::bar ``` and it comes from an impl like `impl<T> Foo<T>` then the self-type the user gave doesn't *directly* map to the substitutions that the impl wants. To handle this, then, we have to preserve not just the "user-given substs" we used to do, but also a "user-given self-ty", which we have to apply later. This PR makes those changes. It also removes the code from NLL relate-ops that handled canonical variables and moves to use normal inference variables instead. This simplifies a few things and gives us a bit more flexibility (for example, I predict we are going to have to start normalizing at some point, and it would be easy now). r? @matthewjasper -- you were just touching this code, do you feel comfortable reviewing this? Fixes #54574
This example should not compile:
But it does =)
The text was updated successfully, but these errors were encountered: