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

Incremental cargo doc doesn't support [lib] path to parent #15203

Closed
Vrixyz opened this issue Feb 19, 2025 · 3 comments · May be fixed by #15205
Closed

Incremental cargo doc doesn't support [lib] path to parent #15203

Vrixyz opened this issue Feb 19, 2025 · 3 comments · May be fixed by #15205
Assignees
Labels
C-bug Category: bug S-triage Status: This issue is waiting on initial triage.

Comments

@Vrixyz
Copy link

Vrixyz commented Feb 19, 2025

Problem

When running cargo doc incrementally on a project with a parent [lib] path:

[lib]
name = "crate1"
path = "../src/lib.rs"

edits to files are not detected, ending up in a previous doc version.

Steps

See https://github.com/Vrixyz/cargo_parent_path.

  1. Run cargo doc --open.

Output is:

 Documenting crate1 v0.1.0 (/path/to/here/crate1)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.17s
     Opening /path/to/here/target/doc/crate1/index.html
  1. Change some documentation in src/lib.rs (and save).

Run again cargo doc --open.

Output is:

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.00s
     Opening /path/to/here/target/doc/crate1/index.html

But should be the same as before.

  1. Notice the opened documentation still shows the previous content, where we would have expected it to show the updated content.

Possible Solution(s)

No response

Notes

My current workaround is to run cargo clean (with -p package in bigger projects to avoid too expensive recompilation.

This bug had been present for a long time (I don´t believe that's a regression).

I detected this while working on https://github.com/dimforge/parry and similar crates.

Version

cargo 1.83.0 (5ffbef321 2024-10-29)
release: 1.83.0
commit-hash: 5ffbef3211a8c378857905775a15c5b32a174d3b
commit-date: 2024-10-29
host: x86_64-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Pop!_OS 22.4.0 (jammy) [64-bit]
@Vrixyz Vrixyz added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Feb 19, 2025
@Jondolf
Copy link

Jondolf commented Feb 19, 2025

I have the same problem in Avian, which uses a similar project structure.

@krtab
Copy link
Contributor

krtab commented Feb 19, 2025

I've started looking at this a bit and may have a hint, I'll try to dig in more and release the assignment if I don't find anything.
@rustbot claim

@ehuss
Copy link
Contributor

ehuss commented Feb 19, 2025

Thanks for the report! I'm going to close as a duplicate of #12266. Unfortunately, cargo does not have the ability to detect the set of files involved with rustdoc. We would need rustdoc to gain the ability to emit a dep-info file to know which files are involved. Currently cargo can only check files in the package's directory and assume any one of them could affect the documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants