# Libs Meeting 2023-08-02

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-ujepnbwg2lzqgt6wvrndwimi
**Attendees**: Amanieu, Thomcc, The 8472, Mara

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

1 rust-lang/rfcs T-libs FCPs

- merge rust.tf/rfc3455 *Create a Testing sub\-team* - (8 checkboxes left)

2 rust-lang/rust T-libs FCPs

- merge rust.tf/104385 *Raise minimum supported Apple OS versions* - (7 checkboxes left)
- merge rust.tf/100806 *Fix generic bound of \`str::SplitInclusive\`'s \`DoubleEndedIterator\` impl* - (4 checkboxes left)

[Amanieu (2)](https://rfcbot.rs/fcp/Amanieu), [cuviper (1)](https://rfcbot.rs/fcp/cuviper), [joshtriplett (2)](https://rfcbot.rs/fcp/joshtriplett), [m-ou-se (2)](https://rfcbot.rs/fcp/m-ou-se), [the8472 (1)](https://rfcbot.rs/fcp/the8472)

### (Nominated) rust.tf/109049 *split\_array: remove runtime panics*

Amanieu: Talked about this yesterday in the libs-api meeting.

Thomcc: The main issue is whether we can have post-monophize errors. Compiler team?

The 8472: Question of whether we can do this at all, and whether we can do this well. Currently they only happen at `build` time and not at `check` time.

Mara: Yesterday we concluded that a lint might be ideal, just like [] indexing.

The 8472: The lint would do a best-effort to determine the value at compile time, but otherwise it'd be a runtime panic.

Thomcc: yeah, that's probably fine.

Amanieu: Maybe we need a compile-time const warning rather than erroring assert.

Mara: But it shouldn't fire in an else branch that's not executed, like `if N == 0 { .. } else { thing<N>() }`.

Amanieu: I'm tending towards a general rule to do this with runtime panics.

The 8472: Then we go to a situation like Java "null pointer exception", where problems only appear at runtime.

The 8472: We lack the tools, we don't have static/constexpr if, etc.

Mara: yes, so basically we can't accept this PR, because it makes the 'if else' use case impossible. So today we don't have much of a choice.

Thomcc: I think panics are fine.

Mara: For [] we already panic without having a compile time typesystem thing to guarantee indexes are in bounds. Same situation here: runtime panic seems fine.

Mara: From the libs side there's nothing we can do today, so I don't think we have more to discuss on this today.

### (Nominated) rust.tf/112727 *Implement SpecFromElem for bool*

The 8472: I did something more generic a while ago, but that needed to be reverted. This is a more specific case just for bools.

Mara: PR seems fine?

The 8472: Scott says not necessary in release mode, and is asking if we still want to merge

Mara: Oh, in that case probably not.

The 8472: Maybe it can still be a benefit for release mode in the false/zero case?

Mara: If this doesn't have effect on release mode, why do we have the u8 and i8 specializations?

Amanieu: might be for compile times?

Amanieu: scott seems in favor of closing this

Amanieu: Seems fine to add this, as we already have it for u8 and i8

Mara: Yeah seems fine.

The 8472: Should it be a macro to avoid repretition?

Thomcc: For three probably not.

Mara: Agree.

Conclusion: this is okay.

Amanieu to reply.

### (Nominated) rust.tf/113435 *slice: avoid calling memcmp with size 0*

Amanieu: we have a similar issue with memcpy, in that the C standard says you must pass a valid pointer, and it's not clear what that means if the size is zero. in C passing a null ptr is UB. but C doesn't have zero sized types, so things are unclear.

Amanieu: for memcpy we use an llvm intrinsic that handles the zero case. for memcmp we use the libc function directly.

Mara: We could submit a proposal to the C committee to add the guarantee we need.

The 8472: Does this PR solve all our problems?

The 8472: Do a perf run?

Amanieu: I'd be against merging, even with no perf impact. It's not a real-world issue, only a theoretical one.

The 8472: So we want the C standard to change?

Amanieu: We can switch to an llvm intrinsic.

The 8472: Then we should document that for backends.

{some discussion on actual memcmp implementations}

Conclusion: we don't want the N==0 check, but using a memcmp intrinsic could work. not changing anything also seems fime.

Amanieu to reply.

### (Waiting on team) rust.tf/110708 *Consider documenting that (parts of?) stdlib must not be used before/after main*

Skip for today.

### (Waiting on team) rust.tf/111071 *Cleaner assert\_eq! & assert\_ne! panic messages*

Mara: The new panic message PR has been merged :tada:, so now this PR is unblocked. The comment on https://github.com/rust-lang/rust/pull/111071 has been updated to reflect the current state.

Mara: I thought this also removed the backtics.

Amanieu: No, this keeps the back tics.

Amanieu: What happened to the idea of showing the stringify!() of both sides?

Mara: Too much of a perf impact.

The 8472: Could we do that in debug builds only? Tests mostly run in debug mode, and there it'd be most useful.

Amanieu: Debug builds are the ones where you care about compile times though.

Mara: This PR is just a first step. It could be a step after this to explore the stringify!() thing.

The 8472: I dislike the old message. The new one seems fime.

Mara: I think we shoud remove the backticks on the `left:` and `right:` lines.

Amanieu: Yeah.

The 8472: Would that be a problem for mult-line.. strings?

Mara: No, those whould get quotes with the {:?} printing.

Conclusion: Fine. And remove the backtics around the values.

Mara to reply.

Probably best if the panic message change and this land on stable at the same time.

### (Needs decision) rust.tf/93415 *Named format arguments can be used as positional*

Amanieu: I thought this wasn't allowed.

Mara: It's allowed, but we warn for this. But now the question is if we want to make this an error in a new edition.

Amanieu: Seems fine if it stays a warning.

Mara: Making this an error in a new edition doesn't make things simpler, because we still need to support all other editions.

Amanieu: Yeah i'm against the change.

Amanieu: Why is this libs?

Mara: Because format_args!() is in core/std.

The 8472: Libs-api?

Mara: How about a libs-api rfcbot close?

Amanieu: Sure.

Mara to fcp-close.

### (Regressions) rust.tf/53340 *Performance regression in tight loop since rust 1.25*

### (Regressions) rust.tf/104092 `P-low` *Strange indentation in libtest output*

### (Regressions) rust.tf/112180 *assertion failed: key as usize != KEY\_SENTVAL in DragonFly BSD*

## Actions

- [ ] Reply to all issues/PRs discussed in this meeting, or add them to the [open action items](https://hackmd.io/Uehlc0qUQfWfvY1swYWRgQ).

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