---
# System prepended metadata

title: Libs-API Meeting 2025-05-27
tags: [Minutes, Libs Meetings]

---

# Libs-API Meeting 2025-05-27

###### tags: `Libs Meetings` `Minutes`

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Amanieu, Josh Triplett, Mara, David, Chris Denton, The 8472, TC, loudjanilef

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

  - merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
  - close rust.tf/140567 *Implement operations for Wrapping\<T\> where Rhs = T* - (3 checkboxes left)
  - merge rust.tf/141574 *impl \`Default\` for \`array::IntoIter\`* - (3 checkboxes left)
  - merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
  - merge rust.tf/137992 *Stabilise \`os\_string\_pathbuf\_leak\`* - (3 checkboxes left)
  - merge rust.tf/138016 *Added \`Clone\` implementation for \`ChunkBy\`* - (3 checkboxes left)
  - merge rust.tf/140881 *Tracking Issue for duration\_constructors\_lite* - (3 checkboxes left)
  - merge rust.tf/140005 *Set MSG\_NOSIGNAL for UnixStream* - (3 checkboxes left)
  - merge rust.tf/139087 *Fallback \`{float}\` to \`f32\` when \`f32: From\<{float}\>\` and add \`impl From\<f16\> for f32\`* - (6 checkboxes left)
  - merge rust.tf/129333 *Tracking Issue for \`lazy\_get\`* - (3 checkboxes left)
  - merge rust.tf/138879 *Ensure non\-empty buffers for large vectored I/O* - (4 checkboxes left)
  - merge rust.tf/135243 *Tracking Issue for nonnull\_provenance* - (3 checkboxes left)

[scottmcm (1)](https://rfcbot.rs/fcp/scottmcm), [BurntSushi (9)](https://rfcbot.rs/fcp/BurntSushi), [dtolnay (1)](https://rfcbot.rs/fcp/dtolnay), [m-ou-se (7)](https://rfcbot.rs/fcp/m-ou-se), [nikomatsakis (2)](https://rfcbot.rs/fcp/nikomatsakis), [jackh726 (1)](https://rfcbot.rs/fcp/jackh726), [Amanieu (5)](https://rfcbot.rs/fcp/Amanieu), [joshtriplett (8)](https://rfcbot.rs/fcp/joshtriplett), [compiler-errors (1)](https://rfcbot.rs/fcp/compiler-errors), [thomcc (1)](https://rfcbot.rs/fcp/thomcc), [the8472 (1)](https://rfcbot.rs/fcp/the8472)

### (nominated) rust.tf/libs466 *ACP: Add nul\-terminated version of \`core::panic::Location::file\`*

We previously rejected this.

Amanieu: After discussing at the all-hands, i think we should reconsider. I was the main person against this.

Amanieu: My main concern was that this'd be the start of a slippery slope towards more and more nul-terminated strings for C++ users.

Amanieu: But I think there's sufficient motivation for this.

David: Do they need a separate signature? Or just a guarantee that there's a nul byte after the slice?

Amanieu: Separate signature. I think that's strictly better.

Amanieu: From the LKML:

> But more importantly, this is really a Rust problem. Does Rust really 
> have no NUL-terminated strings? It should hide them in shame and 
> construct proper, robust strings, instead of spreading this disease to 
> the rest of the kernel, IMHO ...

Amanieu: anyway, should we have nul terminated file locations?

Mara: Fine with me. Doesn't really cost anything and seems useful in plenty of cases.

JoshT: :+1: The time for an argument in the kernel about whether to use NUL-terminated or length-prefixed is *after* a majority of the kernel is Rust, not when Rust is trying to get traction and mindshare.

Amanieu to reply and accept.

### (nominated) rust.tf/libs514 *Add \`Rwlock\` \`try\_upgrade\` method*

JoshT: Considering the response to our request, with no examples.. it seems like this should stay a third-party thing for now.

TC: What happened after it was approved and now?

Amanieu: We approved when we thought it could return a regular guard. But that doesn't work. At the time you acquire the initial read lock, you need to get a guard that is invariant instead of covariant. This blows up the API surface.

Mara: Sounds like something to experiment with in another crate first.

Amanieu: Maybe first add to parking_lot, then come back.

TC: What about 'try_upgrade' in parking_lot?

Amanieu: That's a very different one.

Amanieu: Let's first add it to parking_lot.

Amanieu to reply.

### (nominated) rust.tf/126041 *Tracking Issue for \`unsigned\_signed\_diff\`*

JoshT: for overflowing_signed_diff, when would it ever be useful to have the value when the bool is true?

Amanieu: saturating_signed_diff and overflowing_signed_diff don't appear in rustdoc..

Amanieu: Let me update the tracking issue.

TC: Since this is basically the integer version of `offset_from_unsigned` for pointers, should we align the name in any way?

Amanieu: No, these are just integers. 

Amanieu: I'll start FCP.

### (nominated) rust.tf/130994 *Tracking Issue for File lock API*

FCP finished. Should be merged?

JoshT: https://github.com/rust-lang/rust/pull/141312

Amanieu: removed label

### (nominated) rust.tf/133724 *Tracking Issue for \`breakpoint\` feature (\`core::arch::breakpoint\`)*

Nominating because people want to bikeshed the module (`arch`) and name (`breakpoint`).

JoshT: For core::arch, it'd be the only function directly in it. We ruled out core::process before, but that's still suggested now.

JoshT: any objections against core::arch?

Mara: seems fine, don't have strong opinions. object against core::process.

JoshT: Second, name `breakpoint`. might suggest it's an breakpoint that does nothing when no debugger attached, rather than something that always breaks/signals.

TC: That'd make more sense in core::hint.

Mara: Would it be bad if we ended up having both arch::breakpoint and hint::breakpoint?

JoshT: Not at all.

JoshT: hint::breakpoint would live in std. maybe call it breakpoint_if_debugging() or something.

TC: In that case, I'd expect it in core::hint, and have the debugger have support for that rather than std figuring out if there's a debugger.

Mara: The tracking issue discussion seems to mix up 'arch::breakpoint' and 'hint::breakpoint'. The first should just be an easy way to write the `bkpt` instruction or equivalent on whatever platform you're on. So that would should go in `arch` in any case.

TC: I buy that.

Mara: Regardless of what we put in any potential core::debug, I'd still want the instruction in core::arch.

Amanieu: Also `core::arch::trap`. Makes sense in core::arch.

The 8472: Does wasm have a breakpoint instruction?

Amanieu: It has 'trap'. breakpoint can fall back to trap.

Mara: In liballoc's Arc, we already use core::abort, even though it's not exposed yet. trap instruction.

The 8472: Couldn't we say that fallthrough is a valid implementation?

Mara: That's what happens if you continue from the debugger.

TC: If we say that fallthrough is a valid implementation, then could we make it a const function?

Mara: No. It's an architecture specific instruction. core::arch is just slightly higher level inline assembly. Maybe the hint could be const.

Amanieu: Clearly there is no debugger attached during const eval, so it could theoretically be.  But that may not be desirable.

Amanieu: Let's defer this till next week.

### (nominated) rust.tf/134813 *Tracking Issue for \`keylocker\_x86\`*

In FCP, unnominated.

### (nominated) rust.tf/137992 *Stabilise \`os\_string\_pathbuf\_leak\`*

In FCP, unnominated.

### (nominated) rust.tf/140816 *Static thread\_local! declarations are moved before Drop is called*

Mara: thread locals need fixing in many ways.

The 8472: Shouldn't unmovable things be pinned?

Amanieu: These are statics..

David: Can't we drop it in place?

Amanieu: That can be unsound. The destructor can access the thread local again.

Amanieu: This can probably be fixed. Probably doable.

Mara: Just be careful. This has gone wrong before. There's some comment somewhere with some warnings.

Mara: Let's fix it and keep it a few releases before guaranteeing.

### (nominated) rust.tf/141001 *Make NonZero\<char\> possible*

Amanieu: Interface of char and integers is different. So this makes the NonZero wrapper more complicated.

Amanieu: Actually, the integer methods are implemented directly on the specific `NonZero<u32>` etc types

Mara: PR feels incomplete. Doesn't add any methods for `NonZero<char>`..

The 8472: Motivation also feels incomplete.

David: `new` and a few others are implemented for all of `NonZero`.

Mara: Is that enough? Does that make for a complete enough initial api?

Amanieu: Yes. enough for just storing stuff.

Mara: Alright. Seems fine to me. Maybe some more motivation, but I'm easily convinced.

### (nominated) rust.tf/130703 *Tracking Issue for secure random data generation in \`std\`*

(Skipped.)

### (waiting on team) rust.tf/136687 *Improve the documentation of \`Display\` and \`FromStr\`, and their interactions*

### (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/140779 *Clarify upfront that \`PartialOrd\` is for strict partial orders*

Waiting on author.

### (new change proposal) rust.tf/libs592 *ACP: \`str::chunks\` with chunks being \`&str\`*

Counterproposal: `text.as_ascii().unwrap().chunks(N).map(<[AsciiChar]>::as_str)`

The 8472 to reply

### (new change proposal) rust.tf/libs591 *ACP: \`std::process::search\_paths\`*

We wanted the word "resolve" in the method name, and we wanted it to canonicalize the returned path.  Otherwise we were leaning toward happiness with it.

Chris is going to reword the ACP based on this feedback.

### (new change proposal) rust.tf/libs589 *\`ptr::fn\_code\_ptr\` for explicitly getting an opaque pointer of a function*

TC: We have a lang nomination that's similar to this in some ways:

https://github.com/rust-lang/rust/issues/140803

The 8472: In terms of the guarantees made by the trait in this ACP, we'd want to ask lang.

The 8472: In terms of the CFI discussion, any outcome of that discussion would also be relevant here, in terms of how this would interact with CFI.

TC: In terms of extern types, t-types is FCPing the part of the impl of hierarchy of sized types needed to unblock this:

https://github.com/rust-lang/rust/pull/137944

---

We're discussing Amanieu's proposal for this here:

https://github.com/rust-lang/libs-team/issues/589#issuecomment-2895919811

TC: This seems like generally the right shape to me.

Amanieu: One question is whether we'd ever want to support function pointers of different size than data pointers.

TC: Does CHERI need anything like that?

Amanieu: No; they have pointers that are differently sized than `usize`, but the function and data pointers are the same size.

### (new change proposal) rust.tf/libs587 *ACP: \`try\_exact\_div\` method on \`NonZero\<{integer}\>\`*

### (new change proposal) rust.tf/libs586 *ACP: std::cell::{Ref,RefMut}::try\_map*

### (new change proposal) rust.tf/libs585 *ACP: efficient runtime checking of multiple target features*

### (new change proposal) rust.tf/libs584 *\`From\<PipeReader\> for File\` and \`From\<PipeWriter\> for File\`*

### (new change proposal) rust.tf/libs583 *\`Vec::into\_chunks\` to reverse \`Vec::into\_flattened\`*

### (new change proposal) rust.tf/libs580 *ACP: \`ManuallyDrop\<T\>::pinned\_\*\` methods*

### (new change proposal) rust.tf/libs579 *ACP: \`Vec::push\_mut\` and \`Vec::insert\_mut\`*


### (stalled change proposal) rust.tf/libs371 *ACP: primitive numeric traits*

### (stalled change proposal) rust.tf/libs194 *Fix:Introduce an interface to expose the current \`Command\` captured env var logic*

### (stalled change proposal) rust.tf/libs455 *slice::Windows::as\_slice*

### (stalled change proposal) rust.tf/libs202 *Support for non\-blocking and best\-effort zero\-copy \`io::copy\`*

### (stalled change proposal) rust.tf/libs124 *Integrate \`Error\` trait with panic interfaces*

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

### (stalled change proposal) rust.tf/libs336 *Add \`or\_try\_\*\` variants for HashMap and BTreeMap Entry APIs*

### (stalled change proposal) rust.tf/libs453 *Signed↔Unsigned integer methods*

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

### (stalled change proposal) rust.tf/libs348 *std::os::unix::env::{argc, argv}*


_Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_
