Why is it hard (or even non-pathologically possible) for the CI system to do the right thing here? CI is choked because builds take a long time, typically.
-
-
It is very much not the case that changing a .md file in the docs causes an LLVM rebuild. This has *NEVER* been the case in Rust’s 10 year history.
1 reply 0 retweets 1 like -
Nor is it the case that changing a .rs file in the compiler causes an LLVM rebuild. Again, this has *never* been the case.
1 reply 0 retweets 1 like -
So if LLVM is being rebuilt when the docs change, it is a problem specific to the CI, and it should be solved *there*. Because if you change the build system to Bazel, and don’t fix *that* issue, it will *still* be a problem.
1 reply 0 retweets 2 likes -
This Tweet is unavailable.
-
Now we’re getting somewhere. The reason why that triggered a rebuild is that the compiler couldn’t tell—or, more likely, incremental compilation lacked the hooks to tell the build system—that a rebuild was not necessary.
1 reply 0 retweets 0 likes -
This is a problem that needs to be solved! But it needs to be solved *in the compiler*. The problem is presumably that the compiler, right now, can’t say “oh, I didn’t need to rebuild anything” in a way that the build system can understand.
3 replies 0 retweets 1 like -
Replying to @BRIAN_____ @sayrer and
How is the build system supposed to know? Does Bazel have a magic Rust parser that can understand comment changes?
2 replies 0 retweets 0 likes -
Replying to @pcwalton @BRIAN_____ and
Are you saying that it was the product of a single rustc command that was caused by the comment? The fact that every other step had identical-to-cache input was lost inside one opaque compiler invocation?
1 reply 0 retweets 0 likes
It was not identical-to-cache. Doc comments change metadata; debug info (file/line) changes.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.