Libs Meeting 2023-07-12

**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.