depfile generated by rustc includes contains the depfile itself

[petrhosek]

rustc generates depfiles that have the following shape:

host_x64/exe.unstripped/cmc: ../../src/sys/cmc/src/main.rs ../../src/sys/cmc/src/cml.rs ../../src/sys/cmc/src/compile.rs ../../src/sys/cmc/src/format.rs ../../src/sys/cmc/src/merge.rs ../../src/sys/cmc/src/opts.rs ../../src/sys/cmc/src/validate.rs

host_x64/exe.unstripped/cmc.d: ../../src/sys/cmc/src/main.rs ../../src/sys/cmc/src/cml.rs ../../src/sys/cmc/src/compile.rs ../../src/sys/cmc/src/format.rs ../../src/sys/cmc/src/merge.rs ../../src/sys/cmc/src/opts.rs ../../src/sys/cmc/src/validate.rs

../../src/sys/cmc/src/main.rs:
../../src/sys/cmc/src/cml.rs:
../../src/sys/cmc/src/compile.rs:
../../src/sys/cmc/src/format.rs:
../../src/sys/cmc/src/merge.rs:
../../src/sys/cmc/src/opts.rs:
../../src/sys/cmc/src/validate.rs:

When invoking rustc from Ninja, it causes Ninja to rebuild the target on every invocation: Ninja consumes and deletes the cmc.d depfile (unless -d keepdepfile is specified) and process its content, recording cmc.d as an additional output of the rule that produced it. On the next invocation, Ninja notices that the cmc.d file is missing forcing a rebuild of that rule. rustc generates a new depfile, Ninja consumes and deletes it and so on which means that this process never converges.

I don't think rustc should be including the depfile itself in the generated depfile. I'm not aware of any other tool that would do that, and tools that consume depfiles such as Ninja cannot handle this.

[Mark-Simulacrum]

We do have -Zdep-info-omit-d-target which will skip that target I believe -- see #47035 where it was added.

We didn't want to make a breaking change there -- I think that's probably still the case? cc @alexcrichton, have your feelings changed?

[alexcrichton]

I'd basically feel the same way as before. I'm not necessarily for or against this change but it's unfortunately a breaking change and it's one we'd want to handle carefully. If analysis is done though to realize that it'd have low impact in the wild it seems fine to do. Otherwise we should likely stabilize something to get the behavior of removing the *.d file.

[Mark-Simulacrum]

Closing per the above, we're unlikely to move forward without some analysis and otherwise as a likely breaking change we wouldn't want to do it so there's no reason to keep this open. The flag to disable this behavior is already available on nightly.