Closed d-e-s-o closed 3 weeks ago
This looks potentially useful, but your crate is barely a day old. Nextest had been around for 5 months and was already well-known in the ecosystem when we added support.
This looks like an attempt to use Miri to promote your crate. I'd be much more open to merging this if your crate can become well-known on its own.
This looks potentially useful, but your crate is barely a day old. Nextest had been around for 5 months and was already well-known in the ecosystem when we added support.
This looks like an attempt to use Miri to promote your crate. I'd be much more open to merging this if your crate can become well-known on its own.
Yeah, it's used in crates such as blazesym
[0] and libbpf-rs
[1] currently (which just haven't seen an release since), but your assessment is correct.
That said, I wouldn't have created it if I didn't see a need for it and to the best of my knowledge it offers the only reasonably flexible & reliable way of opting a larger code base into Miri usage, so I think it's entirely justified to mention it here (and it's not like I spammed the README with paragraphs over paragraphs of usage examples or whatnot; and I certainly don't get paid anything if people use it). But feel free to close if you are not interested and/or tell me to come back later, no hard feelings.
Given that Miri is an official Rust project, I think we should generally only advertise crates that are already pretty established in the community - and only if this is really needed for efficient use of Miri. So I agree with Ben.
Nevertheless good luck with your crate!
Sounds good!
The usage of
#[cfg_attr(miri, ignore)]
works well if the majority of tests is Miri compatible, but can be cumbersome if that's not the case. Thetest-tag
crate provides the means for having an opt-in scheme instead, which may be preferred in larger code bases.Given that the README already mentions
nextest
as a third party crate, embed a short note about the possibility of usingtest-tag
as well.