Closed vlovich closed 6 months ago
It's a bit weird since sccache hashes the content of all input files:
Could you create a reproducible example for me to investigate?
No, as I said it's really hard to figure out exactly how to reproduce it. Let's mark this as closed - maybe it's not sccache but rust-analyzer instead.
I'm seeing this frequently although I'm not certain the exact set of steps to repro. When using sccache, I'll do a build, then initiate an interactive rebase & try building an older commit. The older commit throws up compiler errors because older code for some reason is getting compiled against newer APIs.
Configuration: Linux 6.8.4 XFS filesystem sccache 0.7.7
My project is a workspace project. I haven't been paying attention but I think that the failures aren't just when the API is in a different workspace crate (i.e. I believe I've seen failures for in-crate code).
Touching the files explicitly that sccache is serving as cached snapshots (i.e. not the file that's failing to compile but the file containing the API that is claimed to be misused) seems to fix the issue.
My hunch is that there's some kind of brittle mtime code that accidentally thinks a file hasn't been changed because it's older than what was compiled in the cache or something. I would hope though that the file size is checked before any mtime logic since mtime is more brittle than file size. Continuing this train of thought, on Linux filesystems that support it, even better than mtime would be to use the
FS_IOC_GETVERSION
ioctl when it's available (available on most Linux filesystems) which along with the inode would be a more reliable way to detect if file contents have changed without even needing to hash the file.I originally thought it was a cargo bug (https://github.com/rust-lang/cargo/issues/6529) but turning off sccache fixes the issue (+ that bug is about overbuilding, not building against a stale cache).