# Libs Meeting 2023-06-07

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

1 rust-lang/rust T-libs FCPs

- merge rust.tf/104385 *Raise minimum supported Apple OS versions* - (9 checkboxes left)

### (Backports) rust.tf/112292 *Avoid unwind across \`extern "C"\` in \`thread\_local::fast\_local\`*

This 'technically UB' doesn't really result in actual issues, it seems.

Not a recent regression, so might not be a good backport candidate.

Left a comment.

### (Nominated) rust.tf/84187 *Tracking Issue for restructuring \`sys\_common\`*

Discussed last time. Still need to respond. Mara to respond.

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

Discussed last time. Amanieu replied, saying the main issue is thread::current(), which is only used in a few places.

For LocalKey::with we already document it: https://doc.rust-lang.org/stable/std/thread/struct.LocalKey.html#method.with
(And also have a try_with.)

Only for thread::current() (and a few APIs that use that) we don't provide any panic docs (or a try_current() etc.).

Pre-main seems like it's rarely a problem, it's post-main that is more interesting.

### (Nominated) rust.tf/111071 *assert\_eq! message format (take 2a)*

Summary: https://github.com/rust-lang/rust/pull/111071#issuecomment-1576734594

Question 1: Change the default panic handler output format?

Possible answers:

1. No
2. Yes, as proposed, but only for multi-line messages
3. Yes, as proposed, but for all messages

3 seems like a nice option, because the current "at {message}, {location}" feels flipped/swapped.

Crater run could check how widely people depend on the exact output.

We can do an FCP to make it show up in TWiR.

Split this into a separate PR to focus first on just the panic_handler output, independent from assert_eq.

Question 2: Change the panic message of assert_eq?

- Put the message on a separate line?
- Call it "error" or "message" or "description" or ... ?
- Put message on the first line?

assertion failed: `left == right`
 error: message goes here
  left: `1`
 right: `2`

assertion failed: `left == right`, message goes here
  left: `1`
 right: `2`

assertion failed: message goes here
 check: left == right
  left: 1
 right: 2

Leave this for after the PR for question 1.

### (Waiting on team) rust.tf/103126 *Add cfg(no\_128\_bit) to core: removes u128/i128 formatting*

Discussed and responded last time. FCP close in progress. Removed label.

### (Regressions) rust.tf/109064 `P-high` *\`+outline\-atomics\` violates "core shall not depend on libc"*

Resolutions: Either:

- remove outline-atomics, or
- allow core to depend on libc.

The 'can core depend on libc' discussion is a complicated one, probably needs an RFC for a resolution.

Amanieu to write up that RFC.

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

Might have already been broken but simply not resulted in a panic.

Tier 3, so not high priority.