Re: rust and rust-bin out of sync?

[pin <voidpin%protonmail.com@localhost>]

------- Original Message -------
On Tuesday, August 22nd, 2023 at 12:54 AM, Greg Troxel <gdt%lexort.com@localhost> wrote:

Let's take one thing at the time, shall we?
Starting with cargo-c

> devel/cargo-c is at 0.9.23
> 
> I have a box which is netbsd-10 amd64, just before the openssl pullup,
> with rust-bin installed, and cargo-c is failing to build:
> 
> ===> Building for cargo-c-0.9.23
> 
> Compiling cargo v0.72.2
> error[E0658]: use of unstable library feature 'once_cell'
> --> /tank0/ztmp/work/devel/cargo-c/work/vendor/cargo-0.72.2/src/cargo/util/mod.rs:215:9
> 
> |
> 215 | use std::sync::OnceLock;
> | ^^^^^^^^^^^^^^^^^^^
> |
> = note: see issue #74465 https://github.com/rust-lang/rust/issues/74465 for more information
> 
> It seems an obvious upstream bug in cargo to use an "unstable library
> feature" rather than a year-numbered edition, but this is rust :-(
[...]
> What's up with cargo-c? It is not declared as needing any particular
> version of rust (and it seems quite unreasonable to need anything
> bleeding edge
[...]

This is rather unfortunate. Not all projects specify which Rust version they actually require but, cargo-c actually does.
I've crosschecked this before merging the latest cargo-c, it clearly states 'rust-version = "1.69"' on line 12 of Cargo.toml,
see https://github.com/lu-zero/cargo-c/blob/master/Cargo.toml

Also, have a look at the package cargo-depends.mk, it contains a dependency on the once_cell crate.
Look for the line containing 'CARGO_CRATE_DEPENDS+= once_cell-1.18.0'.

In other words, this shouldn't happen and it's clearly something upstream has missed.

Now, to the error itself.
once_cell used to be an external crate up to Rust-1.69 but, it was stabilized and merged into Rust in version 1.70
I understand it's frustrating to see 'error[E0658]: use of unstable library feature 'once_cell'' instead of a version requirement.
Although, if you follow Rust development, the error is rather obvious.

I think it's difficult to predict when a certain feature will actually be stabilized and merged into Rust.
Hence, the missing version requirement. By the time 1.69 was released there was probably not known when once_cell would be merged.
Sometimes, it happens and the error is more clear, stating the required Rust version.

Downgrading cargo-c brings in other issues, see https://mail-index.netbsd.org/pkgsrc-users/2023/07/22/msg037773.html
Easy to fix but, I think the correct thing to do is to bring rust-bin up-to-date with lang/rust.


> We're heading to pre-freeze so I am wondering what is the plan for rust
> for 2023Q3.
> 
> lang/rust is at 1.70.0
> lang/rust-bin is at 1.69.0
> 
> wip/rust is at 1.71.1

I'll leave this for Håvard to answer but, as far as amd64 is concerned there are no issues with 1.71.x
I've been using 1.71 since mid July and all my packages build fine with it, including firefox-115 and 116.
So, again on amd64, the obvious would be to get all these in sync at version 1.71.1

> It seems obvious that anything rust in tree needs to build with rust and
> rust-bin both, and that updates to new code shouldn't happen if that
> isn't true.

Agreed. But, I don't use rust-bin and I think it's easy to forget about syncing it with lang/rust

> Questions arising:
> 
> Am I confused about that I'm seeing, or is it just me?
[...]
See, above. This shouldn't be happening with cargo-c

> Is there a reason rust-bin is behind rust? Just round tuits? Is
> someone going to move rust-bin to 1.70.0 before 9/1?

Not that I'm aware of. Most probably just slipped through.

> Is anyone thinking of landing 1.71.1 in lang/rust before 9/1? I would
> guess not because I haven't been hearing about a call for testing
> already -- but I could be off.

It would be good to get 1.71.1 in because ...
1) 1.72 will be released in less than 48h. The Q3 branch will then be behind upstream by 3 versions.
I know what you think but, 3 version is a lot in the Rust world.

2) Soon it will be possible for projects to set 'edition = 2024'
This will mean that if this variable is set, the project won't build with Rust < 1.71
It's similar to what happen when 'edition = 2021' was introduced requiring Rust >= 1.56

3) Everything using once_cell will eventually break with Rust < 1.71

But, please wait for Håvard to speak.

Regards,
Pedro