5 ms·
> If your build system knows what time it is and that can affect whether or not it compiles, that's a reproducibility problem. The very first example is of thi
by mlyle 5y ago
> If your build system knows what time it is and that can affect whether or not it compiles, that's a reproducibility problem.
The very first example is of this:
// trigger a compile error if we're past a certain date
todo_or_die::after_date!(3000, 1, 1); // its the year 3000!
And the second and third examples (this is all of them) are explicitly relying on non-versioned, external state leaking in, too.
// or a GitHub issue has closed
todo_or_die::issue_closed!("rust-lang", "rust", 44265); // GATs are here!
// or the latest version of a crate matches some expression
todo_or_die::crates_io!("serde", ">1.0.9000"); // its over 9000!
- iudqnolq 5y agoBut the issue is that the time your build process observes changes, not that you add a place that observes the time. If you're not fakeing time already it'll end up in all sorts of other places.
- jrockway 5y agoYup, that's exactly what I was hinting at. This sort of statement makes it clear that there is an undesired connection to the system clock, but of course all those tests that use time.Now() or whatever are equally likely to become faulty.