-
Notifications
You must be signed in to change notification settings - Fork 13.7k
Closed
Labels
A-intra-doc-linksArea: Intra-doc links, the ability to link to items in docs by nameArea: Intra-doc links, the ability to link to items in docs by nameC-bugCategory: This is a bug.Category: This is a bug.E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.P-mediumMedium priorityMedium priorityT-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.Relevant to the rustdoc team, which will review and decide on the PR/issue.
Description
This code works fine:
pub enum Foo {
/// [Self::Bar::abc]
Bar {
abc: i32,
xyz: i32,
},
}
But this code's intra-doc link doesn't resolve:
pub enum Foo {
Bar {
abc: i32,
/// [Self::Bar::abc]
xyz: i32,
},
}
warning: unresolved link to `Bar::Bar::abc`
--> foo.rs:4:14
|
4 | /// [Self::Bar::abc]
| ^^^^^^^^^^^^^^ no item named `Bar` in scope
|
= note: `#[warn(broken_intra_doc_links)]` on by default
Doesn't Self
usually only refer to types, not enum variants? (Barring the proposed RFC to make enum variant types.)
Metadata
Metadata
Assignees
Labels
A-intra-doc-linksArea: Intra-doc links, the ability to link to items in docs by nameArea: Intra-doc links, the ability to link to items in docs by nameC-bugCategory: This is a bug.Category: This is a bug.E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.P-mediumMedium priorityMedium priorityT-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.Relevant to the rustdoc team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
camelid commentedon Feb 17, 2021
Yeah, this definitely seems like a bug. I have to use
Foo::Self::abc
(orFoo::Bar::abc
).Self::abc
doesn't work because it looks for the enum variant as if it's a free-floating type:jyn514 commentedon Feb 17, 2021
@camelid do you know if this ever worked? I might have broken it in #76467.
jyn514 commentedon Feb 17, 2021
But also I agree that this seems like a misfeature, I'd be ok with getting rid of it. To do that, just delete
variant_field
and all references to it.hellow554 commentedon Feb 17, 2021
hey @jyn514
you are correct. Bisecting this leads to b7ebc6b
So the fix is to get rid of the
variant_field
method completly (and of course delete any code that calls it)? Or am I misreading it?jyn514 commentedon Feb 17, 2021
Yes, I think so. No one noticed this breaking for 12 weeks and
Self
always refers to the type in normal code, not the variant: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9655fe188d99f728e90e65a08164e825lucas-deangelis commentedon Feb 21, 2021
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.
camelid commentedon Feb 21, 2021
Yes, this should be a good first issue. You can claim it with
@rustbot claim
. Post here or on Zulip in#t-compiler/help
if you have any questions :)lucas-deangelis commentedon Feb 21, 2021
Thanks! I'll have a look at it. @rustbot claim
lucas-deangelis commentedon Feb 22, 2021
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
issue-82209.rs
file insrc/test/rustdoc/
. Here's the file:I'm not sure about the
#![deny(broken_intra_doc_links)]
, but I couldn't get the test to fail without something like that, and it's more precise than the#![deny(warnings)]
that I used at first. Does this look okay to you?13 remaining items
jyn514 commentedon Feb 24, 2021
@lucas-deangelis all the "preprocessing" of the link (turning
Self
into a path) happens before resolve_link is called, inrust/src/librustdoc/passes/collect_intra_doc_links.rs
Line 858 in a8486b6
camelid commentedon Feb 25, 2021
Aha, I bet this is the issue:
rust/src/librustdoc/passes/collect_intra_doc_links.rs
Lines 837 to 845 in a8486b6
For fields in enum variants, the parent is the variant, not the enum.
lucas-deangelis commentedon Feb 25, 2021
Thanks for the clarification.
So if I understand correctly, if we encounter a variant, we should return the parent of the parent of
item.def_id
?jyn514 commentedon Feb 25, 2021
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.
struct S { x: usize }
).lucas-deangelis commentedon Feb 25, 2021
Thanks, I'll try that.
lucas-deangelis commentedon Feb 26, 2021
I think I'm making some progress. I added a new condition to check if we encounter a field that's in a variant before the
matches!
line 837:I'll have to find a way to handle the call to
.unwrap()
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?
jyn514 commentedon Feb 26, 2021
Hmm, is this still with the calls to
variant_field
removed? Try adding those back.lucas-deangelis commentedon Feb 26, 2021
It was, and now with it back it works. Thanks. Should I make a pull request now?
jyn514 commentedon Feb 26, 2021
That would be great, thanks!
Self
in enum #82563Rollup merge of rust-lang#82563 - lucas-deangelis:issue-82209-fix, r=…
Rollup merge of rust-lang#82563 - lucas-deangelis:issue-82209-fix, r=…
lucas-deangelis commentedon Feb 28, 2021
And it's merged! Thank you @jyn514 and @camelid for the help on the issue, @hellow554 for some of the initial work and @Dylan-DPC for the rollups.
jyn514 commentedon Feb 28, 2021
You're very welcome! Thank you for tackling the fix :)