r? @clubby789

rustbot has assigned @clubby789.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Some changes occurred in src/tools/compiletest

cc @jieyouxu

LGTM from the compiletest side once the pretty printer files changes are removed, but I don't have a Windows system to check if the above comment about the linker is true
r? compiler

I also don't have windows
r? bjorn3
I think I remember you knowing things about windows?

I haven't really touched Windows in years and never did any native development on it. I know some linkage related things because I was trying to get weak linkage working on Windows for EII. As such I don't think I'm a suitable reviewer.

Hmm... @michaelwoerister reviewed this code originally. Any thoughts?

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

rust/compiler/rustc_codegen_ssa/src/back/linker.rs

Lines 1087 to 1105 in a3903b1

	// This will cause the Microsoft linker to embed .natvis info into the PDB file
	let natvis_dir_path = self.sess.opts.sysroot.path().join("lib\\rustlib\\etc");
	if let Ok(natvis_dir) = fs::read_dir(&natvis_dir_path) {
	for entry in natvis_dir {
	match entry {
	Ok(entry) => {
	let path = entry.path();
	if path.extension() == Some("natvis".as_ref()) {
	let mut arg = OsString::from("/NATVIS:");
	arg.push(path);
	self.link_arg(arg);
	}
	}
	Err(error) => {
	self.sess.dcx().emit_warn(errors::NoNatvisDirectory { error });
	}
	}
	}
	}

can be removed after these changes, right?

Looking into it, this appears to be the case; the loop below this section that collects the natvis files from all compiled crates should be sufficient. Removed it.

This looks right to me. The only possible downside I can think of is that this now loads all the natvis files into memory and then writes them out to temporary files (with more obscure file names). But a) the size is not large and b) that's just like how user natvis files are treated anyway. So I don't think it's much of a downside. If it is advantageous to optimise this then such an optimisation should be applied outside of the standard library too.

I would be truly shocked if 14KiB of XML was what broke the bank for compiling on Windows.