fix rustls-aws-lc-rs feature

[stormshield-gt]

In the current Rust editions, if a dependency is declared as optional and it also exists a feature with the same name, dep:name will activate both the feature and the optional dependency.

That is the case for the rustls feature, so sadly

rustls-aws-lc-rs = ["dep:rustls", "rustls/aws-lc-rs", "aws-lc-rs"]

will also activate the rustls feature, which also activates ring.

There is a zulip discussion about this surprising behavior here.

Hopefully, in Rust 2024 edition, with this change, the behavior will be less surprising.

The PR introduce a breaking change, but as far as I know, there is no other way to fix this

Edit: I misunderstood the zulip thread; it's the crate/feature syntax that activates both the optional dependency and the feature if there is one with the same name. Not the dep:crate one. We can just use the crate?/feature syntax here and it should be non-breaking.

[djc]

The PR introduce a breaking change, but as far as I know, there is no other way to fix this

I don't think we want to do a breaking change for this.

[stormshield-gt]

I don't think we want to do a breaking change for this.

I see, do you have any ideas about other alternatives?

Right now the aws-lc-rs rustls-aws-lc-rs features cannot be used in the current state because quinn still uses the ring provider when they are activated.

By executing this command on main we can see that the ring feature is activated on quinn-proto, so in case of using rustls-aws-lc-rs we will fallback to use ring:

$ cargo tree -p quinn -f "{p} {f}" --no-default-features --features rustls-aws-lc-rs
quinn v0.11.5 (/home/tudyg/dev/forks/quinn/quinn) aws-lc-rs,rustls-aws-lc-rs
├── bytes v1.7.2 default,std
├── pin-project-lite v0.2.14
├── quinn-proto v0.11.8 (/home/tudyg/dev/forks/quinn/quinn-proto) aws-lc-rs,ring,rustls,rustls-aws-lc-rs,rustls-ring

[djc]

Maybe we can rename the rustls dependency to something else (like, rustls-core or something), adapting the code, to avoid dep:rustls triggering the feature of the same name?

[djc]

Note that we haven't released #1962 yet, so changing the aws-lc-rs features in backwards-incompatible ways could also be an option.

[stormshield-gt]

Some job failures (https://github.com/quinn-rs/quinn/actions/runs/11383037824/job/31667830692?pr=2015) seems unrelated to this PR, maybe this PR #2007 didn't pass fully the PR CI?

Maybe we can rename the rustls dependency to something else (like, rustls-core or something), adapting the code, to avoid dep:rustls triggering the feature of the same name?

Great idea, I will try this out

[stormshield-gt]

I misunderstood the zulip thread; it's the crate/feature syntax that activates both the optional dependency and the feature if there is one with the same name. Not the dep:crate one. We can just use the crate?/feature syntax here and it should be non-breaking.

I've added an edit to the PR description just in case

[stormshield-gt]

I've noticed some related things; I don't know where to put this out, so I put it here.

• Why the smoll and async-std are optional but not tokio? Some people, not us, might want to use the smoll and async-std runtime without compiling tokio.
• In the code the smol and the runtime-smol features are used interchangeably in #[cfg()]. Maybe it could be better to just use the runtime-smol everywhere, so we could use the crate/?feature syntax in the Cargo.toml. It will get rid of the implicit smol feature, better anticipating the 2024 edition.

[Ralith]

Why the smoll and async-std are optional but not tokio? Some people, not us, might want to use the smoll and async-std runtime without compiling tokio.

We use some portable synchronization primitives provided by tokio. When the runtime-tokio feature is not enabled, then the runtime components of tokio will not be compiled, so such a hypothetical user needn't be concerned about wasted compile time or code size.

Maybe it could be better to just use the runtime-smol everywhere

Seems reasonable.

[djc]

Looks great, thanks!