fix testing Miri with --stage 0

[RalfJung]

Fixes #78778 for Miri.

The issue remains open for error_index_generator, which has its own dylib logic:

rust/src/bootstrap/tool.rs

Lines 396 to 400 in 903e369

	add_dylib_path(
	vec![
	PathBuf::from(&builder.sysroot_libdir(compiler, compiler.host)),
	PathBuf::from(builder.rustc_libdir(compiler)),
	],

@jyn514 I could just copy the logic from add_rustc_lib_path, but that does not seem great. Any other suggestions?

Also I wonder if maybe prepare_tool_cargo should already call add_rustc_lib_path.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[RalfJung]

@bors rollup=iffy
because bootstrap

[jyn514]

@jyn514 I could just copy the logic from add_rustc_lib_path, but that does not seem great. Any other suggestions?

I don't have time to look into it now, but there's a whole mess of things I tried to do to fix it in #84776

[jyn514]

Can we fix it to not do this? Overwriting the old value seems very confusing.

[RalfJung]

(a) this is pre-existing, I'd rather not touch this since I have no idea what changing this will break,
(b) fixing it requires an unstable feature (#44434), which AFAIK bootstrap tries to avoid.

[RalfJung]

I don't have time to look into it now, but there's a whole mess of things I tried to do to fix it in #84776

Okay, so it seems reasonable then to ignore error_index_generator for this PR, I would say.

The main question that remains is if prepare_tool_cargo should call add_rustc_lib_path, or if we better leave that control to the individual tools.

[Mark-Simulacrum]

IMO this is probably fine -- it should be ok to have more libraries in the search path, generally speaking, especially for tools which aren't generally linked dynamically (other than to rustc/llvm, and then we just need these libraries in the search path).

So I think this PR is good if it works -- r=me if we've tested that.

[RalfJung]

IMO this is probably fine -- it should be ok to have more libraries in the search path, generally speaking, especially for tools which aren't generally linked dynamically (other than to rustc/llvm, and then we just need these libraries in the search path).

I can't tell if "this" is what the PR does, or the proposal of calling add_rustc_lib_path already in prepare_tool_cargo.

So I think this PR is good if it works -- r=me if we've tested that.

What kind of tests are you thinking of? I did verify that ./x.py test src/tools/miri --stage 0 passes with this PR as-is.

[Mark-Simulacrum]

Oh, I see -- yeah, this PR as is, or the more invasive patch both seem OK.

That verification seems sufficient for now. I'm not entirely sure this is correct but it does seem like the appropriate start.

@bors r+

[bors]

📌 Commit 9e674af has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit 9e674af with merge c4c2ab5...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing c4c2ab5 to master...