-
Notifications
You must be signed in to change notification settings - Fork 110
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
Consider using a feature rather than cfg flag #235
Comments
cargo feature needs to be additive. see also crossbeam-rs/crossbeam#638 |
This is additive I believe unless I'm missing something? A |
Oh, I see, Loom functions expect |
Some of the features do not work outside of the loom::model function. Lines 32 to 42 in 0d7f0d5
A feature that can break most of the existing tests with panic should not be called "additive", even if it does not seem to break the API. |
The workaround for these problems is to make loom an optional dependency: crossbeam-rs/crossbeam#666 |
Currently Loom recommends using target specific dependencies.
This works, however it has certain drawbacks:
Building with
RUSTFLAGS="--cfg loom"
requires rebuilding every dependency.cargo vendor
vendors dependencies of loom.Dependencies of
loom
are included in Cargo.lock when using a crate that depends on loom.cargo audit
includes dependencies of loom when using a crate that depends on loom.Requiring an user to use
RUSTFLAGS="--cfg loom"
to test crate with loom.Requiring an user to import loom or std types depending on whether loom is enabled.
All those issues would be solvable if
loom
did use a feature rather than a config flag. To clarify what I mean: the user could useloom
like this inCargo.toml
.Then import whatever they want by simply using
use
, without having to bother with#[cfg]
orcfg_if!
.That would work because Loom crate would provide a basic
AtomicUsize
implementation that directly uses methods fromstd
whenmodel
feature is not enabled. This means no performance cost when not usingmodel
feature.Some possible concerns:
#[cfg(test)]
themselves to mockloom
APIs, just like they have to right now.loom
in tests due to Cargo merging all features used within a crate? No, assuming new feature resolver is being used (Rust 1.51+, needs to be opted-in withresolver = "2"
oredition = "2021"
). That said, a note in documentation should be added recommending using new feature resolver for programs that use loom for testing themselves (it's not necessary for libraries or programs that happen to use libraries that use loom).The text was updated successfully, but these errors were encountered: