cargo run and cargo build don't seem to reflect recent changes

[anandijain]

Problem

i've been using vscode and

anand@anands-MacBook-Pro ~/.c/d/lorenz (main)> cargo -V
cargo 1.69.0 (6e9a83356 2023-04-12)
anand@anands-MacBook-Pro ~/.c/d/lorenz (main)> rustup -V
rustup 1.26.0 (5af9b9484 2023-04-05)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.69.0 (84c898d65 2023-04-16)`

and i have a simple lib. when i change some stuff then rerun cargo run it runs the old code.
i found this which seems similar to my issue
https://stackoverflow.com/questions/57087386/cargo-run-does-not-reflect-any-code-changes-in-main-rs

but in my case the only way that i reliably found to get cargo to register the changes is by deleting the target folder and rerunning.

happy to provide more information if needed! i am probably doing something silly (pretty new to rust) but im confused

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

No response

[Eh2406]

What is your folder structure? What is your Cargo.toml? What is your OS?

[anandijain]

anand@anands-MacBook-Pro ~/.c/d/lorenz (main)> tree
.
├── Cargo.lock
├── Cargo.toml
├── README.md
├── data
│   └── Euler_dt0.01.csv
├── src
│   ├── lib.rs
│   └── main.rs

anand@anands-MacBook-Pro ~/.c/d/lorenz (main)> cat Cargo.toml
[package]
name = "lorenz"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
pyo3 = { version = "0.18.3", features = ["extension-module"] }

 
[lib]
name = "lorenz"
path = "src/lib.rs"
crate-type = ["lib"]

anand@anands-MacBook-Pro ~/.c/d/lorenz (main)> uname -a
Darwin anands-MacBook-Pro.local 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30 20:39:35 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T8103 arm64

heres also a short clip displaying what i see

2023-05-05.12-46-19.mp4

[cassaundra]

Some file system questions that might help rule out potential problems: what file system are you using? does the file get written immediately? does the modification time update correctly?

[anandijain]

im using macos 13. i haven't messed with the FS. vscode saves after 1 second or so but i see that that's not the issue, since i can also repro after making a change to src/main.rs from vim. is that any help?

[weihanglo]

What would happen if you execute cargo run first. Then touch src/main.rs. And cargo run again?

Besides, could you follow this FAQ and run this?

CARGO_LOG=cargo::core::compiler::fingerprint=info cargo build --verbose

[anandijain]

does this clip provide any more information?

2023-05-20.16-24-01.mp4

here is the output of doing the build after a clean

anand@anands-MacBook-Pro ~/.c/d/mwe (main) [1]> cargo clean
anand@anands-MacBook-Pro ~/.c/d/mwe (main)> CARGO_LOG=cargo::core::compiler::fingerprint=info cargo build --verbose
[2023-05-20T20:28:19Z INFO  cargo::core::compiler::fingerprint] fingerprint error for mwe v0.1.0 (/Users/anand/.cargo/dev/mwe)/Build/TargetInner { name: "mwe", doc: true, ..: with_path("/Users/anand/.cargo/dev/mwe/src/main.rs", Edition2021) }
[2023-05-20T20:28:19Z INFO  cargo::core::compiler::fingerprint]     err: failed to read `/Users/anand/.cargo/dev/mwe/target/debug/.fingerprint/mwe-b730d5b325c44352/bin-mwe`
    
    Caused by:
        No such file or directory (os error 2)
   Compiling mwe v0.1.0 (/Users/anand/.cargo/dev/mwe)
     Running `rustc --crate-name mwe --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=162 --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C split-debuginfo=unpacked -C debuginfo=2 -C metadata=b730d5b325c44352 -C extra-filename=-b730d5b325c44352 --out-dir /Users/anand/.cargo/dev/mwe/target/debug/deps -C incremental=/Users/anand/.cargo/dev/mwe/target/debug/incremental -L dependency=/Users/anand/.cargo/dev/mwe/target/debug/deps`
    Finished dev [unoptimized + debuginfo] target(s) in 0.32s

[ilammy]

Also affected by this.

I have a workspace with a lot of binaries. I use cargo build to build them all, so that cargo run does not have to when I use it to run individual binaries. What I observe is cargo run rebuilding the workspace crates (but not third-party dependencies), with the same logs as in the previous comment.

I've managed to bisect the issue somewhat:

BAD:  nightly-2023-02-09   cargo 1.69.0-nightly (82c3bb79e 2023-02-04)

good: nightly-2023-02-03   cargo 1.69.0-nightly (e84a7928d 2023-01-31)

Sadly, the versions in between can't build the project, and I failed to reproduce the issue with a smaller projects so far.

[ehuss]

If you can reproduce it, can you do the following:

1. Run CARGO_LOG=cargo::core::compiler::fingerprint=trace,cargo_util::paths=trace cargo check
2. Change some file or use touch to update the timestamp.
3. Run CARGO_LOG=cargo::core::compiler::fingerprint=trace,cargo_util::paths=trace cargo check

and post all of the output? (You can zip it up, or post it in a gist if it is too large.)

@weihanglo Just FYI, that range includes #11672 and #11252 which are pretty suspicious. (Also #11665, but less so.)

[anandijain]

anand@anands-MacBook-Pro ~/.c/d/mwe (main)> CARGO_LOG=cargo::core::compiler::fingerprint=trace,cargo_util:
:paths=trace cargo check
[2023-05-31T06:05:14Z DEBUG cargo::core::compiler::fingerprint] fingerprint at: /Users/anand/.cargo/dev/mwe/target/debug/.fingerprint/mwe-4f282b851a48d248/bin-mwe
[2023-05-31T06:05:14Z DEBUG cargo::core::compiler::fingerprint] failed to get mtime of "/Users/anand/.cargo/dev/mwe/target/debug/deps/libmwe-4f282b851a48d248.rmeta": failed to stat `/Users/anand/.cargo/dev/mwe/target/debug/deps/libmwe-4f282b851a48d248.rmeta`
[2023-05-31T06:05:14Z INFO  cargo::core::compiler::fingerprint] fingerprint error for mwe v0.1.0 (/Users/anand/.cargo/dev/mwe)/Check { test: false }/TargetInner { name: "mwe", doc: true, ..: with_path("/Users/anand/.cargo/dev/mwe/src/main.rs", Edition2021) }
[2023-05-31T06:05:14Z INFO  cargo::core::compiler::fingerprint]     err: failed to read `/Users/anand/.cargo/dev/mwe/target/debug/.fingerprint/mwe-4f282b851a48d248/bin-mwe`
    
    Caused by:
        No such file or directory (os error 2)
    Checking mwe v0.1.0 (/Users/anand/.cargo/dev/mwe)
[2023-05-31T06:05:14Z DEBUG cargo_util::paths] invocation time for "/Users/anand/.cargo/dev/mwe/target/debug/.fingerprint/mwe-4f282b851a48d248" is 1685513114.120240879s
[2023-05-31T06:05:14Z DEBUG cargo_util::paths] set file mtime /Users/anand/.cargo/dev/mwe/target/debug/.fingerprint/mwe-4f282b851a48d248/dep-bin-mwe to 1685513114.120240879s
[2023-05-31T06:05:14Z DEBUG cargo::core::compiler::fingerprint] write fingerprint (6df1dc200f794b51) : /Users/anand/.cargo/dev/mwe/target/debug/.fingerprint/mwe-4f282b851a48d248/bin-mwe
    Finished dev [unoptimized + debuginfo] target(s) in 0.25s

this was the only thing related to an error that I saw. sorry i'm not more helpful here

[weihanglo]

Now I just realized your project is under ~/.cargo. There is an assumption that under ~/.cargo (CARGO_HOME) mtime check will be ignored (#11613).

Could you check if you move the project out of ~/.cargo to some place like ~/dev, does it recompile?

[cassaundra]

Assuming the problem is indeed with CARGO_HOME, it might be good to introduce a warning here to reduce confusion in the future.

[weihanglo]

Yep. Warning is an approach. The other way is that Cargo should only exclude ~/.cargo/registry and ~/.cargo/git, and maybe some more folders for internal use.

[weihanglo]

To fix this, I propose the approach in this #12090 (comment). The change will happen here.

I would not suggest adding a warning as this moment. It could be too verbose and noisy. We can have that warning once Cargo gets its own lint rules control.

@rustbot label -S-needs-info +S-accepted +A-errors +E-easy

[weihanglo]

@ilammy, it would be helpful you could provide more info or a minimal reproduction. I am not sure whether it is the same bug as the original issue.