Skip to content
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

Delay ambiguous intra-doc link resolution after Cache has been populated #131691

Merged
merged 4 commits into from
Oct 16, 2024

Conversation

GuillaumeGomez
Copy link
Member

Fixes #130233.

I was getting nowhere with #130278. I took a wrong turn at some point and ended making way too many changes so instead I started again back from 0 and this time it worked out as expected.

r? @notriddle

@GuillaumeGomez GuillaumeGomez changed the title Delay ambiguous intra-doc link resolution after Cache has been populated Delay ambiguous intra-doc link resolution after Cache has been populated Oct 14, 2024
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Oct 14, 2024
@rustbot
Copy link
Collaborator

rustbot commented Oct 14, 2024

Some changes occurred in src/librustdoc/clean/types.rs

cc @camelid

Comment on lines 291 to 296
/// These links are ambiguous. We need for the cache to have its paths filled. Unfortunately,
/// if we run the `LinkCollector` pass after `Cache::populate`, a lot of items that we need
/// to go through will be removed, making a lot of intra-doc links to not be inferred.
///
/// So instead, we store the ambiguous links and we wait for cache paths to be filled before
/// inferring them (if possible).
Copy link
Contributor

@notriddle notriddle Oct 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is how I would write it.

According to rustc_resolve, these links are ambiguous.

However, we cannot link to an item that has been stripped from the documentation. If all but one of the "possibilities" are stripped, then there is no real ambiguity. To determine if an ambiguity is real, we delay resolving them until after Cache::populate, then filter every item that doesn't have a cached path.

We could get correct results by simply delaying everything. This would have fewer happy codepaths, but we want to distinguish different kinds of error conditions, and this is easy to do by resolving links as soon as possible.

I actually might still try refactoring this to use a single happy codepath, if I can do it in a way that doesn't regress the diagnostics and actually reduces the total amount of code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be done as a follow-up but if you have ideas for improvements, it's very welcome!

}

pub(crate) struct AmbiguousLinks {
disambiguator: Option<Disambiguator>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How could this possibly be Some? Doesn't using a disambiguator imply that the link can't be ambiguous?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One word: reexports. :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still confused. Is there a test case for this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So with:

//! [struct@X]

mod a {
    pub struct X;
}

mod b {
    pub struct X;
}

pub use a::*;
pub use b::*;

We get:

warning: public documentation for `bar` links to private item `X`
 --> bar.rs:1:6
  |
1 | //! [struct@X]
  |      ^^^^^^^^ this item is private
  |
  = note: this link will resolve properly if you pass `--document-private-items`
  = note: `#[warn(rustdoc::private_intra_doc_links)]` on by default

I think it's a bug but for now, let's simply remove this disambiguator as it doesn't seem to work.

self.cx.tcx,
BROKEN_INTRA_DOC_LINKS,
format!(
"all items matching `{path_str}` are either private or doc(hidden)"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"all items matching `{path_str}` are either private or doc(hidden)"
"all items matching `{path_str}` are private or doc(hidden)"

@@ -2061,6 +2251,8 @@ fn ambiguity_error(
// There is no way for users to disambiguate at this point, so better return the first
// candidate and not show a warning.
return false;
} else if !emit_error {
return true;
Copy link
Contributor

@notriddle notriddle Oct 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this first chunk be separated out into a has_ambiguity_error function that ambiguity_error simply calls?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah actually not really: we need the kinds variable that is computed at the beginning...

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 14, 2024
@GuillaumeGomez
Copy link
Member Author

Updated!

@rust-log-analyzer

This comment has been minimized.

@GuillaumeGomez
Copy link
Member Author

Updated!

@GuillaumeGomez
Copy link
Member Author

@bors ready

@GuillaumeGomez GuillaumeGomez added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 15, 2024
@notriddle
Copy link
Contributor

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Oct 15, 2024

📌 Commit 10f2395 has been approved by notriddle

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 15, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Oct 16, 2024
…er-out-2, r=notriddle

Delay ambiguous intra-doc link resolution after `Cache` has been populated

Fixes rust-lang#130233.

I was getting nowhere with rust-lang#130278. I took a wrong turn at some point and ended making way too many changes so instead I started again back from 0 and this time it worked out as expected.

r? `@notriddle`
Urgau added a commit to Urgau/rust that referenced this pull request Oct 16, 2024
…er-out-2, r=notriddle

Delay ambiguous intra-doc link resolution after `Cache` has been populated

Fixes rust-lang#130233.

I was getting nowhere with rust-lang#130278. I took a wrong turn at some point and ended making way too many changes so instead I started again back from 0 and this time it worked out as expected.

r? ``@notriddle``
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 16, 2024
Rollup of 10 pull requests

Successful merges:

 - rust-lang#129181 (Pass end position of span through inline ASM cookie)
 - rust-lang#130989 (Don't check unsize goal in MIR validation when opaques remain)
 - rust-lang#131657 (Rustfmt `for<'a> async` correctly)
 - rust-lang#131691 (Delay ambiguous intra-doc link resolution after `Cache` has been populated)
 - rust-lang#131730 (Refactor some `core::fmt` macros)
 - rust-lang#131751 (Rename `can_coerce` to `may_coerce`, and then structurally resolve correctly in the probe)
 - rust-lang#131753 (Unify `secondary_span` and `swap_secondary_and_primary` args in `note_type_err`)
 - rust-lang#131776 (Emscripten: Xfail backtrace ui tests)
 - rust-lang#131777 (Fix trivially_copy_pass_by_ref in stable_mir)
 - rust-lang#131778 (Fix needless_lifetimes in stable_mir)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 16, 2024
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#130989 (Don't check unsize goal in MIR validation when opaques remain)
 - rust-lang#131657 (Rustfmt `for<'a> async` correctly)
 - rust-lang#131691 (Delay ambiguous intra-doc link resolution after `Cache` has been populated)
 - rust-lang#131730 (Refactor some `core::fmt` macros)
 - rust-lang#131751 (Rename `can_coerce` to `may_coerce`, and then structurally resolve correctly in the probe)
 - rust-lang#131753 (Unify `secondary_span` and `swap_secondary_and_primary` args in `note_type_err`)
 - rust-lang#131776 (Emscripten: Xfail backtrace ui tests)
 - rust-lang#131777 (Fix trivially_copy_pass_by_ref in stable_mir)
 - rust-lang#131778 (Fix needless_lifetimes in stable_mir)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 87c31fe into rust-lang:master Oct 16, 2024
6 checks passed
@rustbot rustbot added this to the 1.84.0 milestone Oct 16, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Oct 16, 2024
Rollup merge of rust-lang#131691 - GuillaumeGomez:intra-doc-link-filter-out-2, r=notriddle

Delay ambiguous intra-doc link resolution after `Cache` has been populated

Fixes rust-lang#130233.

I was getting nowhere with rust-lang#130278. I took a wrong turn at some point and ended making way too many changes so instead I started again back from 0 and this time it worked out as expected.

r? ```@notriddle```
@GuillaumeGomez GuillaumeGomez deleted the intra-doc-link-filter-out-2 branch October 20, 2024 02:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Intra-doc link should rule out hidden items when resolving ambiguous link
5 participants