r? @MomoLangenstein

I think you should also pin indexmap since building with all features on 1.36.0 still fails. Afterwards, the workaround in the CI could probably also be removed.

Good point, I wasn't aware indexmap is also an issue. However, forcing an exact version for it has more implications than it has for bitflags...

Afterwards, the workaround in the CI could probably also be removed.

Yes, I'll do that 👍

Good point, I wasn't aware indexmap is also an issue. However, forcing an exact version for it has more implications than it has for bitflags...

That is true ... it seems that hashbrown is the problem there as it uses the ptr_cast feature that wasn't stable yet in 1.36.0

I'll merge this as-is, it's already a bit of an improvement.

bitflags only provides a macro that generates code for us, so if it gets included with multiple different versions in a dependency tree it won't cause any issues.

IME cargo will fail to compile rather than including multiple compatible versions of a crate in the tree, so anyone depending on ron won't be able to use a newer version of bitflags (unless they release a new major version)

@Imberflur that's only when you have that dependency in your public API.

that's only when you have that dependency in your public API.

@torkleyy unless I'm missing something that is not the case.

I created a test setup to try this and it produces an error https://github.com/Imberflur/cargo-dep-resolution-test

FWIW I'm not currently running into this issue, but I expect I will likely encounter it in the future when another dependency or my code tries to take advantage of any newer features in the bitflags crate. So I wanted to explore the issue ahead of time.

This might be relevant: https://github.com/rust-lang/rfcs/blob/master/text/2495-min-rust-version.md#future-work-and-extensions

e.g. see nix-rust/nix#1548

Oh I see. My understanding was that Cargo can handle multiple versions of a dependency in the tree, which is the case, but with the limitation that all versions must be semver incompatible, which isn't true for bitflags...