library: Move unstable API of new_uninit to new features

[workingjubilee]

• new_zeroed variants move to new_zeroed_alloc
• the write fn moves to box_uninit_write

The remainder will be stabilized in upcoming patches, as it was decided to only stabilize uninit* and assume_init.

• Tracking issue for uninitialized constructors for Box, Rc, Arc #63291
• Tracking Issue for new_zeroed_alloc #129396
• Tracking Issue for box_uninit_write #129397

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[workingjubilee]

Further extracted from #129401 as that PR is now waiting on a Tuesday.

[dtolnay]

Thanks!

[dtolnay]

@bors r+

[bors]

📌 Commit 275a526 has been approved by dtolnay

It is now in the queue for this repository.

[matthiaskrgr]

@bors r-
#129419 (comment)

[workingjubilee]

I suppose there isn't a way for Rust-for-Linux to be updated from our repository, huh.

[workingjubilee]

Hey, I opened Rust-for-Linux/linux#1106 but if that PR isn't good enough can one of you take over fixing RfL so we can later land the stabilization of the features you want? Thanks.

@rustbot ping rust-for-linux

[workingjubilee]

...Rustbot is being disobedient so

cc @alex @bjorn3 @Darksonn @dingxiangfei2009 @fbq @maurer @metaspace @nbdd0121 @ojeda @tgross35 @vincenzopalazzo @wedsonaf @y86-dev

[alex]

I see there's a thread on the RfL side, but I do think this points out the need for a clearer process when rust changes "break" rfl's use of unstable apis. We shouldn't assume rust contributors will be familiar with the kernel contribution process

[workingjubilee]

honestly the kernel itself certainly seems like it could benefit from more clearly paving and marking the path here, I didn't expect to wind up in a situation where I feel things like "I seem to be too {neurodivergence} to understand the directions for contributing to... that famous bastion of neurotypicality, the Linux Kernel Mailing List?"

and it seems that RfL does still use PRs, but mostly as a way to borrow the GitHub UI for a slightly less onerous review flow than mailing lists, and then those are routed to the mailing list?

[tgross35]

I see there's a thread on the RfL side, but I do think this points out the need for a clearer process when rust changes "break" rfl's use of unstable apis. We shouldn't assume rust contributors will be familiar with the kernel contribution process

Agreed to this, I think this is the first case we have encountered it.

and it seems that RfL does still use PRs, but mostly as a way to borrow the GitHub UI for a slightly less onerous review flow than mailing lists, and then those are routed to the mailing list?

That is accurate; we usually suggest that changes in early stages can go through a GH PR to collect some loose feedback before being sent to the list, but everything needs to go through the list for review and eventually getting picked up. We can of course help wherever needed - helping anyone figure out how to send patches, or forwarding patches for anyone who has a fix but doesn't know mailing list flow, or just doing the fix as needed.

[Darksonn]

We have a Rust for Linux page in the rustc-dev-guide. We should make sure that this link is shared when the job breaks.

[ojeda]

Hey, I opened Rust-for-Linux/linux#1106 but if that PR isn't good enough can one of you take over fixing RfL so we can later land the stabilization of the features you want? Thanks.

Thanks!

I see there's a thread on the RfL side, but I do think this points out the need for a clearer process when rust changes "break" rfl's use of unstable apis. We shouldn't assume rust contributors will be familiar with the kernel contribution process

As far as I understood it from the discussions, the idea was to ping us, i.e. it is not expected that Rust contributors need to get familiar with the kernel or its development process. But, of course, if they want to contribute, that is great!

[1] https://rust-lang.zulipchat.com/#narrow/stream/425075-rust-for-linux/topic/building.20on.20Rust.20CI/near/447162810
[2] https://rustc-dev-guide.rust-lang.org/tests/rust-for-linux.html#what-to-do-in-case-of-failure

[workingjubilee]

In general, I do not consult the rustc-dev-guide every time a build breaks. It generally does not change so often that such is useful, and for better or worse, it is rare that a test job is specifically documented inside it. (So Darksonn's idea seems persuasive.)

[workingjubilee]

#129479 (comment)
...an in-std use of new_zeroed... but only on FreeBSD, oddly enough.
@bors r-

[workingjubilee]

@bors r=dtolnay

[bors]

📌 Commit 90b4e17 has been approved by dtolnay

It is now in the queue for this repository.