-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
x.py check creates work for itself #82461
Comments
I think the issue might be that some dependencies are shared between bootstrap and rustdoc? I'm not 100% sure. |
Yeah, there's definitely something odd going on. Running with It's a bit noisy and hard to tell, but at least it looks like RUSTFLAGS is changing - -Zunstable-options gets omitted in one of the cases, which seems unexpected. Not sure why that's happening. |
Oh hmm, good catch. I expect this is what changes it: Lines 330 to 332 in fe1bf8e
|
Don't rebuild rustdoc and clippy after checking bootstrap This works by unconditionally passing -Z unstable-options to the compiler. This has no affect in practice since bootstrap doesn't use `deny(rustc::internal)`. Fixes rust-lang#82461. r? `@Mark-Simulacrum`
Don't rebuild rustdoc and clippy after checking bootstrap This works by unconditionally passing -Z unstable-options to the compiler. This has no affect in practice since bootstrap doesn't use `deny(rustc::internal)`. Fixes rust-lang#82461. r? ``@Mark-Simulacrum``
Don't rebuild rustdoc and clippy after checking bootstrap This works by unconditionally passing -Z unstable-options to the compiler. This has no affect in practice since bootstrap doesn't use `deny(rustc::internal)`. Fixes rust-lang/rust#82461. r? ```@Mark-Simulacrum```
I tried this:
x.py check && x.py check
I expected to see this happen: The first invocation does as much work as it needs to, and the second invocation does no work at all.
Instead, this happened: The second invocation checks rustdoc, clippy, and bootstrap twice.
Meta
Currently rebasing #79341 over fe1bf8e, but this has been happening for the last few weeks so I would expect any parent commit of fe1bf8e, to reproduce the issue.
The text was updated successfully, but these errors were encountered: