c_str_alloc_error test: mention why this is mostly Miri-only

[RalfJung]

This was explained at the top of the file but I missed it there. Seems worth repeating at the attribute? Or am I just too blind?
Cc @bjorn3 -- is it expected that #[global_allocator] does not work in alloctests?

[rustbot]

r? @clarfonthey

rustbot has assigned @clarfonthey.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from Darksonn, JohnTitor, Mark-Simulacrum, clarfonthey

[bjorn3]

It is expected #[global_allocator] doesn't work with -Cprefer-dynamic (and should probably be turned into an error). I didn't know alloctests was compiled with -Cprefer-dynamic though.

[RalfJung]

We have this

rust/src/bootstrap/src/core/builder/cargo.rs

Lines 1439 to 1444 in 9d32c00

	// When we build Rust dylibs they're all intended for intermediate
	// usage, so make sure we pass the -Cprefer-dynamic flag instead of
	// linking all deps statically into the dylib.
	if matches!(mode, Mode::Std) {
	rustflags.arg("-Cprefer-dynamic");
	}

which I guess is also set for std tests.

[clarfonthey]

So, the test is mostly miri-only, but… I guess it is run outside miri?

Probably worth adding a comment to the top of the file too.

[RalfJung]

Yeah I thought it was better to also run what we can outside Miri. There is already a comment at the top, anything specific I should add?

[clarfonthey]

Mostly just think that this comment might be worth mentioning near the top: that the main benefit of this test is for miri since the global allocator isn't applied under normal testing conditions.

[RalfJung]

That's what it says, isn't it?

//! This only
//! reproduces under Miri: in a normal build the `#[global_allocator]` below can't
//! intercept the reallocation inside `CString::clone_into` (it lives in libstd, which
//! library tests link with `-C prefer-dynamic`), so as a regular test it just checks
//! the happy path.

[RalfJung]

So I guess I was wrong when I said that this wasn't explained in the test. I just missed it. Up to you if you think also adding a comment at the attribute is worth it.

[clarfonthey]

I guess I missed it too. I'll take over another look later and decide then.

[clarfonthey]

Yeah, looking at it again, I think this is fine.

@bors r+ rollup

[rust-bors]

📌 Commit 4cc87c1 has been approved by clarfonthey

It is now in the queue for this repository.