---
# System prepended metadata

title: Libs Meeting 2023-07-12
tags: [Minutes, Libs Meetings]

---


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

## Agenda

- Triage
- Go through all new/old issues?
- Anything else?

## Triage

### FCPs

1 rust-lang/rust T-libs FCPs

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


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

Conclusion from earlier discussion is that nearly everything works (and should work) before and after main. The main problem is thread local storage.

The 8472: What about callbacks into user code that can run after main? E.g. a panic hook?

Mara: We only need to document which parts of std don't work before/after main. don't think this falls under that.

Amanieu: I think we should just document which things depend on TLS not being destructed, and that's it.

Josh: Is there any way we can make it more robust, so that parts of the standard library that depend on TLS still work after main?

Amanieu: Before main is not a problem. Only after is an issue.

Mara: We could simply never destruct the TLS for the main thread. The same happens on wasm. And the same for `static`s etc.

Mara: We can also make thread::current() work after TLS destruction on some platforms by making use of #[thread_local]'s that don't need to be dropped. (Just for robustness. Doesn't solve the issue on all platforms.)

The 8472: The 'fix fd 0-1-2' function in std's runtime might not have run in code before main().

Mara: But we don't guarantee that we run that function anyway, so there's nothing to document about not running it.

Josh: If we do document that in the future, we can document when it runs and that user code might be able to run before it.

Amanieu: Is this issue actionable?

Mara: David was asking whether e.g. Cell or some other parts of std can be guaranteed to work before/after main, and I think the answer is yes: everything can be used before/after main, except TLS related stuff might panic.

Amanieu: Sounds good.

Amanieu to reply.

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

Blocked on https://github.com/rust-lang/rust/pull/112849, which is now ready for review.

Still needs team decision on the assert_eq message. Let's defer until after 112849 is merged.


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

Nothing actionable for us.

### (Regressions) rust.tf/113283 *Type annotations needed in assertion*

The revert was labeled 'temporary fix' but that seems more like a permanent fix.

Closed.

## Going through all new issues

https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3AT-libs+-label%3AC-tracking-issue

Mara: Maybe label these all as low/medium/high/critical priority?

Amanieu: We specifically need to look for issues that need input from the team.

Mara: Right. Agreed.

Mara: The compiler team has a traige (sub)team, right? Can they help us out?

The 8472: For everything that is critical, someone probably has already pinged us about it.

Mara: I'm worried that might not be the case.

Mara: I'd like to get to a point where we can go through newly filed issues every week. But right now there are 141 open issues, many of which we have never seen.

{discussion on how to use github labels}

Maybe we can look at all issues that do not have a P-* label yet.

Mara: Isn't there a bot that can add 'needs-prioritization' to those automatically?

Josh: It might be useful to post a standard comment to the issues to clarify we won't see updates unless they nominate the issue. (Perhaps put that text somewhere like the libs repo and link to it?)

Mara: Maybe all issues either need an assignee or E-help-wanted.

Josh: Makes sense

Mara: Some issues might be waiting for a decision on whether an issue is actually a bug. Like an 'unconfirmed' label on most trackers.

Josh: Alternatively, a 'confirmed' label.

The 8472: Let's go through some issues to see what their state is and find out what categorization makes sense.

Mara: Doesn't the compiler team have a 'confirmed' status for their issues?

Josh: We should invite someone from the compiler team.

Mara: Yeah, or just ask on their zulip stream.

### #80836 VecDeque is_empty and get(0) together generate unreachable panic. 

The 8472: Probably fixed by now.

Mara: So we also need a 'might be fixed someone please verify' state?

The 8472: That's just putting it back to the 'unconfirmed' state.

Mara: Not entirely, because the original 'unconfirmed' means we (team) need to check it, while this new 'unconfirmed' state is for someone else to go check it.

Chris (on GitHub): Does this need a test to guard against regression?

Mara: Oh, that's yet another state for an issue.

Chris: There is a E-needs-test label already.

Mara: I'd be interested in making an overview of the states an issue can be in (unconfirmed, confirmed, needs-verification?, etc.) and checking that with the compiler team. Then we can use that next time.

Mara: So, two action items:

- Add newly filed issues to the agenda
- Have labels for all states an issue can be in, and put those without any of those labels on the agenda.

Mara to start a Zulip topic in T-compiler about labels.

### #108409 File from Path with Windows' invalid characters silently fails

The 8472: What's the state of this issue?

Chris: Hard to fix. Probably libs-api.

Seems to be part of https://github.com/rust-lang/rust/issues/107276

Josh: Close as duplicate of https://github.com/rust-lang/rust/issues/107276 ?

Yes.

