Libs-API Meeting 2025-07-29

tags: Libs Meetings Minutes

Meeting Link: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
Attendees: Amanieu, The 8472, Josh, Tomas Sedovic, David, Martin, TC

Agenda

• Triage
• Anything else?

Project goals

https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/2025H2.20Goal.20Review/with/530407783

C++ Rust interop problem space mapping

Amanieu: We're asked to review problem statement.

David: I reviewed drafts for this a few months ago.

Amanieu: This is just proposing a problem statement, no concrete proposals yet.

David: I can be the champion for this one.

SVE and SME on AArch64

Amanieu: I have experience with this, happy to champion this.

Josh: I'm happy to help for the lang side. The biggest blocker is about how difficult it is to introduce the auto traits.

TC: It's also the ??

Amanieu: I'm happy to help with the stdarch part of this.

build-std

Amanieu: Mainly review RFC draft and decide to approve the RFC. My understanding is most of thework is on the cargo side.

The 8472: I think they're proposing to not introduce any stable changes to the standard library.

Amanieu: I'm happy to champion this on the lib side but there's not much to it.

Reflection and Comptime

Josh: We generally had lang items be not libs things. So we don't anticipate this not having actual libs asks. We may want to respond with us not anticipating any libs asks.

The 8472: And re experiments any addition would be unstable.

Josh: Yes, this only proposes experiments so nothing stable.

Evolving trait hierarchies

Amanieu: This adds Receiver as a super trait of Deref?

TC: This is mostly Lang.

Amanieu: Yes. The libs API is mostly related to the Receiver trait.

TC: If libs api is happy with e.g. what module we put it in, then it's mostly lang.

Amanieu: There's still the stabilization but yeah.

TC: Basically we're just splitting up the Deref trait. We need that to support arbitrary self types. So we need to break apart the Deref trait and for that we need lang features to allow us to do that backwards-compatibly.

The 8472: Where will we dogfood this unstable implementation?

TC: It's going to be a lang experiment.

The 8472: The libs ask is stabilization. So someone will have to use the Receiver trait, design APIs around this etc.

TC: There's no material API surface.

The 8472: Who tests this in a real deployment.

TC: The compiler, I think. The Rust for Linux folks as well, as I recall.

Amanieu: Do we need a champion? If it's just asking for a stabilization decision, that's just a libs-api FCP.

TC: I'd volunteer Amanieu in his role as a lang advisor to provide the crossover.

Amanieu: I have been volunteered.

Finish the libtest json output experiment

Amanieu: I've set this in the past but my personal preference is to fully delegate everything relatedto libtest to the desting devex team. It's very separate from the standard library and doesnt' seem it should be under our umbrella.

Josh: +1

Amanieu: Someone want to champion this and give them blank cheque?

Amanieu: How do we feel about delegating this entirely to libtest? It's a commandline argument to test binaries where the parsing of the argument is in libtest. I think maybe it was Mara who had reservations over delegating over to libtest?

Amanieu: I'll take it and see what happens next week.

Triage

FCPs

24 rust-lang/rust T-libs-api FCPs

• merge rust.tf/80437 Tracking Issue for `box_into_inner` - (1 checkboxes left)
• merge rust.tf/140808 Implement Default for &Option - (3 checkboxes left)
• merge rust.tf/133289 Tracking Issue for `const_array_each_ref` - (3 checkboxes left)
• merge rust.tf/143191 Stabilize `rwlock_downgrade` library feature - (3 checkboxes left)
• merge rust.tf/106418 Implement `PartialOrd` and `Ord` for `Discriminant` - (2 checkboxes left)
• merge rust.tf/65816 Tracking issue for `vec_into_raw_parts` - (3 checkboxes left)
• merge rust.tf/132968 Tracking Issue for `NonZero<u*>::div_ceil` - (3 checkboxes left)
• merge rust.tf/139087 Fallback `{float}` to `f32` when `f32: From<{float}>` and add `impl From<f16> for f32` - (5 checkboxes left)
• merge rust.tf/129333 Tracking Issue for `lazy_get` - (3 checkboxes left)
• merge rust.tf/127213 Tracking Issue for AVX512_FP16 intrinsics - (3 checkboxes left)
• merge rust.tf/136306 Tracking Issue for NEON fp16 intrinsics - (3 checkboxes left)
• merge rust.tf/141520 Tracking Issue for const {OsString, PathBuf}::new - (3 checkboxes left)
• merge rust.tf/70530 Tracking Issue for {BTreeMap,BTreeSet}::extract_if - (3 checkboxes left)
• merge rust.tf/141994 add Iterator::contains - (3 checkboxes left)
• merge rust.tf/141744 Stabilize `ip_from` - (3 checkboxes left)
• merge rust.tf/140956 `impl PartialEq<{str,String}> for {Path,PathBuf}` - (3 checkboxes left)
• merge rust.tf/143717 Add `Default` impls for `Pin`ned `Box`, `Rc`, `Arc` - (3 checkboxes left)
• merge rust.tf/125964 Tracking Issue for `core::iter::chain` - (3 checkboxes left)
• merge rust.tf/126695 Tracking Issue for `array::repeat` - (3 checkboxes left)
• merge rust.tf/144054 Stabilize as_array_of_cells - (3 checkboxes left)
• merge rust.tf/99108 Tracking Issue for arithmetic and certain bitwise ops on `AtomicPtr` - (3 checkboxes left)
• merge rust.tf/144091 Stabilize `new_zeroed_alloc` - (3 checkboxes left)
• merge rust.tf/144275 implement Sum and Product for Saturating(u*) - (3 checkboxes left)
• merge rust.tf/63569 * Tracking issue for `#![feature(maybe_uninit_slice)]`* - (3 checkboxes left)

Amanieu (2), scottmcm (1), nikomatsakis (2), m-ou-se (22), dtolnay (1), jackh726 (1), joshtriplett (20), BurntSushi (22)

(nominated) rust.tf/93743 Tracking Issue for str::{floor, ceil}_char_boundary

Amanieu: This is a request for stabilization.

The 8472: There's an unresolved question there.

Amanieu: "Should ceil_char_boundary panic when indices are out of bounds?"

The 8472: There's a PR that sets this to return len instead.

The 8472: I think the methods are useful. I'd have a usecase for them. I'd like to have them.

Amanieu: Do you think they're fine as they are? Are you happy to start an FCP?

The 8472: I don't think I have the permissions.

Amanieu: Ah, you're on libs not libs-api.

TC: I nominate The 8472 for libs-api.

Josh: I second it.

Amanieu: I'll nominate this for FCP.

(nominated) rust.tf/99108 Tracking Issue for arithmetic and certain bitwise ops on `AtomicPtr`

Discussed last week, nominated.

(nominated) rust.tf/144037 Rename bool::ok_or[_else] to bool::then_ok_or[_else] to avoid confusion with Option::ok_or[_else]

Amanieu: Discussed last week.

TC: I still don't want to do the rename (ref: https://github.com/rust-lang/rust/issues/142748#issuecomment-3104242108). If we're going to start prefixing these with then_ I'd rather not have these methods at all and instead have a .opt() method to lift these into Option<()>.

Josh: I agree. I'd keep the methods' names as they are. Effectively any method on bool that takes a Self would essentially duplicate an existing method (e.g. should we call it not or then_false?).

Amanieu: I don't mind either. Whatever we choose, people will get used to it.

The 8472: I find the proposal to turn it to Option<()>.

Amanieu: The whole point of adding these was that turning it to an Option<()> was too verbose.

The 8472: But TC proposed a shorthand method for that.

Amanieu: If you look at the ACP the main concern is that no matter how short you make it it will always introduce a new line.

https://github.com/rust-lang/libs-team/issues/606

Josh: I'd find something like .opt more confusing.

The 8472: A bunch of people use one-liners and I guess rustfmt is to blame.

Josh: My argument is that .opt is confusing. I'd rather use an if. Do we have objections to ok_or_else? We're speculating about other methods? But does this particular method seems good enough?

The 8472: But that argument would work for any method in isolation.

Amanieu: The only unresolved question is whether we rename it to ok_or?

Josh: Is there anyone here who wants to rename the method?

The 8472: No.

Amanieu: I am, very slightly.

Josh: The only reason to having a method is if you find then_some too long.

Amanieu: Does someone want to start the rfcbot close on the PR?

Josh: I'll take care of it.

(nominated) rust.tf/144465 Allow the global allocator to use thread-local storage and std::current()

Amanieu: This changes the internals of thread-local to use the system allocator instead of the global allocator.

The 8472: Do we use the system allocator anywhere else?

Amanieu: pthreads probably uses it internally.

The 8472: I mean in std not some library. Im' mostly wondering how surprising it would be for people if we started using the system allocator more.

Amanieu: No, we don't use it anywhere.

The 8472: So all TLS values would no go into the system allocator, right? Could there be a fragmentation problem?

Amanieu: This is never going to be an issue in practice.

Amanieu: I'm inclined to accept.

The 8472: We're not making any new guarantees. But if we make the change people will depend on it in practice.

Josh: If we're making a change it's probably going to get used. Having an allocator being able to use thread local storage is really important for e.g. pools for memory per thread.

The 8472: If someone's going to use it, they're effectively asking for a guarantee. So we should make it more official. Making docs etc.

Josh: I would expect so, yeah.

The 8472: This PR doesn't do that so we should ask the author to add that documentation.

Josh: Sounds reasonable.

Amanieu: Shouldn't that be the default assumption? That stuff just works?

The 8472: If you're inside the allocator, there are some things you can't use: HashMap, Vec, etc.

The 8472: The stacktracing itself allocates. I think there are other issues.

Josh: I think we should change the team tags from T-libs to T-libs-api because this needs to be a guarantee. We should start an FCP on it and block it on missing docs.

Josh: I can write up a summary and start FCP if there's no objection.

Amanieu: The alternative is to call the global allocator.

Josh: I've seen hacks like this, but that's a mess.

Amanieu: Yeah, you may have to do that for nostd maybe.

The 8472: Don't our mutexes (the fallback) also use thread-local allocator?

Amanieu: I don't think we have the fallback anymore.

The 8472: Maybe for some niche platforms?

Amanieu: Yeah, we do.

The 8472: This is a fix for one thing that uses a global allocator, but there are others. Should we make a whitelist?

Amanieu: Shouldn't mutexes use the thread-local (??)-allocator?

The 8472: The author isn't asking for that. Im' just saying if you write an allocator and need locks inside, that's another pitfall.

Josh: I think we should document what you can and cannot do in the global allocator. But this is useful on its own. Having systematic guarantees on what will and won't allocate is useful and something we want, but it shouldn't block this FCP.

Amanieu: Thead-local is a particularly diffucilt one because you can't really work around that.

Josh: I've just posted a comment and started an FCP.

(nominated) rust.tf/144494 Partial-stabilize the basics from `bigint_helper_methods`

Amanieu: carrying_add, widening_mul and carrying_mul_add.

Josh: Those three seem pretty reasonable. They're only on unsigned.

Amanieu: carrying_mul_add seems like the more questionable one. Mainly because I've not seen many uses for it.

Josh: I'm curious to know. But I think this has something to do with FMA (fused multiply add) optimizations.

Josh: Apparently we don't have mul_add.

Amanieu: Why are we not stabiliznig the other methods (carrying_mul and borrowing_sub).

Josh: I'm assuming the reason we need some kind of carrying_mul or carrying_mul_add it's because it's the counterpoint to widening_mul. Is carrying_mul just carrying_mul_add without the add?

Amanieu: Yes.

The 8472: Are there CPUs with mull_add?

Amanieu: Yes, arm.

The 8472: Does the arm instruction do anything tricky?

Amanieu: Oh, carrying_mul_add doesn't actually overflow.

The 8482: Because it goes through an intrinsic? Or because it's a hand-rolled implementation.

Amanieu: It goes through

(nominated) rust.tf/144538 Tracking Issue for const_exposed_provenance

(waiting on team) rust.tf/116258 Tracking Issue for explicit-endian String::from_utf16

(waiting on team) rust.tf/139087 Fallback `{float}` to `f32` when `f32: From<{float}>` and add `impl From<f16> for f32`

(waiting on team) rust.tf/144330 document assumptions about `Clone` and `Eq` traits

(new change proposal) rust.tf/libs630 Add ASCII-related methods from `u8` and `MIN`/`MAX` to `core::ascii::Char`

(new change proposal) rust.tf/libs629 OnDrop: Simple Drop guard

(new change proposal) rust.tf/libs628 Implement some arithmetic operations for `std::arch` SIMD types

(new change proposal) rust.tf/libs627 ACP: `cast_init` method for pointers

(new change proposal) rust.tf/libs626 `Option::map_iter()` to create an iterator from `Option`

(new change proposal) rust.tf/libs624 ACP: Proper const `Deref` methods

(new change proposal) rust.tf/libs623 Pass file descriptors in std::comand::Command

(new change proposal) rust.tf/libs621 ACP: Add Waker::with_arc_wake

(new change proposal) rust.tf/libs619 slice::get_clamped

(new change proposal) rust.tf/libs618 ACP: Implement fmt::Binary for [u8] and friends

(stalled change proposal) rust.tf/libs483 `Box::new_from_ref` for making a `Box<T>` from a `&T` where `T: CloneToUninit + ?Sized` (and `Rc` and `Arc`)

(stalled change proposal) rust.tf/libs457 APC: split_pattern on slices

(stalled change proposal) rust.tf/libs262 Add infallible variant of RangeFrom::next()

(stalled change proposal) rust.tf/libs456 Add Option::todo and Result::todo

(stalled change proposal) rust.tf/libs347 Context reactor hook

(stalled change proposal) rust.tf/libs344 ACP: Add `std::string::String::replace_and_count` and/or `replace_with`

(stalled change proposal) rust.tf/libs287 ACP: Add `FromByteStr` trait with blanket impl `FromStr`

(stalled change proposal) rust.tf/libs296 ACP: Designing an alternative `FromStr`

(stalled change proposal) rust.tf/libs261 add `write_fmt` method to String, to make `write!` macro work without imports

(stalled change proposal) rust.tf/libs133 Add fmt::Write to io::Write adapter

Generated by fully-automatic-rust-libs-team-triage-meeting-agenda-generator