Change:
debug!("looking for the `Self` type"); let self_id = if item.is_fake() { None <ins> // Checking if the item is a field in an enum variant } else if (matches!(self.cx.tcx.def_kind(item.def_id), DefKind::Field) && matches!( self.cx.tcx.def_kind(self.cx.tcx.parent(item.def_id).unwrap()), DefKind::Variant )) { self.cx.tcx.parent(item.def_id).and_then(|item_id| self.cx.tcx.parent(item_id)) </ins> } else if matches!( self.cx.tcx.def_kind(item.def_id), DefKind::AssocConst

Discussion:
This code works fine: But this code's intra-doc link doesn't resolve: Doesn't usually only refer to types, not enum variants? (Barring the proposed RFC to make enum variant types.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yeah, this definitely seems like a bug. I have to use (or ). doesn't work because it looks for the enum variant as if it's a free-floating type:
do you know if this ever worked? I might have broken it in
But also I agree that this seems like a misfeature, I'd be ok with getting rid of it. To do that, just delete  and all references to it.
hey you are correct. Bisecting this leads to So the fix is to get rid of the method completly (and of course delete any code that calls it)? Or am I misreading it?
Yes, I think so. No one noticed this breaking for 12 weeks and always refers to the type in normal code, not the variant:
Hi, I don't know if anyone is already planning to work on it, but if not, would it be a good first issue? I'm still new to the language but I'd like to start contributing.
Yes, this should be a good first issue. You can claim it with . Post here or in if you have any questions :)
Thanks! I'll have a look at it. claim
I've taken a deeper look at the issue, and at the doc on contributions to Rust. Correct me if I'm wrong, but I think I'm supposed to start with making a failing test case. I made a file in . Here's the file: I'm not sure about the , but I couldn't get the test to fail without something like that, and it's more precise than the that I used at first. Does this look okay to you?
yes, that looks fine. I have a couple nits but they can wait until you make a PR to review, that test is enough to show what's going wrong.
Thanks! I'll start working on the fix now.
Assigning and removing as in the prioritization working group.

I've tried removing with , but even after removing it, the link is still resolved to . I think some of the logic is somewhere else.
Hmm, if that doesn't fix it the bug might be in the handling: You could try extending to also use the parent item for  or ?
This alone doesn't seem to fix it, however I've found that after adding on the match, modifying the following part modify the error message for the resolved link: The problem here seems to be that refers to the kind and not the enum.
Did you try matching both and ?
This is my naive attempt: I didn't add because it is already in the match, however, I think there's something here that I don't understand since you said "matching both", and here I'm matching either of them.
What you wrote is what I meant :) I meant match either or (as in ), but I didn't realize that was already in the match. Does your attempt work?
Nice, thanks for confirming. My attempt doesn't work. Right now I'm looking at , since it's the part where the link is created. I think that by trying to understand more , I can figure out from where exactly does the path comes from, and why in that case it gets resolved to instead of .
all the "preprocessing" of the link (turning into a path) happens before resolvelink is called, in
Aha, I bet this is the issue: For fields in enum variants, the parent is the variant, not the enum.
Thanks for the clarification. So if I understand correctly, if we encounter a variant, we should return the parent of the parent of ?
If you encounter a field that's in a variant. Basically make the check recursive (since fields may not be in a variant, e.g. ).
Thanks, I'll try that.
I think I'm making some progress. I a new condition to check if we encounter a field that's in a variant before the line 837: I'll have to find a way to handle the call to better once I get this working. Now the error I get is: Am I correct in assuming that this is now an error in the link resolution?
Hmm, is this still with the calls to removed? Try adding those back.
It was, and now with it back it works. Thanks. Should I make a pull request now?

That would be great, thanks!
And it's merged! Thank you and for the help on the issue, for some of the initial work and for the rollups.
You're very welcome! Thank you for tackling the fix :)