Fix no_std build

[taiki-e]

Closes #364

[taiki-e]

If build with Linux as a target, it will link to std, so it need to specify a target that does not have std.

[Restioson]

I see what you've done here & agree that it's a better solution to what I have done (less breakage)... however, I'm not sure how it handles lazy_static. Lazy_static is available for no_std with the spin_no_std feature (which by the way was originally why I changed the feature to no_std).

[taiki-e]

AFAIK the current no_std crossbeam does not depend on lazy_tactic.

The crossbeam currently uses lazy_static in two places:

crossbeam/crossbeam-utils/src/sync/sharded_lock.rs

Lines 556 to 562 in 86eff71

	lazy_static! {
	static ref THREAD_INDICES: Mutex<ThreadIndices> = Mutex::new(ThreadIndices {
	mapping: HashMap::new(),
	free_list: Vec::new(),
	next_index: 0,
	});
	}

crossbeam/crossbeam-epoch/src/default.rs

Lines 10 to 13 in 86eff71

	lazy_static! {
	/// The global data for the default garbage collector.
	static ref COLLECTOR: Collector = Collector::new();
	}

However, these are both in modules that require std. Also, they seem to be used with features not available on no_std.

crossbeam/crossbeam-utils/src/sync/sharded_lock.rs

Lines 7 to 10 in 86eff71

	use std::panic::{RefUnwindSafe, UnwindSafe};
	use std::sync::{Mutex, RwLock, RwLockReadGuard, RwLockWriteGuard};
	use std::sync::{LockResult, PoisonError, TryLockError, TryLockResult};
	use std::thread::{self, ThreadId};

crossbeam/crossbeam-epoch/src/default.rs

Lines 15 to 18 in 86eff71

	thread_local! {
	/// The per-thread participant for the default garbage collector.
	static HANDLE: LocalHandle = COLLECTOR.register();
	}

So I don't think crossbeam needs to think about lazy_static's no_std support.

[taiki-e]

Also, I believe many crates in the ecosystem (e.g., serde, futures, itertools) support the no_std environment in the same way as the current crossbeam.

lazy_static supports no_std in the other way as these crates, because it adds spin dependency.
(I think it can be solved by using their own Once and providing no_std support with the same way as the current crossbeam. However, I do not know if the lazy_static developer agrees with this. Also, to not break crates that currently use the spin_no_std feature, it needs to do no_std support on both spin_no_std and no-default-features instead of removing spin_no_std immediately, but I think doing this is not very difficult.)

---

FYI, you can always use the lazy_static/spin_no_std feature or configure the feature to allow users to opt-in like the following:

[dependencies]
lazy_static = { version = "1", optional = true }
[features]
std = ["lazy_static"]
spin_no_std = ["lazy_static/spin_no_std"]

The point to keep in mind when always using the lazy_static/spin_no_std feature is that it has not been tested on older versions than the latest stable (lazy_static, spin).

[Restioson]

FYI, you can always use the lazy_static/spin_no_std feature or configure the feature to allow users to opt-in like the following:

Yeah I just didn't want to fragment the options.

[ghost]

@taiki-e This looks great to me, thanks so much! :)

The only thing left to do is to update the readmes -- check out how we're currently explaining which parts of Crossbeam are available with individual features. We should probably also mention the alloc feature there.

[taiki-e]

@stjepang
I updated readmes and I added e3507f9 so that even targets that do not support CAS(compare-and-swap) operations such as thumv6m can be properly compiled. (Although #![cfg_attr(feature = "nightly", feature(cfg_target_has_atomic))] was originally valid for some crates, errors will occur if this configuration is not propagated.)

[ghost]

Thanks again, this looks ready for landing now! :)

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push