Repository navigation
rustc_has_incoherent_impl breaks rustdoc in subtle ways #161699
Description
Code
I tried this code:
/// [`std::io::Error::last_os_error`]
pub struct Strukt;I expected to see this happen: cargo doc finishes without warnings.
Instead, this happened:
warning: unresolved link to `std::io::Error::last_os_error`
--> dep/src/lib.rs:3:7
|
3 | /// [`std::io::Error::last_os_error`].
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the struct `Error` has no field or associated item named `last_os_error`
|
= note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default
warning: `dep` (lib doc) generated 1 warning
Version it worked on
It most recently worked on: 1.97
Version with regression
rustc --version --verbose:
rustc 1.98.0 (88d9e12ae 2026-08-18)
binary: rustc
commit-hash: 88d9e12ae178fab0fb5cc050a94da85685d449ea
commit-date: 2026-08-18
host: x86_64-unknown-linux-gnu
release: 1.98.0
LLVM version: 22.1.8
Metadata
Metadata
Assignees
Labels
Category: This is a bug.Issue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}Status: A bisection has been found for this issueRelevant to the rustdoc team, which will review and decide on the PR/issue.This issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triagingUntriaged performance or correctness regression.
Activity
maxdexh commentedon Aug 24, 2026
searched nightlies: from nightly-2026-06-01 to nightly-2026-08-24
regressed nightly: nightly-2026-06-30
searched commit range: df6ee90...0966944
regressed commit: 7fb284d
bisected with cargo-bisect-rustc v0.6.11
Host triple: x86_64-unknown-linux-gnu
Reproduce with:
Welp, I could have guessed that it came from that
@rustbot label S-has-bisection T-rustdoc T-libs
clarfonthey commentedon Aug 25, 2026
This honestly feels like a rustdoc bug, not a libs bug, but I may be wrong there. If you check the generated rustdoc for the
stdcrate, this method is present, so…maxdexh commentedon Aug 25, 2026
My LSP is also fine with it, even when linking to
core::io::Error::last_os_errorinno_std. If I had to guess, this is an issue with the fact thatlast_os_erroris an incoherent inherent impl that lives instd. Probably the lint is only searching incore, since that's whereErroris definedclarfonthey commentedon Aug 25, 2026
Hmm, are there any other incoherent impls that might be triggered by this, that aren't primitives?
maxdexh commentedon Aug 25, 2026
core::io::Error::otheris also affected and is a better example since it has less stuff on it.Also affected:
@rustbot label -T-libs
maxdexh commentedon Aug 25, 2026
Yeah it seems to just be any inherent method on a non-primitive type (marked with
rustc_allow_incoherent_impl) that's not in the same crate as the type.Conveniently, we have
alloc::bstr::ByteString::to_string(inherent method, not onToString) that's also marked withrustc_allow_incoherent_implfor some reason despite living inalloc(like 20 lines below the declaration ofByteStringeven). It does not give a warning. (ByteStr::to_stringdoes give a warning, as you'd expect)[-]Doc links to `std::io::Error::last_os_error` fail to resolve in 1.98[/-][+]`rustc_has_incoherent_impl` breaks `rustdoc` in subtle ways[/+][-]`rustc_has_incoherent_impl` breaks `rustdoc` in subtle ways[/-][+]`rustc_has_incoherent_impl` breaks rustdoc in subtle ways[/+]clarfonthey commentedon Aug 27, 2026
@rustbot claim
Going to try and see if I can fix this one.