Support for rust stable?

[jcornaz]

Hi,

I am wondering, what rust nightly feature this project needs? What would it take to support rust stable?

Even if it is not all playdate-* crates supporting rust stable, and if some features are gated behind a nightly feature flag, having playdate-sys supporting rust stable would already be awesome.

[boozook]

Hi Jonathan,

I'm using nightly in playdate-cargo and nightly features of underlying cargo as well as rustc (a little bit, and I thinking to rid of it).
So to build a game we need nightly anyway.

Also I'm sure we should not be afraid by nightly, because there are mostly only "unstable" features used are actually stable mostly and waiting stabilization, or features that will never be stabilized.

There is list of used nightly features:

• playdate-sys
  • lang_items
  • core_intrinsics
  • optional features:
    • allocator
    • panic_info_message
    • try_trait_v2 for impl FromResidual
    • adt_const_params to compile generated bindings with impl ConstParamTy for some simple types, optional, incomplete, but API seem to will not be changed.
• playdate-system
  • try_trait_v2 (optional)
• playdate-sound and others
  • error_in_core
  • const_trait_impl for extension-traits for enums and other simple types
• color and ctrl
  • impl_trait_in_assoc_type probably can be removed 🤷🏻‍♂️, I'll see

So, as you see, not for all crates it's possible currently. And it probably not needed because you're already have nightly and its features used in some compilation steps by playdate-cargo.
Of course, I concede that I could be wrong and would love to get your suggestions. I'd like to not make decisions on this project alone, ideally. Ideally it should be a democratic decision or at least a second maintainer.

[jcornaz]

Perfect! Thanks for the reply.

Also I'm sure we should not be afraid by nightly, because there are mostly only "unstable" features used are actually stable mostly and waiting stabilization, or features that will never be stabilized.

Yes, I fully agree, we don't need to be afraid of it. And we can even achieve build reproducibility by using a rust-toolchain.toml file (like this one) so the nightly channel is not problematic.

That being said, I think it is nice to aim at reducing the dependency on nightly features when possible. Even if we can never achieve it completely.

I don't mind using Rust Nightly for my final game projects, so it doesn't matter if cargo-playdate or not all playdate-* crates support only nightly. But it would be awesome if I could use the stable channel to develop intermediate crates that depend only playdate-sys. Again not a problem if it isn't possible. Just that it would be nice.

For now, having the list of used nightly features is all I wanted ;-)

[boozook]

Hmmm... Thinking about how to specify toolchain channel for one concrete crate and for all of them.
I can add rust-toolchain.toml to the directory of each package. For each package. One package, one file, I mean.
But as far as I remember, it doesn't work that way, i.e. in case of workspace only the root rust-toolchain.toml for the whole space will be used.

---

I've fixed the channel in the rust-toolchain.toml (#187).

[boozook]

@jcornaz, do you recommend place rust-toolchain.toml in every crate?

[jcornaz]

No. I would define it only on the root of the repository. My only recommendation would be to pin the exact nightly version, to maximize build reproducibility.

Also keep in mind, that this file only affects people working in that repo directly. AFAIK It doesn't affect consumers who download the crates from crates.io. Those consumers should create their own rust-toolchain.toml file, and it may be a different version of the nightly channel than defined here.