-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build caching issue: stage 0 fails in thiserror with "unresolved imports std::any::Demand
, std::any::Provider
"
#114839
Comments
As far as I understand, this is a bootstrap bug, not caching. See 1st paragraph of dtolnay/thiserror#243 (review). |
Although, sounds like I'm wrong because I wouldn't have expected I don't know of anything the thiserror build script is doing wrong with regard to caching. |
I think you mean rust-lang/cargo#11138, which I'd say is a cargo limitation. Here we don't have a proc macro dependency I think, so I don't think it is that problem. |
I think what happens is that usually, when the rustc version changes, cargo will rerun build scripts automatically. But here the rustc version is always Maybe bootstrap should delete the cached build script output when the stage0 library artifacts change? Not sure if it even knows that this is the case though. |
Will check what we can do on the bootstrap side by the coming weekend. Thanks for the ping. |
Hm, we usually rely on Cargo doing the rebuild as a result of depinfo containing references to the sysroot when it uses it (via -Zbinary-dep-depinfo), but in this case that doesn't get passed since we don't control the rustc invocation. I'm not sure we have a good way of recognizing when we need the rebuild and when we don't; we wouldn't want to always clear build scripts because that would cause many more spurious rebuilds... |
Hm yeah, maybe the right solution is for cargo to provide a native way of doing "probe builds", that integrates with its caching... |
Fixing this on bootstrap will most likely require implementing hacky tricks(like creating/moving some values as files between outputs and comparing them each time on the compilations) and that could make our complex flow even more confusing. And there's a good chance these things could cause unexpected problems that are hard to detect.
+1 |
FWIW for now thiserror is working around this via dtolnay/thiserror#248 |
Error message says it all:
This is probably related to #113464. It goes away when I
rm build/host/stage0-rustc -rf
. Looks like the thiserror build script is caching its output too aggressively, so it doesn't notice that it needs to be rerun? Cc @dtolnayThe text was updated successfully, but these errors were encountered: