Try   HackMD

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), BurntSushi (9), dtolnay (1), m-ou-se (7), nikomatsakis (2), jackh726 (1), Amanieu (5), joshtriplett (8), compiler-errors (1), thomcc (1), the8472 (1)

(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:

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
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