Skip to content

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

Closed as duplicate of#12266
@Vrixyz

Description

@Vrixyz

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]

Metadata

Metadata

Assignees

Labels

C-bugCategory: bugS-triageStatus: This issue is waiting on initial triage.Z-rustdoc-depinfoNightly: rustdoc-depinfo integration

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions