0.31 fails to compile

[bestouff]

   Compiling rumqtt v0.31.0
error[E0308]: mismatched types
   --> /home/xav/.cargo/registry/src/github.com-1ecc6299db9ec823/rumqtt-0.31.0/src/client/network.rs:130:34
    |
130 |             config.set_protocols(&self.alpn_protocols);
    |                                  ^^^^^^^^^^^^^^^^^^^^ expected slice, found struct `std::vec::Vec`
    |
    = note: expected type `&[std::string::String]`
               found type `&std::vec::Vec<std::vec::Vec<u8>>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
error: Could not compile `rumqtt`.
warning: build failed, waiting for other jobs to finish...
error: build failed

[TheBestJohn]

What other crates are you using in this? This is due to an old rustls version being used. If you're just using this crate, do a cargo clean.

[bestouff]

I'm using it in a project with many other crates; maybe the problem is that the rustls dependency isn't correctly specified.

[tekjar]

@bestouff Can you try removing Cargo.lock and target dir and then recompile?

[TheBestJohn]

Yeah anything that depends on an older version of ring will fail with this. rustls used to use String for alpn_protocols docs and in version 0.15.0 onwards used Vec<Vec<u8>> docs. I had to excise the alpn parts to update. Not sure what I can do otherwise. This problem with interoperability is well known to the main Ring developer

[bestouff]

I tried recompiling without Cargo.lock and effectively rustls went from 0.14 to 0.15, and my project compiled. tokio-rustls also got a bump from 0.8 to 0.9, which is where rustls is pulled from.
So the problem lies in Cargo.toml's deps. I'm sending a patch.

[bestouff]

See MR #175

[tekjar]

Did you try removing both target and Cargo.lock at a time?

I'm ok with the pull request but I think there are people using rumqtt with other dependencies which require older version of ring. Wouldn't pinning tokio-rustls pin compatible ring as well causing conflicts with other dependencies depending on older ring?

NOTE: I could push this to crates and CI succeeds. Sort of proof that this a version conflict with local cache

[bestouff]

Did you try removing both target and Cargo.lock at a time?

Yes I did.

Wouldn't pinning tokio-rustls pin compatible ring as well causing conflicts with other dependencies depending on older ring?

I don't know. But now it may not compile, so there's obviously a bug.

[tekjar]

@TheBestJohn Are you able to compile 0.31?

[bestouff]

I think only people with a dependency on rustls 0.14 will see a problem when creating a new project.

[TheBestJohn]

@TheBestJohn Are you able to compile 0.31?

I can compile it by itself just fine but the alpn stuff gets in the way if I'm using it with Rocket.

That being said the proposed patch also fails for me.

    Updating git repository `https://github.com/bestouff/rumqtt`
    Updating crates.io index
error: failed to select a version for `ring`.
    ... required by package `webpki v0.19.0`
    ... which is depended on by `rustls v0.15.0`
    ... which is depended on by `tokio-rustls v0.9.0`
    ... which is depended on by `rumqtt v0.31.0 (https://github.com/bestouff/rumqtt?branch=patch-1#a141397b)`
    ... which is depended on by `mwe_rocket_rumqtt v0.1.0 (/Users/john/Desktop/tests/mwe_rocket_rumqtt)`
versions that meet the requirements `^0.14` are: 0.14.6, 0.14.5, 0.14.4, 0.14.3, 0.14.2, 0.14.1, 0.14.0

the package `ring` links to the native library `ring-asm`, but it conflicts with a previous package which links to `ring-asm` as well:
package `ring v0.13.5`
    ... which is depended on by `cookie v0.11.1`
    ... which is depended on by `rocket_http v0.4.2`
    ... which is depended on by `rocket v0.4.2`
    ... which is depended on by `mwe_rocket_rumqtt v0.1.0 (/Users/john/Desktop/tests/mwe_rocket_rumqtt)`

failed to select a version for `ring` which could resolve this conflict

[PetrGlad]

Also Rumqtt version 0.31 has no tag - it is hard to see which sources were actually used.

[PetrGlad]

I cannot build project using rumqtt 0.31.0, with same error. I, however can cargo build this project separately from master. ~~Note that published crate on crates.io uses tokio-rustls 0.8.1 (which in turn requires rustls 0.14) while project from git /master here requires tokio-rustls 0.9.3 (which in turn requires rustls 0.15.1). Actual versions are from Cargo.lock So, yes it would definitely help if each released version would have a tag in git here.~~

~~Also I am not sure what is expected behavior here but rumqtt's Cargo.toml has requirement tokio-rustls = ">=0.8, <=0.9" while actual used version is tokio-rustls 0.9.3~~

OK, cargo update solved the problem. The tokio-rustls indeed fits the range and there were changes in rustls since 0.14

[PetrGlad]

The fix would be to explicitly require tokio-rustls version 0.9.1 or later.

[TheBestJohn]

I don't think we can get away from historical rustls and ring issues here. It's a pain of moving forward. I also don't think it's incumbent on a libraries developer to support other libraries using old sources.

Using the master branch of Rocket solved this problem for me personally and I think that's the solution to other libs using incompatible libraries. It's not the problem of the more up to date library, rather an issue with the other library using an older version of a library that now has breaking changes.

More on this... it's also a rare issue as new dependencies being added isn't something that happens every day. Imagine this was added at the beginning. Rustls would have changed with this crate and the solution would have been "use this version here that uses the older syntax".

That being said, the ^0.9 addition makes sense now.

[feymartynov]

Had this error on macOS after system upgrade from Mojave to Catalina. Removing Cargo.lock and target dir of the project solved the problem.

[TotalKrill]

Which is just lucky and depending on other deps in the system, this project is now dependent on tokio-rustls ^9 and therefore the cargo.toml is essentially wrong for now

[TotalKrill]

So many people are now using this crate that I would vote for bumping the patch number for every fix that is done.