Make loom dependency optional

[taiki-e]

The loom dependency will never compile unless users enable cfg, but the way cargo and crates.io handle cfg-ed dependencies is not very good and confuses users.

This issue seems to work around by the way proposed by @matklad in #487 (comment).
So this PR uses that workaround.

Closes #665

r? @jeehoonkang @jonhoo

[taiki-e]

bors d=jonhoo

[bors]

✌️ jonhoo can now approve this pull request. To approve and merge a pull request, simply reply with bors r+. More detailed instructions are available here.

[jonhoo]

bors r+

[bors]

Build succeeded:

• ci

[taiki-e]

@matklad @djc: Do you need me to do a new release?

[matklad]

I would appreciate one!

[taiki-e]

Published in crossbeam-utils 0.8.3 & crossbeam-epoch 0.9.3.

[djc]

@taiki-e thanks for getting this resolved so quickly!

[faern]

Do you people remember why you put loom both behind a cfg and made it optional? I see you still have this solution in place. I faced the same issue as this PR solves, but I found no downside of only making it an optional dependency: faern/oneshot#43. I'm trying to figure out if I missed some aspect of this. I have not published my crate yet since making the change, so would love to figure out any issues first :P

[taiki-e]

@faern See #487 (comment) (and subsequent 2 comments) and #638 for related discussion. (TL;DR that is not compliant with Cargo's recommendations)

[faern]

I have read those, and it did not shed any light on it for me. I'm not really asking why it's optional, rather why it's behind cfg(loom). I know the feature goes against the rule that features should be additive. Also internals for testing should not be exposed with features.

But changing from [dependencies] loom = ... to [target.'cfg(loom)'.dependencies] loom = ... does not help from what I can tell. The loom feature is still listed in cargo metadata. And my crate is built with the loom feature on if I do cargo build --all-features. The only difference is that if I guard loom both behind being optional and [target.'cfg(loom)'.dependencies] is that if a downstream user builds with the loom feature enabled, they still get standard functionality (not loom)... But that's ugly. Having them build with loom is also ugly, but yeah.

Is your motivation that by making it a cfg, even if it is exposed as a feature, enabling it does nothing for downstream?

EDIT: Cargo is indeed not really equipped to handle this well. But yeah, your solution is probably the least bad :) I move towards that also: faern/oneshot#45