Closed RalfJung closed 1 month ago
One (I think somewhat typical) example of a leaky test is this: a Vec
is created but remains in a MaybeUninit
so it is never dropped.
I've nominated for libs-api to ensure this gets discussed but feel free to un-nominate if a decision is made before a meeting.
One (I think somewhat typical) example of a leaky test is this: a
Vec
is created but remains in aMaybeUninit
so it is never dropped.
Was that meant as an example of one that takes extra steps to unleak it? Since it calls assume_init
which makes the vec droppable again.
The Vec::leak doctest is an example that leaks.
Ah, I picked the wrong test indeed, sorry. Here is an example that leaks.
We discussed this in the libs meeting today. We would prefer to have miri check for leaks in doctests and handle the currently leaking tests by either:
no_leak_check
which disables leak checking just for that test.Adding a doctest attribute such as no_leak_check which disables leak checking just for that test.
That could be done if rustdoc allowed passing flags to Miri... but the could be only for Miri, not rustc, so not sure how to best do this. Alternatively, https://github.com/rust-lang/miri/issues/3670 would help.
This got fixed by https://github.com/rust-lang/rust/pull/127446 :)
Currently a bunch of our doctests have memory leaks. For that reason, we have to disable Miri's leak checker when running doctests.
To reproduce:
@rust-lang/libs how do you feel about that -- is it okay for the tests to leak, or should we fix that (by adding hidden code that deallocates things again)? Currently we don't have a good way to disable the leak checker on a per-test basis so there is a risk of accidental leaks.