rust: Eschew Box<MaybeUninit<T>>::write
#1106
Conversation
T-libs-api has consensus for stabilizing some of `feature(new_uninit)`, but not for `Box<MaybeUninit<T>>::write`. The replacement is trivial, so let's just do that, and RfL can simply move off the feature after it is stabilized. That will happen immediately after this unblocks Rust CI, as the relevant FCP has completed: rust-lang/rust#63291 (comment) This is required in advance of the stabilization because any remaining unstable API will be carved up into subfeatures as a direct result of stabilizing the majority of it. This code doesn't know about those yet. It can't, as they haven't landed, as building this code blocks Rust's CI but the expected-to-be-stabilized API can't be stabilized as long as this code requires that feature. Signed-off-by: Jubilee Young <[email protected]>
|
This looks reasonable to me but it does need to go through the list. Are you able to send it or would you prefer one of us forward it for you? |
|
which one tho' |
|
Just the default Lines 19907 to 19917 in 6d1c22d |
|
I would never have guessed to send it to that specific list so there's nothing "default" about it. |
|
Heh by default I guess I just meant whatever get-maintainer.pl would have said. But yeah, that's the main list for anything rust related (archives at https://lore.kernel.org/rust-for-linux/) |
|
...Why does the kernel document mailing list procedure in the kernel's source docs, instead of somewhere linked from the various webpages touting to be the LKML FAQ? It was a stroke of luck that I got Kconfig to work to test this at all. I'm honestly kind of baffled that something like |
I mean, I can understand the chain of events that does lead to the placement making more sense, I just can't understand not e.g. decommissioning http://vger.kernel.org/lkml/#s4 posthaste. Surely the Linux Foundation can afford sufficient devops assassins to put out a hit on a rogue HTML file? |
|
Fwiw I think https://docs.kernel.org/process/submitting-patches.html is the place most people get pointed now, I don't think I have ever seen the FAQ you posted. I don't disagree that figuring out the emails is about the worst part of kernel development, I still struggle to reply to emails that aren't already in my inbox (just subscribing to every list is easier than setting up Mutt, lol). If it helps, usually the process looks something like: # Get a .patch file for the last 1 commit
git format-patch -1
# List of people to mail
scripts/get_maintainer.pl 0001-my-thing.patch --norolestats
# Send it, usually `to:` the maintianers and `cc:` the lists and everyone else
# from the output above. There's a `--dry-run` option to try first
git send-email --to='...' --cc='...' ... 0001-my-thing.patch |
|
If it's still giving you problems then one of us can forward it for you fine, not trying to put you in mailing list pain because you made the mistake of being helpful. But usually it's pretty straightforward to send it. But the Rust build options are indeed pretty hidden, lots of looking at the target dependencies in menuconfig unfortunately. Hopefully that will get better as we stop requiring a lot of tiny things to be turned off. |
|
I will simply remain surprised there's no equivalent of |
|
And I will take a quick look at the patch formatting before deciding whether to put you up to it, I had to finish filing a form with a Byzantine bureaucracy first (I've done this before and my main annoyance, that I remember, was trying to make sure that it was an ASCII patch or whatever). |
|
There, sent to the mailing list. |
|
Thanks for your feedback @workingjubilee! I have forwarded it to the admins (for the vger one in particular, perhaps they can do something about it), but please note that most of these involve changes for most of the kernel, so they aren't things we can tackle independently.
We have some docs of our own at https://rust-for-linux.com/contributing, with links to the relevant kernel docs and some other tips. https://kernel.org has also a link to the docs, https://docs.kernel.org, which explains how to interact with the kernel.
Hmm... I am not sure I understand. It is common to document your project/workflow/... in the same tree as the sources (or at least having a pointer to somewhere from there).
I think the vger server was an older one, managed differently, and perhaps it has something to do with that. But, yeah, the document is quite old so perhaps it can be updated or archived.
Yes, the kernel uses a mailing list workflow, for better or worse. |
|
$ cd rust
$ make check
make: *** No rule to make target 'check'. Stop.
$ make help
make: *** No rule to make target 'help'. Stop. |
I am aware -- I said |
T-libs-api has consensus for stabilizing some of
feature(new_uninit), but not forBox<MaybeUninit<T>>::write. The replacement is trivial, so let's just do that, and RfL can simply move off the feature after it is stabilized. That will happen immediately after this unblocks Rust CI, as the relevant FCP has completed:rust-lang/rust#63291 (comment)
This is required in advance of the stabilization because any remaining unstable API will be carved up into subfeatures as a direct result of stabilizing the majority of it. This code doesn't know about those yet. It can't, as they haven't landed, as building this code blocks Rust's CI but the expected-to-be-stabilized API can't be stabilized as long as this code requires that feature.