`cargo doc` doesn't pick up changes to "deleted" modules

[SergioBenitez]

I have a project that's structured as follows:

src/
    lib.rs
    module.rs

In lib.rs, I have:

mod module

The git status is:

Changes not staged for commit:

	deleted:    src/module.rs

Untracked files:

	src/module.rs

This git status arose from deleting module.rs and then renaming a different file to module.rs.

When I make changes to lib.rs and run cargo doc, updated documentation is generated. However, if I make changes to module.rs and run cargo doc, documentation is unchanged. The correct thing, of course, is for cargo doc to have picked up the changes. I presume something is going on with how cargo is treating files that git believes are "deleted", and so perhaps this issue is more widespread than just cargo doc.

[alexcrichton]

Hm this is probably related to how we use git information by default to check dirtiness (e.g. we don't look at ignored files). It's probably located around here, but I'm not certain of that.

[dwijnand]

After some initial difficulty I found that this is reproducible by using git rm --cached src/module.rs.

Also it's still reproducible with the current head of cargo (version 1.29.0, sha 972ccba)

[weihanglo]

Triage: This somehow has the same root cause as #12266. We don't have a reliable way to detect change in rustdoc other than walking the filesystem. See #12266 (comment).

In addition, when a package is under the control of git, Cargo will include both staged and untracked files, but exclude deleted files in the index (via #9645). The special case here is src/module.rs is both “untracked” and “deleted”. I feel like we may not want to pursue such an edge case. I could be wrong, though.

@rustbot label +S-blocked-external +Command-doc +A-rebuild-detection +A-git

[epage]

FYI rustdoc dep info support is being worked on in rust-lang/rust#137684

[weihanglo]

This should be fixed by #15359, and is now tracked by #15370. Let us know if it doesn't. Thank you!