Fix h1-client and default-client feature

[taiki-e]

Context: http-rs/http-client#67 (comment)

This also adds a CI task to check all feature combinations work properly. (This is almost the same as that used in crossbeam, futures-rs, hyper, etc.)

[taiki-e]

If this check takes a long time, it can limit the max number of simultaneous feature flags by passing the --depth flag. (like futures-rs, hyper, etc. do) AFAIK --depth 2 should be sufficient in most cases as described in taiki-e/cargo-hack#58.

[JEnoch]

Hi @taiki-e,

Thanks for your insights in here and http-rs/http-client#67 + http-rs/http-client#69 !
I realise you're far more experienced than I am with Cargo features...

The full purpose of this is to be able to configure Surf to use h1_client + rustls. See my attempt in #271.
I'm not sure to see how we would achieve that with your PR, since the h1-client defaults to http-client/native-tls. What's the best solution in your opinion ?

[Fishrock123]

I'm not sure to see how we would achieve that with your PR, since the h1-client defaults to http-client/native-tls. What's the best solution in your opinion ?

I thought we were already disabling http-client's default features in Surf?

[JEnoch]

I'm not sure to see how we would achieve that with your PR, since the h1-client defaults to http-client/native-tls. What's the best solution in your opinion ?

I thought we were already disabling http-client's default features in Surf?

Yes. I meant that in the Cargo.toml of this PR the h1-client feature uses http-client/h1_client + http-client/native-tls. We would still lack a feature in Surf to use http-client/h1_client + http-client/rustls.

[Fishrock123]

And looks like I have been bitten by this myself. I'll make sure to deal with this stuff properly tomorrow, finally.

[Fishrock123]

These should not be necessary - we allow building the wasm client even if the target arch is not strictly wasm32.

Also, even if it was, most of these clients explicitly set the default-client feature, and so the casing would only need to be for the wasm client.

[taiki-e]

we allow building the wasm client even if the target arch is not strictly wasm32.

http-client's wasm module compiles only on wasm targets, so building wasm-client on non-wasm targets will fail to compile.

Also, even if it was, most of these clients explicitly set the default-client feature, and so the casing would only need to be for the wasm client.

The problem is when the default-client feature is specified and no client is specified.
In that case, DefaultClient is not defined, so the compilation will fail if only cfg(feature = "default-client") is used.

surf/src/client.rs

Lines 10 to 20 in fc75a59

	cfg_if! {
	if #[cfg(feature = "curl-client")] {
	use http_client::isahc::IsahcClient as DefaultClient;
	} else if #[cfg(feature = "wasm-client")] {
	use http_client::wasm::WasmClient as DefaultClient;
	} else if #[cfg(feature = "h1-client")] {
	use http_client::h1::H1Client as DefaultClient;
	} else if #[cfg(feature = "hyper-client")] {
	use http_client::hyper::HyperClient as DefaultClient;
	}
	}

However, cfg(feature = "default-client") isn't really needed here, so it seems right to remove it.

[taiki-e]

The problem is when the default-client feature is specified and no client is specified.
In that case, DefaultClient is not defined, so the compilation will fail if only cfg(feature = "default-client") is used.

Another way to deal with this is to explicitly fail the compilation if only the default-client feature is specified: https://github.com/rust-lang/futures-rs/blob/c7328778999f8d20f5c3bb821a8ad38b72923ff9/futures-core/src/lib.rs#L13-L14
It will make managing cfg somewhat easier.

[taiki-e]

All clients enable this feature and all cfg(feature = "default-client") removed, so this feature is no longer used.

[Fishrock123]

Ok well I have merged the important part in #291

I'd rather not get rid of default-client if possible because it makes all of the cfg statements much easier to read, although it should probably be renamed to __default-client.

I did not take the wasm32 change because it unnecessarily complicates things.

Both of those features are just ignored in the cargo hack check because the first doesn't matter 9impliced by other features) and the second we check properly in a separate wasm context.