Making the crate no_std and alloc compatible

[ngildenhuys]

Adding std and alloc features to the crate, enabling std as default. Allowing alloc feature to gate alloc struct implementations and std feature to gate std struct implementations.

[ngildenhuys]

#38

[epilys]

We're interested in using arbitrary in a no_std environment. Is there something blocking this PR? could it be merged?

[nagisa]

Suggested change

	- name: "Build"
	run: cargo build --verbose --no-default-features
	- name: "Build"
	run: cargo build --verbose --no-default-features --features=alloc
	- name: "Run tests"
	run: cargo test --verbose --no-default-features
	- name: "Run tests as no_std with alloc"
	run: cargo test --verbose --no-default-features --features=alloc
	- run: cargo build --verbose --no-default-features
	- run: cargo test --verbose --no-default-features
	- run: cargo build --verbose --no-default-features --features=alloc
	- run: cargo test --verbose --no-default-features --features=alloc

this ordering will likely reduce overall time mildly (and names are not only superfluous but also fail to differentiate the steps properly.)

[nagisa]

Suggested change

	# Turn this feature on to enable support for `#[derive(Arbitrary)]`.
	default = ["std"]
	derive = ["derive_arbitrary"]
	std = ["alloc"]
	alloc = []
	default = ["std"]
	alloc = []
	# Turn this feature on to enable support for `#[derive(Arbitrary)]`.
	derive = ["derive_arbitrary"]
	std = ["alloc"]

[ngildenhuys]

Besides the comment being adjusted to be above the corresponding feature, is there a reason for the specific ordering of the features? just curious.

[nagisa]

you're gating a chunk of these tests on the alloc feature, but then import hashset unconditionally. How does that work?

That said, I'd probably personally just specify the required features for tests in Cargo.toml and drop the cfgs. There is unlikely a future where there's any functional difference from enabling/disabling the features in this crate that would be worth testing.

[ngildenhuys]

I'll gate it properly. The compiler is being smart here since HashSet is only being use in a function that is itself only used in tests that are gated behind the alloc feature, in a no_std compile time I imagine it is just dropping the import.

[ngildenhuys]

actually doing some digging, you can import std without problem in test code because the unit test code is the only consumer of it and is compiled with std, the library code is compiled without std and linked in with the test code.

[ngildenhuys]

I figured you gate the alloc feature like any other feature (like the derive feature), the tests that are testing alloc structures should be gated under the alloc feature, any code that doesn't need alloc should be tested without alloc to ensure that "version" of the library does not regress in functionality