Another reasonable behavior (perhaps on top of the warning) is to rebuild only when the file is removed between builds or is created just before a new build (i.e. the file is "modified" in the sense that it went from existent to non-existent or vice versa).

I agree with @remysucre that a warning is not necessarily appropriate.

I came across the spurious rebuilding behavior described in this issue in the case of https://github.com/rust-lang/crates.io — they have a cargo:rerun-if-changed=.env but a .env file is not checked into the repo, in fact it is ignored via gitignore.

The behavior I would have expected is that Cargo remembers which rerun-if-changed files did not exist in the most recent build, and does not rebuild if they still do not exist. Could we consider the continual rebuilding behavior a bug?

crates.io$  cargo check
...
...
    Finished dev [unoptimized   debuginfo] target(s) in 21.91s

crates.io$  cargo check
   Compiling cargo-registry v0.2.2
    Finished dev [unoptimized   debuginfo] target(s) in 3.21s

crates.io$  cargo check
   Compiling cargo-registry v0.2.2
    Finished dev [unoptimized   debuginfo] target(s) in 3.24s

crates.io$  cargo check                       # each of these is a rebuild
   Compiling cargo-registry v0.2.2
    Finished dev [unoptimized   debuginfo] target(s) in 3.19s

crates.io$  touch .env

crates.io$  cargo check
   Compiling cargo-registry v0.2.2
    Finished dev [unoptimized   debuginfo] target(s) in 3.20s

crates.io$  cargo check
    Finished dev [unoptimized   debuginfo] target(s) in 0.12s

crates.io$  cargo check
    Finished dev [unoptimized   debuginfo] target(s) in 0.12s

crates.io$  cargo check                       # no longer rebuilding now that .env exists
    Finished dev [unoptimized   debuginfo] target(s) in 0.12s

There is a small backwards compatibility hazard for changing the behavior, if any project is relying on the way it works now. For example, rerun-if-changed=phony to force a rebuild every time. (similar to a Makefile .PHONY target)

I tried searching through crates.io, and I only found one that seemed to be doing this here.

I found a few others that do cargo:rerun-if-changed= without a value, which was a bit of a surprise. However, I don't think that would affect this issue (it seems like cargo treats that as "scan the whole directory").

I'm not sure if that's a big enough concern to block changing this behavior. I agree it is probably not the best behavior. A warning is an option, though I'm uncertain how likely that could trigger a false positive.

It won't be trivial to implement because cargo does not track the status of every file (it just tracks the newest mtime).