From 1defb07c36845e5d9eae6506eee1c96fcaadb613 Mon Sep 17 00:00:00 2001 From: Tomas Sedovic Date: Tue, 13 Oct 2026 19:03:36 +0200 Subject: [PATCH] Add 2026-10-13 meeting minutes --- minutes/2026-10-13.md | 690 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 690 insertions(+) create mode 100644 minutes/2026-10-13.md diff --git a/minutes/2026-10-13.md b/minutes/2026-10-13.md new file mode 100644 index 0000000..98ab705 --- /dev/null +++ b/minutes/2026-10-13.md @@ -0,0 +1,690 @@ +# Libs Meeting 2026-10-13 + +###### tags: `Libs Meetings` `Minutes` + +**Meeting Link**: https://meet.jit.si/the-libs-agenda +**Meeting Link 2**: https://meet.jit.si/the-libs-agenda-2 +**Attendees**: Nia, Amanieu, The 8472, Chris, thomcc, Clar Fon, Josh (Triplett | Stone) + +## Agenda + +- Nominated items +- Regressions +- FCPs (optional) +- ACPs (optional) +- Anything else? + + +## Triage + + +### Backports + +#### [#161253](https://rust.tf/161253) Implement `AsMut` and `AsRef` for `!`. + +Nia: Poll in favour, crater says 0 regressions. Any opposition to it? + +The room: ship it + +### Prioritization Requested + +#### [#164141](https://rust.tf/164141) 1.100 beta crater regression: Behavior change with `#[derive(Ord)]` and manual `impl PartialOrd` + +Fon: This is bad. I don't think this is doing something we should support, but it's changed behaviour. The reproducer reverses the ordering in PartialOrd and then derives Ord. We generally derive Ord to not be just `partial_ord.unwrap()` + +Josh: Didn't we at some point made it so if you derive both we define `PartialOrd` in terms of `Ord` + +Fon: We tried that but failed at detecting that both of them were being derived. That may be reason for this regression + +The 8472: The reason linked in the issue is something about an Iterator change + +Nia: We do warn people againts doing this sort of thing. If you do a thing we specifically tell you not to do, there's more of a case to call it acceptable breakage + +Fon: The change from Iterator min/max (as pointed out here: https://github.com/rust-lang/rust/issues/164141#issuecomment-6109448633) doesn't seem like it should be + +Nia: The release notes spell out that this could impact types with inconsistent ord trait implementations. I assume that was FCPd. + +Fon: I feel this person is doing that incorrectly. + +Nia: The change was not actually FCPd. + +The 8472: It wasn't an API change. This isn't the only case of Iterator having multiple possible implementation strategies and typically when we change it, we don't FCP it + +Fon: If you look at the actual code linked: https://github.com/aprowe/equity-cli/blob/481a9d0d48d7fd651c1afa667cd3ce210b3ac30d/src/poker_hand.rs#L63 that seems related to derive macro changes not iterator changes: + +Nia: Should we mark this as High? + +Fon: I think it should be P-High until we find the exact commit. I don't believe it's the iterator change + +Nia: And then we look at it again. Is everyone on board? + +Chris: Is the issue itself P-High? This is broken code. + +Nia: It's a regression where we may have FCPd the thing that regressed. + +Amanieu: I think the conclusion here doesn't change though: this seems like acceptable breakage and we are unlikely to want to revert and make the old behavior a guarantee. + +The 8472: It's something that possibly didn't require FCP + +thomcc: I think this was already broken and the iterator change exposed that breakage + +The 8472: This is implementation flexibility, we don't guarantee which thing calls which thing + +Nia: From that perspective this is not a high priority + +Fon: And Clippy would warn you + +Josh: The fact that Clippy warns doesn't mean it's unequivocally wrong + +Nia: The docs are clear on this: + +> Because Ord implies a stronger ordering relationship than PartialOrd, and both Ord and PartialOrd must agree, you must choose how to implement Ord first. You can choose to derive it, or implement it manually. If you derive it, you should derive all four traits. If you implement it manually, you should manually implement all four traits, based on the implementation of Ord. + +Nia: Maybe we can make this a rustc lint rather than just a Clippy one. But this seals the deal for me that this is a completely acceptable thing to do. And in that case this is a wontfix + +The 8472: If the API contract of `Ord` and `PartialOrd` requires that they're consistent and the user doeesn't have a consistent implementation, this is an issu ewith the user's code + +Josh: I agree regarding the consistency part. But we did have the behaviour before that if you derived Ord and wrote a PartialOrd. Under that behaviour the code wasn't buggy. It was producing correct implementation of ord and PartialOrd that was correct. We then changed an implementation that caused their code to become inconsisntent + +thomcc: The code was already inconsistent. We changed the implementation of Iterator to use one of those, not the other. + +Josh: I see. In that case this is fine for us to break. How long ago did we make the change to `Ord`? If we did that last release and didn't make it loud. On top of that we should have a lint, not just a Clippy lint + +Fon: We could keep it open for investigation or close and open a separate issue + +Nia: But it seems not a particularly high priority thing -- they're doing something that's broken. + +Josh: I think it is relevant to find out whether we handled the change to `Ord` correctly. But we shouldn't try to prioritise this one. But we may want to make it louder. + +Nia: Agreed. I'll reply sayng that and close the issue + + + +#### [#164243](https://rust.tf/164243) double\-free in safe code using thread\-locals, when calling process::exit() + +Amanieu: We changed `process::exit` to run thread-local destructors in the current thread. But what if you call it inside the thread local with. Now you have an aliasing issue: you hold a reference to the content of the thread local while also mutating it + +Josh: This is effectively non-reentrant code? + +Amanieu: Yes + +Fon: Were we not running TLS destructors before? + +Amanieu: It was platform specific. Whether they're executed on `process::exit` varies. We tried to make it consistent at one point + +Josh: What is the rationale for calling those destructors on exit but not the other ones? + +Fon: From process::exit you can only be certain that the current thread will exit immediately + +Josh: I was asking why do we call it on the current thread instead of just dying? + +Nia: Do we call TLS destructors in other places? Is there a precedent? + +Josh: I recall us making the change at some point and I don't remember the rationale. Maybe we should evaluate it + +Nia: I agree. But we should also put this as P-High and whenever something comes up here, people should renominate it for libs + +Chris: Agreed, this needs asynchronous investigation + +Amanieu: Yes this seems like a P-High issue + + +### Mark: Council announcements + +* Seeking 2027 budget items - see https://rust-lang.zulipchat.com/#narrow/channel/546943-all.2Fprivate/topic/2027.20Leadership.20Council.20budget.20ideas +* T-funding charter will soon be in FCP - https://github.com/rust-lang/funding/pull/10 + +Mark: Council items I wanted to give visibility to. There's FCP for the Funding team's charter. Has implications for anyone wanting funding from them. Also starting process for 2027 budget asks. If you have thoughts, bring it up to me or write in the Zulip thread. + +The 8472: What about the Jitsi issue? + +Nia: I spoke to Jonathan and we're getting a Jitsi instance spun up locally after EuroRust + +Mark: That cost is probably gonig to be funded out of Infra pool rather than Council pool. + +Josh: Huge props to the Infra team to solving it for everybody. But it might be worth starting the conversation with Jitsi to see if there is a way to get support and if they have a paid service, asknig if they could donate that to us as an in-kind donation. + +Mark: If you or whomever on RustNL side want to touch base on infra, please do. This is not going to be a short-term kind of thing. + +Fon: We could have a "general announcements" section for things like this at the top of every meeting. + +### Nominated + +#### [#114544](https://rust.tf/114544) Tracking Issue for RISC\-V Ratified Extensions Intrinsics + +Nia: We spoke about this recently. + +Amanieu: There's C API that we should just use here + +https://github.com/riscv-non-isa/riscv-c-api-doc/blob/main/src/c-api.adoc#scalar-bit-manipulation-extension-intrinsics + +Josh: Is the C API limited so 32-bit can only call on 32-bit and + +Josh: If their approach is "you must write different code for RISC-V 32 and 64 completely separately" I'd like for us to abstract over that so we can write code that uses 32-bit on 32-bit and similar for 64 bit + +Amanieu: The 32-bit and 64-bit intrinsics have different names and different behaviours + +Josh: In that case let's just use those intrinsics and use u32 and u64 + +Nia: We're not precluding ourselves from offering an API, but right now we are just matching the intrinsics + +Amanieu: I don't think it's our job to provide an abstraction over this + +Fon: It does say the 32-bit version can be used in 64 bit just not the other way around + +Josh: Fair enough + +Nia: So u64 and u32 + +Amanieu: The answer is just to follow the spec and point at the spec document + +#### [#134645](https://rust.tf/134645) Tracking Issue for `sync_nonpoison` and `nonpoison_{condvar,mutex,rwlock}` + +Fon: I nominated this so we can talk about it. For the sake of the meeting, people talked about other issues for nonpoison mutexes. + +Nia: What do you think we can make progress on? + +Fon: We have blockers on the API. Are there any issues with the API? I say we resolve those. + +The 8472: That's for the RWlock. We could still stabilize mutex? + +Fon: It depends whether we want to stabil ?? + +Amanieu: ?? + +Josh: as in nonpoison can mean "don't track it" or "trakck it and auto-wrap it"? + +Amanieu: Yes + +Nia: Third opinion: if we refactor the mutex internals, we could have them not being different at all. Poison could be a bit on top of nonpoisoning mutex. BUt that would require mutex refactoring + +Josh: You wouldn't be the first person to do that. That sounds like a good plan. But I'd be sceptical of 0 overhead. We can zero the space overhead but not time + +Nia: I don't think we have a time overhead. Targets tat support unwinding would let us set is-poisoned bit in the mutex + +Amanieu: We also need to check whether we're unwinding when the guard is created. The guard uses TLS access. + +Nia: Right, but I'm not convinced we need a different type + +Josh: The other thing is people saying "I'm using a mutex, I don't want to poison ever, please just deadlock" + +Nia: This would be just unlock with/without ignoring poison + +Josh: There would still be an argument for a different type so they can drop to unlock rather than calling unlock. If we can provide a zero-overhead of tracking it, then there's no necessary reason to not track it. And then it's more a question of what interface you want to be for the underlying functionality and what the default should be. + +Fon: This feels like the `Arc` and `Rc` refactor. Somebody just needs to do it. We could say we're not stabilizing it, but that's probably the best path forward. Right now we're talking about a theoretical implementation + +Amanieu: I don't think this will work, but this meeting might not be the right place to discuss this + +The 8472: Josh talked about default, but if we put this on lock we can just have different methods and then there's really no default, you should just choose one of them + +Nia: That's what I was talking about. You could make different types for API reasons. But is there anything other than lock that would be different? + +Josh: Unless we're hard-committing this is 0 overhead on all platforms, is there a platform where it wouldn't be trivial to track with zero overhead. We'd have to go check all the tier-1 platforms + +Nia: FWIW Mara's convinced that it can be done. + +The 8472: How many spare bits would we have in the mutex? + +Nia: A lot. Poison is just one bit, and then we have the 2 bits for system mutex and UnsafeCell for the actual data + +Amanieu: But the storage for that 1 bit is not the issue. + +Nia: Yes, the problem is setting it. + +Nia: I unnominated the mutex issue. + +#### [#164197](https://rust.tf/164197) std: make `nonpoison::RwLockReadGuard` invariant + +Amanieu: My inclination is to not support it and keep the variance as it is today. + +Nia: I agree with Amanieu that variance is quite useful. If you need to, you should take a writelock + +The 8472: I wrote algorithms where it's useful to allow concurrent readers and implement write later on. + +Nia: Can you just pass a reference to the underlying `RWLock` and try a write on it? It's just a shared ref. + +The 8472: You need to drop the ReadGuard first which means you no longer have access to the underlying data + +Fon: There are weird usecases that will show up with lifetimes + +Nia: Can we have a different upgradabla ReadGuard? + +Amanieu: an ubgradable ReadGuard exists in parking_lot. But you can only have one at a time. It allows to concurrent readers until you try to upgrade it. If you had multiple that both do a hard upgrade, you'll get a deadlock + +The 8472: But with try_upgrade one would fail + +Nia: So we could only expose the try one + +Amanieu: If you're writing that, you shouldn't use the standard library. + +Nia: I believe The 8472 when they say they have an algorithm that it's useful + +Nia: Sounds like people here think that having covariance on the read lock is better? + +Amanieu: Yes + +Nia: And maybe we can have an upgradable ReadGuard that would go through the ACP process + +Fon: I'm confused why this change was made to just the nonpoisoning version? The poisioning one should have the same issue. + +The 8472: Do we even have `try_upgrade` there + +Amanieu: On July 7th I closed the ACP as not planned. The conclusion IIRC was to prototype it outside of the standard library. Should we do that here too? + +Nia: We can resolve that question under the "unresolved questions" + +Amanieu: do we use pthreads + +Josh: Not anymore. All of the mainstream platforms I can think of is driving the futex directly + +Nia: I'll reply that we want covariance and we'd like a prototyping upgradeable lock in parking_lot + + +#### [#141975](https://rust.tf/141975) Tracking Issue for `unix_send_signal` + +Fon: We discussed this last week. I thought we wanted to write actual code for this: https://github.com/rust-lang/rust/issues/141975#issuecomment-6021125452 + +Nia: Unnominated, let's see + +#### [#153261](https://rust.tf/153261) Partially stabilize `ptr_alignment_type` as `alignment_type` + +Fon: I [renominated](https://github.com/rust-lang/rust/pull/153261#issuecomment-5482587674) this. It's blocked on Sushis' opinion. We have three options: + +1. We omit the as_nonzero_usize from the stabilisation. +2. We rename the method to as_non_zero_usize. +3. We keep the as_nonzero_usize naming. + +Nia: I think restarting the FCP as is is not the worst idea. Let's not block this on Andrew. + +Nia: I think most of us were happy with "nonzero" being one word + +The 8472: We odn't have consistency there so it doesn't matter + +Amanieu: The conclusion was that "nonzero" is a word in a dictionary + +Fon: This would still be the first case fo stabilization where we decide on that but I'm fine with that + +The 8472: The capitalization is an argument: we have both `NonNull` and `NonZero`. + +Fon: That's the main argument for that. But also we could pretend that it's "half capitalized" + +Nia: This is pure bikeshed. + +Fon: My opinion is to keep the current name. But we could also restart the FCP. + +Nia: I'm restartting FCP, we're doing no underscore + + +#### [#156743](https://rust.tf/156743) std: store key\-based TLS variables in a hashmap + +Fon: I can't see what we were using before + +The 8472: I think we used the native slots + +Josh: Sounds like the problem is there are limited number of native slots. Do we *really* need a HashMap here rather than just an Array? Don't we know the number of TLS keys? If you have three thread-local items that are within your platform's capacity, it'd be strange to force you to use the HashMap. I wonder if we could only use that as a fallback + +Fon: Could we see how this affects the performance in the compiler? Do we use them there? + +Josh: I think we use them in the compiler + +The 8472: Last joboet's comment says "no tier 1 targets left" + +Josh: As in, only tier 2+ targets would use this? In that case I don't care + +Fon: There are some tier 2 targets where it would be unfortunate (e.g. freebsd, musl) + +Amanieu: Anything using ELF is using native TLS + +Fon: It also automatically includes MacOs as well. + +Nia: Given the changes mentioned above (few targets to be impacted, even elf stuff is fine), I'd ship it + +The 8472: It'd be helpful to have a more detailed list. I think SGX is tier-2? + +Fon: There is a tier-2 SGX but not all of SGX is tier-2 + +Nia: They can do their own implementation if they want + + +#### [#162808](https://rust.tf/162808) Enable `--generate-link-to-definition` rustdoc option on std docs + +Nia: Nominated by Amanieu + +Fon: We need compiler checking in order to do this. The solution was to make no_code macro that removes the code in doc mode. + +Josh Stone: All this `no_code` everywhere is pretty horrible + +Amanieu: The `no_code` macro is ugly, maybe it could be an attribute instead. Basically, tell rustdoc to not look into the body of this function. + +The 8472: Rustdoc uses the compiler internals, right? + +Fon: Telling rustdoc is just `#[cfg(doc)]`. That's also just telling compiler. + +The 8472: There was an unstable flag `-Zeverybody-loops` that replaced every body with a loop. That's similar and might allow parsing to happen and would only get ignored at a later stage. The flag was removed because it made things complicated and now we're back to doing that by hand + +Fon: Another upsetting thing is we can't compiler this. Rustdoc doesn't need to compile anything, it just needs name resolution. + +Nia: I'm still inclined to go against this. I wouldn't want to maintain this and it would be hell for anyone who doesn't understand when to put the macro to. + +The 8472: It's mainly the `os` module where we already have a lot of `cfg(doc)`. + +Fon: An attribute would be better + +Nia: That's less hideous than this + +Tomáš: Would the work of Alejandra González (she's doing staged compilation) help? I'm not sure she's planning to do nameres-only but maybe she could? + +Fon: In these functions we only need name resolution. But in all of our deps we need more than name resolution. + +Nia: The only solution I see is to make this an attribute for now and hope Alejandra's work fixes it. We could also say no to this, but then we lose link to definition and that's sad. + +Josh: Could an attribute be applied at a module level? + +Fon: We should be able to do that. + +Nia: We could do that. It would be great if we could have one attribute that does both (module and item-level attribute) + +Fon: If it's configured out, Rust Analyzer will just ignore it + +Nia: Would we be able to eat this (attribute) on item? + +Fon: As long as it's applied to a function and it modifies the function body, yes. + +Amanieu: Implementation-wise it might be difficult to apply to module + +Nia: Per-item is acceptable + +Fon: Yes that sounds like more work + +Josh: I don't think it even needs to change the function body + +#### [#163818](https://rust.tf/163818) remove\_dir\_all: avoid deleting symlinks to files on Unix + +This was discussed in last week's meeting. + +#### [#164175](https://rust.tf/164175) Drop WC\_ERR\_INVALID\_CHARS from Windows stdio + +Chris: This is instead of erroring on UTF8 output in console + +Amainieu: This is stdio which accepts Write which accepts arbitrary byte stream + +The 8472: But the console doesn't support that + +Chris: It does but in whatever encoding + +Fon: Writing potentially non-UTF8 output to the console resulting in IO error is terrible. In most cases, this will be something that's bytes that's string and we should degrade that gracefully + +Amanieu: That's also potentially untrusted data + +The 8472: Isn't printing untrusted data to the console problematic due to escape codes? + +Fon: The right choice would have been implementing Read for stdio be platform-specific on unix + +Josh: I see the PR's explicitly checking if we're writing explicitly to the console. But in some cases you are writing a binary to a pipe and that's fine + +Amanieu: This seems fine to me + +Nia: No objections + +Chris: Thank you + +#### [#164258](https://rust.tf/164258) clarify when `Vec::into_boxed_slice()` is in\-place + +Nia: I think this is a useful guarantee, our implementation already does this. I started FCP on it + +Amanieu: This seems fine. I think people already assume it anyway + +Josh: We previously said it uses shrink-to-fit so in a roundabout way this was already promised + +The 8472: It *could* shrink-to-fit and then copy it anyway. So this is a new guarantee. + +The 8472: Since the Allocator API was stabilized, we should refer to the allocator fitting. That also applies to the box. + +Fon: Is the issue specifically about allocating excess and it being part excess we don't need to shrink-to-fit? + +The 8472: Yes: https://github.com/rust-lang/rust/issues/125941. + +Fon: We explicitly confirm the contents of the `Vec` being 3 pointers. In that model, there would be no way to store excess for allocation. + +The 8472: It could ask the allocator to please resize to the target size. And the `Allocator` could say that's within its existing flexibility and do nothing. + +Nia: for this particular case we should not give excess. + +The 8472: If you call `shrink` it returns a slice pointer that has a length and it can have excess + +Fon: The docs say "smaller or equal than the requested size". I think we should word it as we don't exactly guarantee that the allocation is smaller ?? + +The 8472: We have existing wording in other places about excess capacity. We can refer to that or copy it. + +Fon: This is a part of the existing `Allocator` work. There's a lot of documentation that needs to be updated for the `Allocator` API. The only guarantee here is that we're allowed to use the same pointer and well do that if we can. + +Nia: Makes sense + +The 8472: I was trying to make sure we avoid documenting something that's too strict + +Nia: Should we kick off the FCP? + +Fon: Yes and any concerns could be brought up for this + +#### [libs#864](https://rust.tf/libs864) Extra tracking labels for libs team + +Fon: This goes with the regressions list. What compiler considers P-High is different from what we do. Compiler's P-High means they want to do this thing. In libs P-High means we want to look at it more. We want another label for this, the question is whether `-radar` is good enough for this + +The 8472: Don't we just use `P-High` for regressions? + +Nia: For regressions, I don't think `P-High` would be shared with the compiler + +Fon: These are libs issues, but libs is not going to be the one doing them. The one about Pin being deref-coerced, that will be a libs change to the `pin!` macro, but there will also be a compiler change. It makes sense to say it's a libs issue but that libs is not going to be working on this + +The 8472: Maybe we should change the team label to clarify who's the driver. + +Fon: That's essentially what the `-radar` label Lang uses for that. The way the prioritization subteam works is they'll tag every relevant team on the issue. And those teams will also be tagged on the PR. We won't be returning to this every week but we want to be tagged when the PR is open + +Fon: It would make sense to have a label saying "libs is driving this" and not having that label would mean that it's not there + +Fon: That's the `-radar` would mean -- we want it to show up every week, but we don't need to discuss it every week. We want to give guidance to people who are prioritizing issues to make sure we discuss it in our meetings. Once we've nominated it and discussed it, what should we do about it? + +Nia: Put a `-radar` on it. That should mean it shows up in the agenda but we don't need to discuss it. + +Fon: And that also closes this nomination. In terms of agenda, this means we're replacing the `Regressions` section with `Radar` section? + +Nia: Yes + +#### [forge#1111](https://github.com/rust-lang/rust-forge/pull/1111) Completely rework library team docs + +Fon: This would be best for people to read in advance. The linked issue has a hackmd that goes over the strategy for this: https://hackmd.io/@clarfonthey/S1jJs8ljGl. The doc talks about where everything has moved. The PR is on std dev guide. A lot of those represent decisions that were made that nobody FCPd. I think the main thing is probably the std dev guide things that were left out. The other thing is on `assert_unchecked!` -- having a more formal policy on that. That would give a better idea for review on when it is okay to use `assert_unchecked!` and the idea is as a lost resort. In most cases it would make the code worse. + +The 8472: We do have a bunch of places where we hint to the code that comes after the function that there is some invariant there. E.g. in the binary search you can do a post condition the LLVM can't figure out on its own. + +Fon: That's a place where it would be really valuable. Or similarly: NonZero would assert to the compiler that this value cannot be zero. For binary search that logic is worth it. + +Chris: We have pattern types now as well. + +Fon: Pattern types are explicitly listed on the page as an option. + +The 8472: But we can't use them in e.g. binary search and other places that have existing APIs where we return something more narrow than the signature says + +Fon: We can't do pattern types for dynamic values + +Fon: All this is a relevant discussion that hasn't been had yet. + +The 8472: Is this based on any existing PRs? + +Fon: Yes and that's why I have the list. We could FCP this part by part, but maybe that's an overkill. Depends on what we want to do. If people would prefer to set up a dedicated meeting like what Lang does with their design meeting (everyone read it at the meeting) + +Nia: Let's discuss this async. + + +### Regressions + +#### [#142119](https://rust.tf/142119) `P-medium` Linking a Rust staticlib unexpectedly changes C math functions from libm to bundled ones from compiler\-builtins + +#### [#149752](https://rust.tf/149752) `P-high` TrivialClone is not derived for generic types (Performance regression) + +#### [#153425](https://rust.tf/153425) `P-medium` `&pin!()` stopped being deref\-coerced in rust 1.88 + +#### [#163614](https://rust.tf/163614) `P-high` Regression in Rust 1.99: missing symbol `wcslen` + + +## FCPs + +#### [#163816](https://rust.tf/163816#issuecomment-5998492761) stabilize String::into\_chars +- needs 3 libs: [@Mark-Simulacrum](https://rfcbot.rs/fcp/Mark-Simulacrum) [@the8472](https://rfcbot.rs/fcp/the8472) [@thomcc](https://rfcbot.rs/fcp/thomcc) + +#### [#161531](https://rust.tf/161531#issuecomment-5381271798) Remove `T: Send + Sync` bound from `Arc::downcast` +- needs 2 libs: [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) +- needs 1 libs-former-fcp: [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi) + +#### [#121641](https://rust.tf/121641#issuecomment-3821243226) Tracking Issue for `OnceCell/Lock::get_mut_or_init` +- needs 2 libs: [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) +- needs 1 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu) + +#### [#162012](https://rust.tf/162012#issuecomment-5470063322) unseal std::io::IsTerminal +- needs 1 libs: [@the8472](https://rfcbot.rs/fcp/the8472) +- needs 2 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu) [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi) + +#### [#163499](https://rust.tf/163499#issuecomment-5895502691) vec: stabilise allocators for into\_iter +- needs 4 libs: [@ChrisDenton](https://rfcbot.rs/fcp/ChrisDenton) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) [@thomcc](https://rfcbot.rs/fcp/thomcc) + +#### [#163458](https://rust.tf/163458#issuecomment-5933589602) stabilize {Rc, Arc}::is\_unique +- needs 4 libs: [@ChrisDenton](https://rfcbot.rs/fcp/ChrisDenton) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) [@thomcc](https://rfcbot.rs/fcp/thomcc) + +#### [#117222](https://rust.tf/117222#issuecomment-5650063839) Tracking Issue for NEON FCMA intrinsics +- needs 3 libs: [@cuviper](https://rfcbot.rs/fcp/cuviper) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) +- needs 1 libs-former-fcp: [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi) + +#### [#161908](https://rust.tf/161908#issuecomment-5453467135) Stabilize `ExitCode::exit_process` +- needs 2 libs: [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) +- needs 2 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu) [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi) + +#### [#163696](https://rust.tf/163696#issuecomment-6101896042) Stabilize `int_from_ascii` +- needs 5 libs: [@ChrisDenton](https://rfcbot.rs/fcp/ChrisDenton) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@nia-e](https://rfcbot.rs/fcp/nia-e) [@the8472](https://rfcbot.rs/fcp/the8472) [@thomcc](https://rfcbot.rs/fcp/thomcc) + +#### [#151973](https://rust.tf/151973#issuecomment-5413059244) Stabilize `proc_macro_value` feature +- needs 4 libs: [@cuviper](https://rfcbot.rs/fcp/cuviper) [@dtolnay](https://rfcbot.rs/fcp/dtolnay) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) +- needs 1 libs-former-fcp: [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi) + +#### [#163753](https://rust.tf/163753#issuecomment-5979888082) implement PartialEq\\> for Vec\, &\[T\], &mut \[T\], \[T; N\], &\[T; N\] and &mut \[T; N\] +- needs 7 libs: [@ChrisDenton](https://rfcbot.rs/fcp/ChrisDenton) [@Mark-Simulacrum](https://rfcbot.rs/fcp/Mark-Simulacrum) [@cuviper](https://rfcbot.rs/fcp/cuviper) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@nia-e](https://rfcbot.rs/fcp/nia-e) [@the8472](https://rfcbot.rs/fcp/the8472) [@thomcc](https://rfcbot.rs/fcp/thomcc) + +#### [#80437](https://rust.tf/80437#issuecomment-1125982498) Tracking Issue for `box_into_inner` +- needs 1 libs: [@dtolnay](https://rfcbot.rs/fcp/dtolnay) +- blocked by concern: [convey the use case in documentation](https://rust.tf/80437#issuecomment-1150255531) + +#### [#158368](https://rust.tf/158368#issuecomment-4845707778) std: make `Instant` a signed `Duration` on all platforms +- needs 2 libs: [@the8472](https://rfcbot.rs/fcp/the8472) [@thomcc](https://rfcbot.rs/fcp/thomcc) +- blocked by concern: [input-from-andrew-gallant](https://rust.tf/158368#issuecomment-5320384629) + +#### [#126840](https://rust.tf/126840#issuecomment-4860808228) Tracking Issue for `mpmc` +- needs 2 libs: [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) +- blocked by concern: [async-and-unbounded-are-not-the-same-thing](https://rust.tf/126840#issuecomment-5181310113) + +#### [#163067](https://rust.tf/163067#issuecomment-5749755058) Stabilize `std::os::unix::process::CommandExt::chroot` (`process_chroot`) +- needs 2 libs: [@cuviper](https://rfcbot.rs/fcp/cuviper) [@the8472](https://rfcbot.rs/fcp/the8472) +- blocked by concern: [tests, examples and improved documentation](https://rust.tf/163067#issuecomment-5783213629) + +#### [#153261](https://rust.tf/153261#issuecomment-4164136648) Partially stabilize `ptr_alignment_type` as `alignment_type` +- needs 2 libs: [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) +- blocked by concern: [non_zero_name_consistency](https://rust.tf/153261#issuecomment-4608729444) + +#### [#134915](https://rust.tf/134915#issuecomment-4971877356) Tracking Issue for ByteStr/ByteString +- needs 1 libs: [@the8472](https://rfcbot.rs/fcp/the8472) +- needs 1 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu) +- blocked by concern: [deref-vs-methods](https://rust.tf/134915#issuecomment-4971877039) + +#### [#109737](https://rust.tf/109737#issuecomment-3821238426) Tracking Issue for `once_cell_try` +- needs 2 libs: [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) +- needs 1 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu) +- blocked by concern: [try-trait](https://rust.tf/109737#issuecomment-3869682069) + +#### [#161947](https://rust.tf/161947#issuecomment-5470072560) std::io: impl IsTerminal for {Empty, Repeat, Sink, Take} +- needs 1 libs: [@the8472](https://rfcbot.rs/fcp/the8472) +- needs 2 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu) [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi) +- blocked by concern: [always-false](https://rust.tf/161947#issuecomment-5496414873) + +#### [#163328](https://rust.tf/163328#issuecomment-5833061292) Stabilize `iter_advance_by` +- needs 4 libs: [@Mark-Simulacrum](https://rfcbot.rs/fcp/Mark-Simulacrum) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) [@thomcc](https://rfcbot.rs/fcp/thomcc) +- blocked by concern: [nth-advance-by](https://rust.tf/163328#issuecomment-5880235659) + +#### [#160951](https://rust.tf/160951#issuecomment-5365520096) Stabilize `core::io::{Error(Kind), IoSlice(Mut), Result}` +- needs 3 libs: [@cuviper](https://rfcbot.rs/fcp/cuviper) [@joshtriplett](https://rfcbot.rs/fcp/joshtriplett) [@the8472](https://rfcbot.rs/fcp/the8472) +- needs 2 libs-former-fcp: [@Amanieu](https://rfcbot.rs/fcp/Amanieu) [@BurntSushi](https://rfcbot.rs/fcp/BurntSushi) +- blocked by concern: [solicit-feedback](https://rust.tf/160951#issuecomment-5458232285) + +#### [#141994](https://rust.tf/141994#issuecomment-3368366135) add Iterator::contains +- has all checkboxes +- blocked by concern: [shadowing](https://rust.tf/141994#issuecomment-3469674757) + +#### [#160394](https://rust.tf/160394#issuecomment-5188875192) Lang/libs coordination question: okay for libs to stabilize traits with `final fn` in them? +- needs 1 lang: [@nikomatsakis](https://rfcbot.rs/fcp/nikomatsakis) +- needs 2 types: [@lcnr](https://rfcbot.rs/fcp/lcnr) [@spastorino](https://rfcbot.rs/fcp/spastorino) +- blocked by concern: [types-semantics-and-documentation](https://rust.tf/160394#issuecomment-5780228455) + +#### [#132484](https://rust.tf/132484#issuecomment-2472310685) unix: Relax escaping in `Debug` impl on `Command` +- has all checkboxes +- blocked by concern: [!](https://rust.tf/132484#issuecomment-2474536101) +- blocked by concern: [use-single-quotes](https://rust.tf/132484#issuecomment-2474536101) + +#### [#106418](https://rust.tf/106418#issuecomment-1954725313) Implement `PartialOrd` and `Ord` for `Discriminant` +- needs 2 lang: [@nikomatsakis](https://rfcbot.rs/fcp/nikomatsakis) [@scottmcm](https://rfcbot.rs/fcp/scottmcm) +- blocked by concern: [overly-broad](https://rust.tf/106418#issuecomment-1994833151) +- blocked by concern: [rfc-3607-instead](https://rust.tf/106418#issuecomment-2271666365) + +#### [#157168](https://rust.tf/157168#issuecomment-4781605913) Stabilize `Rng` and `SystemRng` +- needs 2 libs: [@dtolnay](https://rfcbot.rs/fcp/dtolnay) [@the8472](https://rfcbot.rs/fcp/the8472) +- blocked by concern: [unavailable SystemRng](https://rust.tf/157168#issuecomment-4781604491) +- blocked by concern: [global](https://rust.tf/157168#issuecomment-4808937889) +- blocked by concern: [fallibility](https://rust.tf/157168#issuecomment-4876547147) + + +## ACPs + + +### New + +#### [libs#912](https://rust.tf/libs912) ACP: `Vec::from_elem` and `Vec::from_elem_in` + +#### [libs#909](https://rust.tf/libs909) ACP: `uid`, `gid`, `effective_uid` and `effective_gid` in `std::os::unix::process` + +#### [libs#908](https://rust.tf/libs908) ACP: `OpenOptions`: add a way to mutate `custom_flags` (and not just overwrite them) + +#### [libs#907](https://rust.tf/libs907) ACP: Add an optimize\_for\_size\_aggressive flag + +#### [libs#904](https://rust.tf/libs904) ACP : Add a fallible but always safe method to compute layout from `Metadata` + +#### [libs#902](https://rust.tf/libs902) ACP: Add portable OpenOptions flag to not follow symlinks + +#### [libs#900](https://rust.tf/libs900) Thread spawn hooks for thread::Builder + +#### [libs#899](https://rust.tf/libs899) ACP: StartBounds and EndBounds + +#### [libs#898](https://rust.tf/libs898) Introduce `UnixSeqListener`/`UnixSeqPacket` + +#### [libs#896](https://rust.tf/libs896) Add a `get_disjoint_mut` method to `BTreeMap` + + +### Stalled + +#### [libs#826](https://rust.tf/libs826) Add `core::mem::size_of_field!` + +#### [libs#828](https://rust.tf/libs828) Separate `Components` iterator implementation into non\-prefixed & prefixed versions + +#### [libs#837](https://rust.tf/libs837) Split out common behavior of `FnStatic` and `FnPtr` into a new trait: `FnAddr` + +#### [libs#819](https://rust.tf/libs819) ACP: Remove 'static from Any itself, moving the bound to the operations themselves + +#### [libs#832](https://rust.tf/libs832) Type\-smart `intersect` on ranges \-\- v2 + +#### [libs#835](https://rust.tf/libs835) Rename `VecDeque::truncate` to greatly reduce ambiguity + +#### [libs#840](https://rust.tf/libs840) Trait for safe all\-zero byte initialization (v2) + +#### [libs#827](https://rust.tf/libs827) ACP: add `unsafe trait PureRef` to guarantee purity of the AsRef/Deref/Borrow traits + +#### [libs#821](https://rust.tf/libs821) ACP: `impl From<&Rc> for Rc` + +#### [libs#838](https://rust.tf/libs838) Add `rem_euclid_unsigned()` for signed integer types + + +_Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_