-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Cargo is not rebuilding a project that has been modified #8868
Comments
In case it makes a difference: I currently have |
|
Hm, without a reproduction it will be difficult to figure out what happened. For future reference, you can run with the The relevant line in the debug logs would look something like this:
The key is to check that mtime value against any source files you think should be newer. |
Strangely, I already managed to reproduce this.
So the file is almost 12 hours out of date, but cargo still isn't rebuilding it. |
What is the contents of |
|
I just ran into this again, on the same project :/ it's really frustrating - is there anything more I can do to help debug? It happens very frequently, although not every time. |
Actually I had a slightly different issue this time: |
What is the compile error? Or in other words, which dependency was out-of-date relative to what? You can gather the log messages, and check the mtimes and contents of the files to see if anything looks off. Cargo checks mtimes in two ways:
The first one is the "all paths up-to-date relative to" log message. Is there some source file listed in that dep-info file that you think has been modified and is newer since it was last built? For example:
You can compare the mtimes of the files listed in The second one is the "max output mtime for" log message. Do you think any of the dependency mtimes should be newer than that one? (Those listed as "max dep mtime for...") For example:
This says that the binary |
IIRC, the compile error was that I passed a borrow when it expected an owned value. The function used to take an owned value, but I changed it recently to take a borrow instead. The error occurred in the binaries, not in the tests themselves, even though So I would expect the mtime of the binary to be older than the library mtime, but it doesn't seem to be marked that way. |
I'm hitting a similar error in a workspace of mine, although the problem is different in that a workspace dependency is not rebuilt when running
even though the variant had been removed in https://github.com/robojumper/uc-analyzer/commit/8f11b9adfe246aa3793b7ab92040c2f6a3eef51b, 14 hours/4 commits earlier. Changes to This is despite I can't reproduce this from a fresh checkout, but I have a zipped copy of the project + target directory that I can use to reproduce this in a different folder. Console transcript with fingerprint trace
|
@robojumper I moved your comment to #10175, as fingerprint problems are usually due to different reasons. |
Problem
When I modify a file in the project, it is not rebuilt. Instead cargo thinks the project is fresh and uses a cached copy. I know it's wrong to do this because a fresh build (with a different toolchain) gives a compile error.
Steps
I am not sure how to reproduce this in isolation. I'm modifying a file in deadlinks/cargo-deadlinks@f3857e1, then running
cargo run
.I double-checked the last-modified date of
main.rs
and it says 19:39; the binary was built at 19:01.Notes
Output of
cargo version
:cargo 1.47.0 (f3c7e066a 2020-08-28)
The text was updated successfully, but these errors were encountered: