Remove --cfg dox from rustdoc.rs

[jyn514]

This was added in #53076 because
several dependencies were using cfg(dox) instead of cfg(rustdoc) (now cfg(doc)).
I ran rg 'cfg\(dox\)' on the source tree with no matches, so I think
this is now safe to remove.

r? @Mark-Simulacrum
cc @QuietMisdreavus :)

[Mark-Simulacrum]

Hm, this also looks stale, we should really be passing --cfg bootstrap in stage 0 these days, cfg(stage0) shouldn't be used by anything.

Want to update that in this PR as well? (We should match rustc.rs).

[jyn514]

It looks like rustc.rs doesn't set it either, I did find it set in compile.rs though:

compile.rs
422-                        .arg("--cfg")
423:                        .arg("bootstrap")

Maybe nothing actually needs --cfg bootstrap for rustdoc? I'll try removing --cfg stage0 and see.

[jyn514]

Actually it looks like I was a little overoptimistic, library/stdarch is still using cfg(dox) :(

library/stdarch/crates/core_arch/src/mod.rs
6:#[cfg(any(target_arch = "arm", target_arch = "aarch64", dox))]
17:    #[cfg(any(target_arch = "x86", dox))]
28:    #[cfg(any(target_arch = "x86_64", dox))]
...

I'll make a PR upstream first.

[Mark-Simulacrum]

I guess this is blocked on a stdarch update?

[jyn514]

Yes, that's right. What's the process for that, do I just open a PR updating the submodule?

[jyn514]

I included the stdarch update in this PR.

[Mark-Simulacrum]

r? @Amanieu

I'll let @Amanieu approve the submodule bump.

[jyn514]

I also needed this diff to get the doc-tests to pass:

diff --git a/crates/core_arch/src/core_arch_docs.md b/crates/core_arch/src/core_arch_docs.md
index 64860050..3d363ea7 100644
--- a/crates/core_arch/src/core_arch_docs.md
+++ b/crates/core_arch/src/core_arch_docs.md
@@ -210,12 +210,6 @@ using LLVM's auto-vectorization to produce optimized vectorized code for
 AVX2 and also for the default platform.
 
 ```rust
-# #![cfg_attr(not(doc),feature(stdsimd))]
-# #[allow(unused_imports)]
-# #[cfg(not(doc))]
-# #[macro_use(is_x86_feature_detected)]
-# extern crate std_detect;
-
 fn main() {
     let mut dst = [0];
     add_quickly(&[1], &[2], &mut dst);

@Amanieu does that look like a reasonable change, should I make a PR with it?

[Amanieu]

@jyn514 Sounds good.

[jyn514]

This is ready for review.

[Amanieu]

@bors r+

[bors]

📌 Commit ca98778 has been approved by Amanieu

[jyn514]

@bors rollup=iffy

Updates submodules and I'm still not sure if removing --cfg stageN will break things.

[bors]

⌛ Testing commit ca98778 with merge 564586eb2abb8f9e5cd07f82266a87457f4ea1fe...

[bors]

💔 Test failed - checks-actions

[jyn514]

Looks spurious? cc @rust-lang/cargo

failures:

---- clean::clean_git stdout ----
running `D:\a\rust\rust\build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\release\cargo.exe build`
running `D:\a\rust\rust\build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\release\cargo.exe clean -p dep`
running `D:\a\rust\rust\build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\release\cargo.exe build`
thread 'clean::clean_git' panicked at '
Expected: execs
    but: exited with exit code: 101
--- stdout

--- stderr
   Compiling dep v0.5.0 (file:///D:/a/rust/rust/build/x86_64-pc-windows-msvc/stage2-tools/x86_64-pc-windows-msvc/cit/t478/dep#800dc269)
   Compiling foo v0.0.1 (D:\a\rust\rust\build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\cit\t478\foo)
error: linking with `link.exe` failed: exit code: 0xc0000374
  |

@bors retry

[ehuss]

I ran the test in a loop for a few hours locally, and didn't run into any problems. 0xc0000374 is STATUS_HEAP_CORRUPTION. I don't have any ideas what could cause that, other than a flaky VM or cosmic ray ☢️. I've never seen this error, but I'll keep an eye out if it happens again.

[bors]

⌛ Testing commit ca98778 with merge 6f56fbd...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: Amanieu
Pushing 6f56fbd to master...