Open SergioBenitez opened 7 years ago
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.
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 972ccba41ecb8cca2c7a34837788a6124e0bc9a2)
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 https://github.com/rust-lang/cargo/issues/12266#issuecomment-1591253839.
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 https://github.com/rust-lang/cargo/pull/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
I have a project that's structured as follows:
In lib.rs, I have:
The
git status
is:This
git status
arose from deletingmodule.rs
and then renaming a different file tomodule.rs
.When I make changes to
lib.rs
and runcargo doc
, updated documentation is generated. However, if I make changes tomodule.rs
and runcargo doc
, documentation is unchanged. The correct thing, of course, is forcargo doc
to have picked up the changes. I presume something is going on with howcargo
is treating files that git believes are "deleted", and so perhaps this issue is more widespread than justcargo doc
.