Change:
return None; } <del> if !builder.config.rust_codegen_backends.contains(&self.backend) { return None; } </del> if self.backend == "cranelift" { if !target_supports_cranelift_backend(self.compiler.host) { builder.info("target not supported by rustc_codegen_cranelift. skipping");

Discussion:
Bootstrap no longer documents any / crates or in CI. now only contains a meager 20 or so crates. This has to have regressed fairly recently.
It regressed in the latest nightly, we have CI tests on checking for some of these and the last daily test succeeded.
If I'm reading the commit history right there were a number of PRs that touched one of CI, bootstrap or rustdoc itself:
This appears to have regressed in ... but I'm pretty confused by that.
Since mostly allowed to have an effect, it could be that the issue is in .
cc and also maybe you happen to have an idea too
I don't have a clue how either PR could have affected building docs.
I would do quick check between the recently merged PRs as there are not many. It seems not to be so hard to find and fix the problem. But I can only do that later tonight.. I don't have access to my computers right now.
Ok, so the problem is when we use as a backend with llvm, documentation outputs generated by these backends seem to conflict with each other during the invocations. It appears that one of them(most likely cranelift) is not generating the compiler documentation. As we purge the previously generated documentation output at we end up with output that doesn't have the compiler documentation. I am currently unsure of the exact reason why cranelift is causing this issue. I will open a temporary fix PR and investigate further once I get more time.
Indeed the search at is completely useless right now. If a fix would take more than a day, reverting the offending PR should also be considered, given that those docs are quite crucial for rustc contributors.
Fix PR is already open at
Yeah I've seen that, but I can't tell if that's the lowest-risk approach. :shrug: Reverting (or un-setting on whatever builder builds the docs) is something we know will obviously work.
I am quite sure that PR contains no risk, but I am fine with reverting codegen environment variable updates in the runner containers
I'm fine either way but can't approve your PR since I don't understand the context of it. So if we can have it reviewed fast, fine, but otherwise - the revert is trivial to review.

did fix it locally, but seems didn't fix it on actual environment..
To fix this, we can either disable cranelift on the gh action step which we build nightly documentation or revert until we find out and fix the problem of compiler documentations with cranelift.
Which one is that?
I guess (never worked on the infra side before) these ones
Those steps just do the uploading, the docs are most likely created before. We need to figure out which runner is doing this and disable cranelift there.
It's done in multiple place(creating and uploading). I think the question is which one is getting deployed to
It's been 3 days without docs, clearly this is not entirely trivial to fix. Let's revert.
The docs are back.
While the immediate issue is addressed, do we need an issue to track the underlying problem?
We could. At the same time, and are also still working on this, e.g. in this as it's quite important to fix. There's little chance we'll forget about this, and it should hopefully be fixed very soon.
The underlying problem is that symlinks are being dropped in a wrong way between invocations. I can easily fix this by copying the document outputs instead of linking them, but I would prefer to invest a couple more hours in fixing the linking issue rather than replacing it.