Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[guide] How to disable miri in doctests #3381

Closed
yoshuawuyts opened this issue Mar 14, 2024 · 6 comments
Closed

[guide] How to disable miri in doctests #3381

yoshuawuyts opened this issue Mar 14, 2024 · 6 comments

Comments

@yoshuawuyts
Copy link
Member

I'm documenting this for posterity in an issue, following up from #584. This is what I've used to disable miri from running in my doc tests:

/// # Example
///
/// ```
/// # #[cfg(miri)] fn main() {}
/// # #[cfg(not(miri))]
/// # fn main() {
/// use my_crate::my_function;
///
/// my_function();
/// # }
/// ```
fn my_function() {}

This should show the example as intended in the docs while also ensuring miri doesn't run this particular doctest. This also provides a dummy main function to ensure that miri doesn't complain about a missing fn main either.

This took me around 30 mins to figure out, so I wanted to make sure I'd leave a note of how to do this in the miri repo in case anyone else runs into this in the future. Thanks!

@yoshuawuyts
Copy link
Member Author

yoshuawuyts commented Mar 14, 2024

Closing this straight away as there shouldn't be anything actionable here.

@RalfJung
Copy link
Member

RalfJung commented Mar 14, 2024

Usually I would do that via:

/// ```no_run
/// my_function();
/// ```
fn my_function() {}

This will type-check the doctest but not run it.

So a trick like the above is only needed if you want the example to run in cargo test but not cargo miri test. That should be pretty rare I think? But the dummy main function is a nice trick, I recently wanted to enable a test only under cfg(bootstrap) and couldn't get it to work; this would have done it.

@yoshuawuyts
Copy link
Member Author

So a trick like the above is only needed if you want the example to run in cargo test but not cargo miri test. That should be pretty rare I think?

This came up when writing yoshuawuyts/futures-concurrency#167 earlier today. Miri doesn't understand how things like async timers work, so I figured we should just skip the doctest here. But it's still useful to test on e.g. linux to actually ensure the test works as intended.

@saethlin
Copy link
Member

Miri doesn't understand how things like async timers work

Because of an attempt to call an external function or make a syscall Miri doesn't understand? Which one(s)?

@yoshuawuyts
Copy link
Member Author

I believe it may have been something kqueue related given I'm on macOS and was executing async code. My test pulls in an async timer crate, which I don't think Miri liked.

@RalfJung
Copy link
Member

Yeah Miri can't run the Tokio executor on any target I think. On Linux it's missing epoll.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants