Hi there,
I am working on nutype crate and ran into a dilemma.
I have the following piece in the documentation in lib.rs
//! A regular expression can be defined right in place:
//!
//! ```
//! # mod wrapper_module {
//!
//! use nutype::nutype;
//!
//! #[nutype(validate(regex = "^[0-9]{3}-[0-9]{3}$"))]
//! pub struct PhoneNumber(String);
//!
//! # }
//! ```
This only compiles if regex feature is enabled for nutype.
Question: how can I annotate the doc tests to compile this example with nutype having enabled regex feature?
I know I can pass --feature nutype to cargo test, but it's not exactly the same. I want to have a granular control over specific code examples.
You could include a configuration attribute in your doc:
//! A regular expression can be defined right in place:
//!
//! ```
//! # #[cfg(feature="regex")]
//! # mod wrapper_module {
//!
//! use nutype::nutype;
//!
//! #[nutype(validate(regex = "^[0-9]{3}-[0-9]{3}$"))]
//! pub struct PhoneNumber(String);
//!
//! # }
//! ```
The code will still show in the documentation, but from what I understand, it's not what you're trying to avoid.
Thanks for your reply!
Right, I saw this in frunk docs.
The problem with this, that it makes the doc & example conditional depending on the feature.
While what I want is to make it always be there, but be compiled with a particular feature enabled.
I did a quick test, and I get the documentation whether the feature is enabled or not (with cargo doc, or looking at the doc of a function in the IDE). Only the doc test isn't performed when the feature is disabled because the module that follows the attribute isn't compiled.
Do you see something different, or did I misunderstand you?
Oh. You want to always enable the feature in the doc test (and the doc test only), no matter what's in the Cargo.toml? In that case, I don't see a solution, but is it necessary?
AFAIK this is not possible. What I like to do is define a "meta-feature" like __doc or something which enables all necessary features needed to build documentation (I never had to deal with the use-case of two features being incompatible with each other before, that would require a different approach). Or just pass --all-features. You could also define an alias in your Cargo config.