Description
Right now, if you work on a mir-opt test and iteratively change it without cleaning in between runs, your build directory can end up with content like this:
% ls -o *TypeckMir.before.mir )
-rw-r--r-- 1 pnkfelix 5759 Feb 9 15:42 rustc.node13.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 2773 Feb 9 14:42 rustc.node16.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 4373 Feb 9 15:42 rustc.node20.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 2817 Feb 9 14:54 rustc.node21.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 2816 Feb 9 14:56 rustc.node22.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 458 Feb 9 14:41 rustc.node29.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 458 Feb 9 14:54 rustc.node36.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 458 Feb 9 14:56 rustc.node37.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 2800 Feb 9 15:14 rustc.node40.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 2800 Feb 9 15:42 rustc.node43.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 3228 Feb 9 14:56 rustc.node4.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 844 Feb 9 15:14 rustc.node55.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 844 Feb 9 15:42 rustc.node58.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 2772 Feb 9 14:41 rustc.node7.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 458 Feb 9 15:14 rustc.node86.TypeckMir.before.mir
-rw-r--r-- 1 pnkfelix 458 Feb 9 15:42 rustc.node89.TypeckMir.before.mir
Note the wide variety of timestamps. As the node id's changed in response to source file modifications, some of the output stops getting overwritten and just stays in place.
This, combined with the mir-opt architecture where one embeds the name of the specific file that one wants to compare against, has a bad failure case during iterative development: if you are not paying attention and leave the header as e.g. START rustc.node4.TypeckMir.before.mir, you'll keep comparing your expected output against the same (stale) file, so you'll either get false negatives (the test passes because the embedded expected output is just as stale as the file you end up comparing against), or as you revise your concrete test input, you'll get false positives (the test fails because the now correct embedded expected output is still being compared against a stale file).
The user error here is of course that the START rustc.node4.TypeckMir.before.mir needs to be kept in sync with the actual node number to which the mir dump sends its output.
But it would be much better if compiletest did a sanity check on the time stamps: if the dumped mir output is older than the original source file, then chances are something has gone wrong, and compile test could either error in response, or at least issue a warning to the user.