-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nll should respect lifetime annotations from multi-segment paths #54574
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: