Skip to content

Deprioritize doc(hidden) re-exports in diagnostic paths#153630

Open
arferreira wants to merge 1 commit intorust-lang:mainfrom
arferreira:fix-doc-hidden-reexport-diagnostic-path
Open

Deprioritize doc(hidden) re-exports in diagnostic paths#153630
arferreira wants to merge 1 commit intorust-lang:mainfrom
arferreira:fix-doc-hidden-reexport-diagnostic-path

Conversation

@arferreira
Copy link
Contributor

@arferreira arferreira commented Mar 9, 2026

Fixes #153477.

This is the other half of #99698, which fixed the case where the parent module is #[doc(hidden)] but left the case where the re-export itself is #[doc(hidden)] as a FIXME (with a tracking test in dont-suggest-doc-hidden-variant-for-enum/hidden-child.rs).

The problem: when a crate does #[doc(hidden)] pub use core::error::Error, diagnostics pick up the hidden re-export path instead of the canonical one. For example, snafu::Error instead of std::error::Error.

Two changes:

In visible_parent_map, the add_child closure now checks whether the re-export itself is #[doc(hidden)] via reexport_chain and sends it to fallback_map, same treatment as doc-hidden parents and underscore re-exports.

should_encode_attrs now returns true for DefKind::Use. Without this, #[doc(hidden)] on use items was never written to crate metadata, so is_doc_hidden always returned false cross-crate. This was the actual root cause, the check in visible_parent_map alone isn't enough if the attribute isn't in the metadata.

The existing FIXME test now serves as the regression test. The .stderr goes from suggesting hidden_child::__private::Some(1i32) to just Some(1i32).

cc @eggyal

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 9, 2026
@rustbot
Copy link
Collaborator

rustbot commented Mar 9, 2026

r? @jackh726

rustbot has assigned @jackh726.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 69 candidates
  • Random selection from 15 candidates

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Name resolution is confusing when crates re-exports std items

4 participants