Compile zenoh Rust rewrite with stable

[esteve]

It'd be great if the Rust rewrite of zenoh compiled with Rust stable, the following are packages in zenoh that use features from nightly or that are declared unstable:

• plugins/example-plugin
  • async-std unstable features
• plugins/zenoh-http
  • async-std unstable features
  • async_closure (stabilization being tracked at Tracking issue for #![feature(async_closure)] (RFC 2394 / RFC 3668) rust-lang/rust#62290)
• zenoh
  • async-std unstable features
  • async_closure (stabilization being tracked at Tracking issue for #![feature(async_closure)] (RFC 2394 / RFC 3668) rust-lang/rust#62290)
• zenoh-ffi
  • async-std unstable features
• zenoh-perf
  • async-std unstable features
• zenoh-protocol
  • async-std unstable features
• zenoh-router
  • async-std unstable features
  • get_mut_unchecked (stabilization being tracked at Tracking issue for {Rc, Arc}::get_mut_unchecked rust-lang/rust#63292)
  • async_closure (stabilization being tracked at Tracking issue for #![feature(async_closure)] (RFC 2394 / RFC 3668) rust-lang/rust#62290)
• zenoh-util
  • async-std unstable features
  • is_sorted (stabilization being tracked at Tracking issue for RFC 2351, "Add is_sorted to the standard library" rust-lang/rust#53485)

[esteve]

Which repository is the canonical one? I filed the issue here because I saw that the issue tracker was more active here than in atolab, let me know if I should file it elsewhere and where to submit PRs. Thanks.

[kydos]

@esteve your recombination is wise, but async-std is still stabilising and there are a few unstable features that we really need in zenoh. Our intent is to switch to stable as soon as we async-std allows us.

[kydos]

Most of our team works mostly out of the ATOLab fork https://github.com/atolab/eclipse-zenoh. There is a relatively big merge we plan to do at the end of this week. Thus in general if you want the bleeding edge, look at the ATOLab fork.

[esteve]

@kydos thanks for the info. I submitted the PR that removes the const_if_match feature gate (as it's been stabilized in 1.45) in the ATOLab repo, since it seemed to have the most activity, but I was confused at first where to file tickets and submit PRs.

I'll shortly submit a PR to document in the README that zenoh requires nightly.

[esteve]

I just realized that ATOLab has two repos https://github.com/atolab/eclipse-zenoh and https://github.com/atolab/zenoh, which one is the correct one? I submitted my pull request to the latter, should I submit it to the first one? Thanks.

[kydos]

@esteve, https://github.com/atolab/zenoh is the pre-eclipse repository -- we will archive that soon. https://github.com/atolab/eclipse-zenoh is the fork of the Eclipse Zenoh official repository, what we actively work on, before pushing into the official Eclipse Repo.

[esteve]

@kydos I see, thanks for the explanation. The changes were meant for atolab/zenoh, now that I've had a look at atolab/eclipse-zenoh some of the features from nightly have been integrated and some new ones popped up. I'll update this ticket to track packages that depend on nightly features.

[kydos]

Thanks @esteve !

BTW, the old zenoh repository has been parked.

[JEnoch]

@esteve : after internal discussions, we decided for more clarity to close/archive our https://github.com/atolab/eclipse-zenoh fork.
From now on, we're only working in this repo (using rust-master branch for current developments). Please submit your pull requests here.

[esteve]

@JEnoch thanks for the update, that definitely makes things clearer. I've updated this issue with the other features from nightly and their respective rustlang tickets.

[teburd]

I created a PR that lets zenoh build on stable #92 related to this

[Mallets]

#92 has been merged in the sync branch. It will land later on also in the master branch.

[JEnoch]

zenoh now build on stable in master branch.