--- # System prepended metadata title: Libs Meeting 2026-06-03 tags: [Minutes, Libs Meetings] --- # Libs Meeting 2026-06-03 ###### tags: `Libs Meetings` `Minutes` **Meeting Link**: https://meet.jit.si/rust-libs-meeting-ujepnbwg2lzqgt6wvrndwimi **Attendees**: Nia Deckers, Amanieu, The 8472, thomcc, Urgau, Chris Denton, Josh Stone, Nurzhan Saken, bendn, clarfonthey, qj ## Agenda - Triage - Anything else? ## Triage ### FCPs 7 rust-lang/rust T-libs FCPs - merge rust.tf/155750 *Document that \`ManuallyDrop\`'s \`Box\` interaction has been fixed* - (3 checkboxes left) - merge rust.tf/155697 *Stabilize c\-variadic function definitions* - (6 checkboxes left) - merge rust.tf/155739 *Add temporary scope to assert\_eq and assert\_ne* - (3 checkboxes left) - merge rust.tf/155421 *Document panic in \`RangeInclusive::from(legacy::RangeInclusive)\`* - (3 checkboxes left) - merge rust.tf/132484 *unix: Relax escaping in \`Debug\` impl on \`Command\`* - (0 checkboxes left) - merge rust.tf/149648 *Mark const SIMD intrinsics as indirectly stable* - (4 checkboxes left) - merge rust.tf/134021 *Implement \`IntoIterator\` for \`\[&\[mut\]\] Box\<\[T; N\], A\>\`* - (3 checkboxes left) 1 rust-lang/rust-forge T-libs FCPs - merge github.com/rust-lang/rust-forge/issues/1040 *Add an LLM policy for \`rust\-lang/rust\`* - (6 checkboxes left) [nagisa (1)](https://rfcbot.rs/fcp/nagisa), [traviscross (1)](https://rfcbot.rs/fcp/traviscross), [the8472 (5)](https://rfcbot.rs/fcp/the8472), [saethlin (1)](https://rfcbot.rs/fcp/saethlin), [digama0 (1)](https://rfcbot.rs/fcp/digama0), [nikomatsakis (1)](https://rfcbot.rs/fcp/nikomatsakis), [BoxyUwU (1)](https://rfcbot.rs/fcp/BoxyUwU), [Amanieu (3)](https://rfcbot.rs/fcp/Amanieu), [CAD97 (1)](https://rfcbot.rs/fcp/CAD97), [joshtriplett (3)](https://rfcbot.rs/fcp/joshtriplett), [scottmcm (3)](https://rfcbot.rs/fcp/scottmcm), [tmandry (2)](https://rfcbot.rs/fcp/tmandry), [BurntSushi (2)](https://rfcbot.rs/fcp/BurntSushi), [joshlf (1)](https://rfcbot.rs/fcp/joshlf), [dtolnay (1)](https://rfcbot.rs/fcp/dtolnay), [spastorino (1)](https://rfcbot.rs/fcp/spastorino) ### (Prioritization Requested) rust.tf/157363 *1.97 beta regression due to \`TryFromIntError\` changing size* Nia (pre-meeting): I couldn't find any acknowledgement of this possibly causing a regression in [the PR that caused this](https://github.com/rust-lang/rust/pull/153178), so we may want to decide if this actually constitutes acceptable breakage or not. ### (Nominated) rust.tf/154715 *split try trait in twain* Nia: Got nominated on "do we want this or wait for bigger refactor of Try?". There's been talk about refactoring it with GATs. I'd say... The 8472: Is this not an API quesiton? Amanieu: Should be discussed with scottmcm, but he hasn't been active in Try discussions lately. Nia: Need to ping him. Amanieu: Has been pinged and hasn't responded. Nia: Is there ?? for next libs API meeting? Josh S: There's #lang/try on Zulip, maybe worth raising there. Nia: Good to know. Happy to drop the PR link there. Josh S: For our part, it's an API question. Nia: I'll nominate for libs-api and we'll discuss next Tuesday. ### (Nominated) rust.tf/155816 *Libs proposal: Policy for constifying traits and trait implementations* Nia (pre-meeting): We [responded](https://github.com/rust-lang/rust/issues/155816#issuecomment-4557372840) last week, but some of us were not here. Do we have more to say or should we unnominate? Nia: We said the policy looks good, but it'd be useful if the people who weren't here last time spoke out. Josh S: ~~Already checked my box.~~ Haven't checked it yet. Nia: I'll unnominate this and wait for their final answer. The 8472: Is it our responsibility? I see the lang-radar... Should we approve it? Nia: We've approved it with the caveats (pinging wg-const-eval)... The 8472: If it's about PRs, then we should also notify our reviewer channel. Nia: Happy to do that. I assumed... but happy to do it as libs instead. Not sure what the process is, as it's just a process proposal. The 8472: We could update our libs documentation, but in principle this is like an unstable feature, so hopefully resolves in a year (stabilizing const stuff). Nia: Ok, I'll drop the link to the zulip reviewer stream for now, tell the author to (what's the right place for this, the dev guide?) The 8472: Yes. Nia: I'll reply with that. Thank you for bringing it up. (More people joined.) ### (Nominated) rust.tf/156496 *Redesigned \`Components\` iterator to use front and back indexing instead mutating and subslicing path field* Nia (pre-meeting): See [this comment from last week](https://rust-lang.zulipchat.com/#narrow/channel/259402-t-libs.2Fmeetings/topic/Meeting.202026-05-27/near/598143659) for context. Nia: The author replied. They clarified on Zulip: yes, it's a perf thing that's relevant for some stuff they want for Ancestors that we approved a couple months back. Based on that, I'd say +1 from us. For the case of moving forward it's probably fine. The 8472: 10% slower is not insignificant... Is cargo part of our... in previous times we optimized path stuff... clarfonthey: I intended to show up last week for this... Part of this is related to using paths in a btreemap, and about 80% of the program's runtime was in path comparisons. I think this person saw my issue and wanted to improve that. There may be potential API solutions to solve this. The main issue with Components is that the prefix logic is basically the entirety of the logic... The 8472: Oh, you're on Windows? clarfonthey: The Windows logic needs to be done on every program The 8472: I thought we disabled it for non-Windows clarfonthey: No, that's the reason it's so bad. The 8472: I thought I added some check that's supposed to be false on Linux... but maybe that's the wrong place I'm thinking of. clarfonthey: The main issue is that even if we do have differences between slashes, this is the only difference between the path impls betweeen the platforms. The Components iterator is accounting for Windows-specific prefixes every time. The prefix parsing could be optimized out of the logic. The 8472: This should lead to early bailout on non-Windows: https://github.com/rust-lang/rust/blob/042c759f774872cf2f94c6685ce87e24c046c722/library/std/src/path.rs#L953. I think I used it in a few other places too. https://github.com/rust-lang/rust/blob/042c759f774872cf2f94c6685ce87e24c046c722/library/std/src/path.rs#L671 clarfonthey: I think that path is not always being followed. I'll check it more. As it stands, it's not just about optimizing the Windows path on UNIX. The 8472: Maybe I missed something that's relevant to your use case, or maybe you were benchmarking with ?? such that it doesn't optimize well. clarfonthey: I used release mode, so should have been fully optimized. Specifically, PartialOrd was slow. I think it parses the prefix before the bailout step. It may have also been that there's been an attempt to improve this, and future changes undid that? clarfonthey: Another thing, I've been thinking of an API proposal for relative path type which specifically optimizes the prefix logic regardless of platform. On every platform, it would just be a string with slashes everywhere The 8472: We have a wishlist for Path somewhere, maybe this could be added there. clarfonthey: Maybe I want to think about it in this PR. It'd make sense if we optimized it here. I agree that 10% or even 1% is not good when Paths are used everywhere. The 8472: Cargo does a lot of Path processing... Chris: We have ?? The 8472: Only the compile overhead, but I did runtime benchmarks. Josh: The perf-suite... Amanieu: It specifically measures rustc time. Josh: We have several Path wishlists, but I don't know which is the canonical one. Would be good to consolidate them. Nia: For this PR, we could ask if it's possible to come up with benchmarks for cargo to see if it's affected. If not, I'd accept the 10% slowdown compared to the wins it gives elsewhere. The 8472: What was the use case? Nia: Ancestors. clarfonthey: Components and Ancestors are the same logic, just in a different way. They're both trying to find bounds of components, it's just what path they're returning at the end. The 8472: Yeah, but is it for regular use of ancestors or the proposed change for ancestors? Would it regress for everyone except the new API users? clarfonthey: I think we shouldn't accept a change that would cause regressions, ?? clarfonthey: We can make solid improvements to this without causing regressions. There's something we can do. Nia: I'll defer to your knowledge. If you're confident that this can be done without significant slowdowns, let's say to wait until there's a design that does so. clarfonthey: There were also some weird optimization issues the author ran into. Maybe something small needs to be fixed to improve it. The 8472: They optimized pretty hard to... look at the inner loop that does component matching. Nia: Seems like this needs more review, let's move on. ### (Nominated) rust.tf/157170 *Use \`impl\` restrictions in \`std\`, \`core\`* Nia: This is to replace sealed trait. Do we want to do this? Josh: Looks like an impl matter because none of the sealed traits are public. It's a matter of "do we want to replace sealed traits with restrictions, which will be stabilized at some point?". ~~The primary concern is the lack of rustdoc support.~~ Oh, rustdoc just merged the support. Nia: Then it seems like a trivial +1, unless more concerns. The 8472: Nia: I don't think it's a stability guarantee... The 8472: Not stability, just internal use. Would it break if used across crate boundaries? Nia: AFAIK, it should be ok to switch back to sealed traits if we need to cross crate boundaries. I'll respond with +1? Josh: Sounds good. Will start a libs thread for support of coherence domains. ### (Regressions) rust.tf/139730 `P-high` *A case of compound x86\_64 performance regression caused by LLVM 20 and #124810* ### (Regressions) rust.tf/53340 `P-low` *Performance regression in tight loop since rust 1.25* ### (Regressions) rust.tf/119560 `P-low` *\`cargo test\` performance regression on Windows on version 1.75.0* ### (Regressions) rust.tf/124216 `P-medium` *Performance regression: rustc failed to optimize specific x86\-64 SIMD intrinsics after 1.75.0* ### (Regressions) rust.tf/130320 `P-medium` *stdlib code size increase in nightly\-2024\-09\-01 for aarch64\-linux\-android* ### (Regressions) rust.tf/142119 `P-medium` *Linking a Rust staticlib unexpectedly changes C math functions from libm to bundled ones from compiler\-builtins* ### (Regressions) rust.tf/142345 `P-low` *\`pin!()\` macro no longer constant\-promotes \`&mut\` references to empty arrays* ### (Regressions) rust.tf/145424 *rustc output no longer reproducible if it crashes* ### (Regressions) rust.tf/149752 `P-high` *TrivialClone is not derived for generic types (Performance regression)* ### (Regressions) rust.tf/152942 *Query depth limit overflow due to nested async fn when building matrix\_sdk* ### (Regressions) rust.tf/153425 `P-medium` *\`&pin!()\` stopped being deref\-coerced in rust 1.88* ## 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)_