1. 45
  1.  

  2. 10

    Good to see that when incremental builds are broken, it is a bug!

    I have fond memories of recursive Make (where correct incremental builds were practically unattainable): We would rush together as a bunch of developers standing almost on top of each other in someone’s office a few odd times per year. This to add the missing dependency in the toplevel Makefile, of course. Like a ceremony. Then, we would wish each other good luck and go back to work. At least, the bug was always in our hands.

    Even CMake, I think is flawed when it comes to cached variables (i.e. variables): There is no cache invalidation – they take precedence over new default values. Every time I get a nonsense error, and it helps to delete the build directory, I get so sad.

    1. 2

      Even CMake, I think is flawed when it comes to cached variables (i.e. variables): There is no cache invalidation – they take precedence over new default values. Every time I get a nonsense error, and it helps to delete the build directory, I get so sad.

      The hardest problem in CMake is what happens when you change the default: CMake’s cache doesn’t differentiate between variable-was-set-to-default-value-X and var-was-set-to-X. This tripped me up recently when LLVM switched to enabling the new pass manager by default. My builds had cached the disabled value because that was the old default.

    2. 4

      Cache invalidation remains a hard problem.

      1. 2

        Unfortunately, this was done under the assumption that the new verification would ship in 1.53, not 1.52.

        It turns out verify-ich was turned on in version 1.52.0, which was released recently.

        Curious, how did that happen?

        1. 2

          I’m normally impressed by the Rust team, but from my position of ignorance this seems like a surprisingly bad solution to this problem. It sounds like at least some people were planning the whole time to release 1.52 without fixing the bugs that were exposed by this check (just, without the check in place). Maybe they didn’t know about the miscompilation?

          The chosen solution, to totally disable a feature that’s crucial for usability, seems pretty extreme - surely there are less extreme workarounds? e.g. you could presumably simply clean the cache when you see this error.

          I do really appreciate the helpfulness of this blog post in describing the problem, and I’m probably missing some important details that make this the best way to deal with the situation.

          1. 21

            Rust is a lot about correctness, and we’d rather prefer to keep such a critical feature off rather than having it broken. We didn’t know about this bug until last Thursday and it’s actually present in versions before Rust 1.52.0.

            Even if rare and sporadic, this is most likely an old bug. This means that the recommendation for all users is to disable incremental compilation, even on older Rust versions if they want to make sure they don’t hit this bug.

            The new version was released to avoid users from downgrading to avoid the ICE, which would just hide a miscompilation - leading potentially to other problems that we would need to trace down to this bug.

            Incremental compilation also isn’t quite as crucial in Rust: it only happens on a per-crate level, so it’s not like you need to rebuild everything. It’s annoying, but this gives us time to write a proper fix.

            I would expect a 1.52.2 soon once engineers had a good look at this issue and validated solutions.

            1. 2

              surely there are less extreme workarounds?

              Add RUSTC_FORCE_INCREMENTAL=1 to your .profile and move on ? Hopefully you don’t ship anything critical this way. The new default just prevents any kind of miscompilations by giving you the safe route by default. That way nothing goes sideways at some possibly critical application due to a known bug. Which might do real world damage.