# Libs-API Meeting 2025-12-09

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: David, Amanieu, Nia Espera, Tomas Sedovic, The 8472, arielby

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

1 rust-lang/rfcs T-libs-api FCPs

- merge rust.tf/rfc3873 *build\-std: context* - (9 checkboxes left)

13 rust-lang/rust T-libs-api FCPs

- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
- merge rust.tf/116258 *Tracking Issue for explicit\-endian String::from\_utf16* - (1 checkboxes left)
- merge rust.tf/139087 *Fallback \`{float}\` to \`f32\` when \`f32: From\<{float}\>\` and add \`impl From\<f16\> for f32\`* - (4 checkboxes left)
- close rust.tf/136638 *warn on empty precision* - (3 checkboxes left)
- merge rust.tf/98407 *Tracking Issue for \`Exclusive\`* - (1 checkboxes left)
- merge rust.tf/145948 *Stabilize 29 RISC\-V target features (\`riscv\_ratified\_v2\`)* - (3 checkboxes left)
- merge rust.tf/140808 *Implement Default for &Option* - (1 checkboxes left)
- merge rust.tf/141994 *add Iterator::contains* - (1 checkboxes left)
- merge rust.tf/135894 *Tracking Issue for \`atomic\_try\_update\`* - (3 checkboxes left)
- merge rust.tf/76314 *Tracking Issue for atomic\_from\_mut* - (2 checkboxes left)
- merge rust.tf/125687 *Tracking Issue for \`new\_range\_api\` (part of RFC 3550)* - (4 checkboxes left)
- merge rust.tf/149408 *refactor: remove Ord bound from BinaryHeap::new etc* - (3 checkboxes left)

[joshtriplett (3)](https://rfcbot.rs/fcp/joshtriplett), [scottmcm (2)](https://rfcbot.rs/fcp/scottmcm), [the8472 (7)](https://rfcbot.rs/fcp/the8472), [Amanieu (4)](https://rfcbot.rs/fcp/Amanieu), [cjgillot (1)](https://rfcbot.rs/fcp/cjgillot), [jtgeibel (1)](https://rfcbot.rs/fcp/jtgeibel), [dtolnay (4)](https://rfcbot.rs/fcp/dtolnay), [mdtro (1)](https://rfcbot.rs/fcp/mdtro), [BurntSushi (8)](https://rfcbot.rs/fcp/BurntSushi), [jackh726 (1)](https://rfcbot.rs/fcp/jackh726), [estebank (1)](https://rfcbot.rs/fcp/estebank), [nikomatsakis (2)](https://rfcbot.rs/fcp/nikomatsakis), [SparrowLii (1)](https://rfcbot.rs/fcp/SparrowLii), [nagisa (1)](https://rfcbot.rs/fcp/nagisa), [matthewjasper (1)](https://rfcbot.rs/fcp/matthewjasper)

### (nominated) rust.tf/149615 *implement error multi provider*

Arielby: There's the error provider API that allows errors to provide types. We had concerns people might want to create observability libraries with 100+ provider types and put them somewhere. That would be O(n^2) which would be slow. Currently there don't seem to be libraries that provide more than 5 values. But if the API becomes popular, this could happen in the future.

Arielby: That's why I filled this to stabilise the curent error provider API. The multirequest is not urgent to stabilize, but the current error provider has users who want it to be stable.

Amanieu: I'm looking at the multirequest proposal

Josh: The request mechanism would let you comb through the list once with a set of things you want and that would change from n^2 to something better assuming it's not linerar in your multirequest. I don't think we want to add that now, but given we could do it sounds like it's reasonable to stabilise

Amanieu: IIRC, the complexity is not `n^2` but `n*log(n)`. LLVM can turn the lookup into a jump table and that reduces the complexity.

The 8472: but it's not always reliable

arielby: Sometimes LLVM does'nt like to generate the jump tables. But the other issue is having a long error chain. In that case it's still O(n^2) even with the jump tables

Amanieu: Do we expect the associate error data to be propagate through the chain?

arielby: Even if the provider is local, the observability library would want to follow the chain.

arielby: I'ts O(n*m) n is the number of errors and m is the number of types.

The 8472: We could at least make it fast for single errors so the problem odesn't compound it as much

arielby: In practice, you'd have a chain of length 50 where each entry is

The 8472: At work we don't have deep chains but we definitely put more than five values into the error.

arielby: So it's one step of the chain that explores around five types.

Amanieu: How does multirequest solve that?

arielby: It transposes the order of requests. You can always generate a pattern that generates `n*log(n)`.

The 8472: We could do better in principle, but then the provide side would need a multiprovide type that we'd sort errors and do things in tandem but that would be an even more complicated API

David: This was nominated to see if we can stabilise the non-multiprovide part. I don't have an issue with that.

arielby: I don't see the reason to have a stable multirequest api for now.

David: Is there anything missing before we kick off an FCP?

Amanieu: There's one thing I'd like to change: there are free functions I'd like to ahve a methods on the trait. That's blocked on final methods in lang.

arielby: I don't want to block this on a lang feature that we don't know when it's shipping.

Amanieu: Josh, do you know?

Josh: At the moment the RFC has not been accepted yet. I've tried to revive it and kicked off an FCP. Once it's signed off on, I expect it to be fast to implement. Someone did a prototype. And once it's implemented, we could use it before it's stabilized.

Josh: The aspect of not putting it in the vtable is not something that `final` will currently guarantee.

David: Which methods are we talking about? request_ref and request_value?

Amanieu: Yes.

David: Those have specific type parameters. They won't be in the vtable.

Amanieu: They won't be in the vtable but we still want them to be available on `dyn Error`

arielby: This is not a problem specific for this API. Given taht this is a widespread problem I don't see why this proposal should be blocked on that.

Josh: I don't think we should wait long for it. But I think it's worth renominating this for lang and say libs-api is interested in this and say that we want to use it while it's unstable. But I don't think we need a new lang feature to provide it on `dyn Error`. But for the short term, can't we do `impl dyn Error` block?

The 8472: Don't arbitrary self types support that?

Amanieu: We had `impl dyn Error` and we removed it

David: There's method resolution issue where one of the methods of the same can become uncallable.

David: I'm inclined to agree with arielby. It's not a huge surface.

arielby: This pattern happens in a lot of places in code and people will switch to the new API when it's ready.

Amanieu: Josh we discussed this and it could potentially be useful for the Read trait.

Josh: read_array won't be in the vtable anyway because it has a generit. But it should be marked as final before we stabilize it. And if we add additional helper methods, those should not be overridable either.

arielby: I agree this is a useful lang feature. But the version that works without the vtable, is still some times in the future -- it'll need its own RFC. I feel we shouldn't be blocked on that.

Amanieu: The conclusion is we start stabilization for error generic access?

The 8472: The performance was my main concern. If we don't have any alternative there, that's fine by me

David: What timeline do you have to stabilise the multirequest

The 8472: We'll keep this on until someone runs into scaling issues and then we can stabilise

Josh: arielby, did you prepare this PR with the idea that you had a usecase for it? Or that you wanted a proof of concept that it could be done in a scalable way?

arielby: Mostly latter. To prove that this can be stably. But do we need to merge it to stabilize the feature?

Josh: Then let's have this as a proof of concept, but we don't need to merge it. We can document the potential for n^2 and to get in touch if people have scaling issue.

arielby: That makes sense to me.

The 8472: I'm ok with that. If we can find a way to amke the current API fast in LLVM, we wont't need it.

David: A counter argument is: if they have a lot of items, it's difficult to tell if they're hitting issues with going down the dyn chain vs. an n^2 problem. Having it in nightly as unstable would make it easier for people to test.

The 8472: If we do want to add it, we should treat this as an ACP and review the API surface?

David: From my point of view the ACP side has already been accepted. If we want to stabilise it later, we can have the discussion of the API surface then.

The 8472: The `ChainValMultiRequestBuilder` -- is that exposed?

arielby: it's public

David: must this be in the same library?

arielby: It must.

Josh: as long as it's under a separate feature flag with a tracking issue, I think it's fine having it there

David: I agree, let's put it in a module somewhere.

The 8472: This already creates a `provide` module, maybe we want to make it public?

arielby: It's already in the provide module

Josh: We show unstable APIs by default and the `provide` API is already pretty complicated. Maybe we could tuck it in another module?

arielby: a multi module sounds like a good idea

Josh: We could make the multi module unstable behind a flag

Josh: Any concerns about that?

Amanieu: I'm happy to move on with that

Josh: We need to start a stabilisation FCP on the provider API

arielby: I'll be clear the multi module API

The 8472: Do we need multi module? You already created provide and that didn't exist before

arielby: We could have an unstable module inside the provide module

Amanieu: I belive the API description in the tracking issue needs to be updated. Can someone start an FCP?

Amanieu: I can do that.

### (nominated) rust.tf/125687 *Tracking Issue for \`new\_range\_api\` (part of RFC 3550)*

Discussed last week, unnominating.

### (nominated) rust.tf/146948 *add \`core::hint::prefetch\_{read, write}\_{data, instruction}\`*

Amanieu: There's a big discussion on how to deal with nontemporal prefetches and prefetches to different cache levels. My conclusion is this is too much complexity for agenerit API. You should just have prefetch

AManieu: Folkert said a lot of the prefetches make use of L2 prefetches

Amanieu: I decided to go with these names because it's what's easier for users to understand.

The 8472: Do all mainstream CPUs support more or less those interfaces?

Amanieu: More or less.

Josh: In CPU design the concept of a L1/L2/L3 is pretty universal.

Josh: This implementation is trying to use a constant that's underlying prefetch, but L1 = 3, L2 = 2 and L3 = 1 is bad

Amanieu: I'm aware.

The 8472: If we want a portable API then it should map to all mainstream platforms at least.

Amanieu: I think we should not have locality at all. Just have a pointer and nothing else.

The 8472: But the motivation is they want portable API for what reason?

Amanieu: They're porting zstd from C uses builtin prefetch.

The 8472: I looked at the code and they do use a bunch of platform-specific code. Should we redo it?

Josh: Do we have x86-specific prefetch-t0 prefetch-t1 etc.

Amanieu: We have mm_prefetch

The 8472: We have intrinsics that probably map to whatever LLVM does?

Amanieu: This PR exposes those intrinsics.

The 8472: So we're exposing LLVM and it has this API?

Amanieu: Yes, and it's based on the GCC API which has locality, L1, L2, L3 and temporal

Amanieu: This is the ARM documentation: https://developer.arm.com/documentation/100069/0606/Data-Transfer-Instructions/PRFM--immediate-

Josh: The current way it's broken out has the locality passed to the non-temporal prefetch. You can't have a non-temporal prefetch

Amanieu: You can. Our intrinsic is just not providing it.

Josh: On common architecture implementations of ARM -- do all the combinations work?

Amanieu: I don't know.

Josh: If some architectures will handle this in all richness and some don't, providing an abstraction over this doesn't sound completely unreasonable.

Amanieu: Yes.

Josh: Every couple new generations of processor, they (Intel) add a new prefetch and every couple of generations that prefetch becomes less necessary because the processor will handle that better and they'll add a new round of prefetch. I wonder how stable this will be.

Josh: Whether you need a prefetch depends on the version of your architecture and a benchmark with/without prefetch. If we have a portable version, people will want to have a way to detect whether they need it or not. Which makes me wonder whether we should have a portable version at all.

The 8472: Yeah. On a tiny arm and x86 are going to have different behaviours

Josh: The prefetchers on different chips can differ a lot in how smart they are

Josh: I think we should add this and the proposed API is reasonable. But I'd be hesitatnt to stabilize this without trying to find out whether people are using the prefetch intrinsics and will want to switch to vs. keep using the underlying intrinsics.

The 8472: We can ask the author if theyr zstd code benefits from the same prefetches on multiple platforms if they've measured that.

Amanieu: I don't think they have. It's a straight port of the C code.

The 8472: The C code authors may have it then.

Josh: I'm looking at uses of mm_prefetch in Rust code and I'm seeing a lot of Rust projects caling the prefetch hint. Mostly only for x86. I'm trying to find if anyone is using prefetch for ARM

Amanieu: prefetch for ARM is unstable.

Josh: I think we should merge this. We may wish to figure out which criteria to use for stabilisation.

Amanieu: What are the thoughts on nontemporal methods?

Josh: (1) make it a locality (wrong for arm), (2) make it a separate parameter (too complicated), (3) make it a separate function (what this does and seems reasonable)

Amanieu: So happy with the PR as it is?

Josh: For now.

### (nominated) rust.tf/147725 *Remove \-Zoom=panic*

Amanieu: it's a very complex feature ot implement. We should instead tell people to `set_alloc_error_hook` to panic instead if that's waht they need. It's a pain to implement as a compiler flag.

Josh: We're not removing the feature, but we're saying "rather than making a special flag use the out of memory hook"

Amanieu: Yes. Which is arguably more user-friendly than a sea of compiler flags. I'm happy to go ahead, any objections?

Josh: Hanna's message: https://github.com/rust-lang/rust/pull/147725#issuecomment-3419691707 arguing the gook is better.

Josh: I'm sympathetic to Ralf's point that alloc hooks is a global mutable. But so are all the other hooks.

Josh: This seems fine.

Josh: Even though it's an unstable feature, given a lot of people were waiting on it and looking for it, would it make sense we add a brief relnote saying "we dropped this, use alloc hook instead"

Josh: Oh `set_alloc_error_hook` is unstable, can we fix that?

Amanieu: Oh, is it unstable?

(Amanieu is looking at the alloc_eror_hook tracking issue)

Josh: How does `alloc_error_handler` attribute and `alloc_error_hook` interact?

Amanieu: the `alloc_error_handler` attribute in the standard library calls the hook.

Amanieu: I think we don't need the hook mechanism. We can do this just with the attribute.

Josh: Yes.

Amanieu: We'd have to publicly expose the default error handler. I'll write up something.

***

The 8472: Has there been any progress on externally implementable types?

Amanieu: There's been progress. Latest update: 5 hours ago?

The 8472: Would alloc_hook use that mechanism in the future too?

Amanieu: Yes.

### (nominated) rust.tf/148941 *stabilize \`Peekable::next\_if\_map\` (\`#!\[feature(peekable\_next\_if\_map)\]\`)*

Amanieu: Last week we decided to give it a couple weeks to see the experience. Let's give it another week.

### (nominated) rust.tf/149069 *Tracking Issue for \`uint\_gather\_scatter\_bits\`*

Josh: Someone made a convincing comment saying that this is confusing the "scatter" / "gather" in ways that people using SIMD would be. Since this is unstable, they propose the changes.

Amanieu: If you're vectorising a loop to do for iterations at once (pointer chasing) you use this

Amanieu: I'me happy with either (deposit/extract or compress/expand)

Josh: I've a mild preference for deposit/extract because it won't conflict with terms like "compress" when searching code and having zlib in there too.

Josh: My main point is: I think we ought to rename them and propose them for stabilization.

Amanieu: We said we'de block stabilization on LLVM intrinsics. Yes to renaming, either name is fine.

Josh: Any concerns with me writing it up and using deposit/extract?

The 8472: Sounds fine

Amanieu: Is that different from bitfield exctract? Those are also instructions on ARM. It takes an offset and a width.

Josh: I believe these intrinsics are for: "I have a mask, please consolidate the bits the mask matches"

Josh: On ARM getting the mask into the register is more complicated.

Amanieu: Are we doing deposit/extract? I'm fine with that. One downside is we're not in line with C++ which uses compress/expand

Josh: I think that's what aliases are for

Amanieu: Yeah, sure

Amanieu: C++ proposal was against deposit/extract because of ambiguity: https://eisenwave.github.io/cpp-proposals/bit-permutations.html#naming-compress-expand

Josh: Their claim is that "deposit" could be either "take a thing, compact it" or "take a compact thing, extract it and deposit it". I can see that.

Amanieu: I disagree with that decision, we should go with deposit/extract.

Josh: I agree.

Josh: But it's probably worth saying we've seen the CPP proposal and we don't agree with the rationale.

### (nominated) rust.tf/149537 *f\*::min/max do not behave as documented for signaling NaN on aarch64, or with optimizations*

Amanieu: the bullet points in [my comment](https://github.com/rust-lang/rust/issues/149537#issuecomment-3604776087) show the three IEEE defined behaviours. Notably ARM implemens the 2008 min_num/max_num and RISC implement the 2019. Both implement minimum/maximum

Amanieu: x86 doesn't use either. It does `if a < b { a } else { b }`

Josh: If you have `NaN` then it''s not `a < b`.

Amanieu: Currently we define float::min, return the lower number ignoring NaN. If one of them is NaN, ?? This is very slow on x86.

Amanieu: I'd like to relax it so that if NaN we can nondeterministically return either NaN or the numeric argument. And on zeros, we'll non-deterministically return either a negative or positive zero. That will let us implement the fast behaviour on all platforms.

Josh: I the only difference between min_num and minimum_number that

Amanieu: the 2008 behaviour: if any input is a signalling NaN the output is a Quiet NaN

Josh: if any input is a signalling NaN, the result is a qNaN. It's not a squelching behaviour

Amanieu: It's also non-associative. That's a big issue for compiler optimization

Amanieu: Can we get away with this breaking change?

Josh: I think we should try. We should be very loud about it.

The 8472: We haven't made such a change for MulAdd, right?

Amanieu: no, that's defined as the IEEE MulAdd.

The 8472: It must be emulated on hardware that doesn't have it

The 8472: I'd like to understand why we'd do the "let's do the fast thing" here and not elsewhere. This will change the behavior algorithms.

Josh: In theory this should only affect the result of an algorithm if you have a NaN or if you use the copy sign. At the end of your operation is negative or positive zero, the only result is if you use the copy sign operation.

Amanieu: There's a valid usecase we can break: if you have an array of floats where some entries are NaN and you want them to be ignored in min/max because you're intentionally relying on this behaviour

The 8472: Can we provide a new method that does the fast thing?

Josh: We could, but getting everybody to switch to that

The 8472: It's float, it's unstable. The situation is terrible anyway. We're going to stabilise them at some point.

Josh: I think it's important to have a "fast" and "maximally specified". But which one should be "max". I think the short one should be the "fast" thing and the more particular one should be longer.

Amanieu: I'd hope if someone's relying on this is testing it.

Josh: I think it's worth trying a crater run.

Amanieu: how can we make the crater run maximally pessimistic? Always changing the behaviour?

Amanieu: I'm not sure we can get away with this.

The 8472: It's already broken now, right? That's the issue we're looking at?

Amanieu: This bug already happens with signalling NaNs and no one is using those. But people using quiet NaNs would still be affected.

The 8472: So the current breakage is less interesting, because it's only affecting signalling NaNs.

Amanieu: The issue is: we're documenting the 2019 behaviour but LLVM sometimes implements the 2008 one instead

The 8472: Which is only a minor difference because no one is using signalling NaN. But that means we can't use it as a justification for "this is already broken so let's make it fast"

Amanieu: Proposal, we attempt to do this and we also add minimum number methods and just not expose the 2008 behaviour

The 8472: How will we get the information without just trying to break the world?

Amanieu: That seems unlikely.

The 8472: But people testing NaNs rather than just the happy path is also unlikely

Amanieu: I don't think anyone relies on this behaviour

The 8472: Should we announce this?

Amanieu: I'd like to stabilise the minimum and minmum_number methods

Josh: You want to stabilize both? You want guaranteed behaviour A, guaranteed behaviour B and then whatever

Amanieu: Yes. And the "do whatever" is the only one fast on x86

The 8472: Should we remove the wording now and change the behaviour later? So we don't keep guaranteeing something we're trying to remove?

Josh: That seems appropriate.

The 8472: If the plan is to relax the implementation, we should stop promising the thing we don't want to do.

Amanieu: Yes.

Amanieu: How should we communicate this. Make a public announcement?

The 8472: So the first two in your list minimum/maximum and minimum_unmber/maximum_number plus whatever's fastest

Amanieu: For any of the three current behaviour the x86 one is just terrible.

The 8472: Sounds like a plan but I think we should do something like that for MulAdd

Amanieu: We already have that: the `algebraic_add` / `algebraic_mul`

The 8472: Okay, then never mind

The 8472: If we do get feedback from people that they're relying on the behaviour, what will we do then?

Josh: Then we'll probably add another one and figure out what to call it.

### (nominated) rust.tf/rfc3892 *Complex numbers*

Josh: I think the RFC is comparable to the ACP. This was expanded to an RFC because it needs to specify Lang FFI compatibility. But that feels liek a less Libs API matter. Our question is do we want to add this API?

Amanieu: This is proposing general API number. What about us doing it only for FFI purposes?

Josh: The sensible representation here is the real+imaginary part.

The 8472: Nobody is using the polar form?

Josh: Nobody uses it for a transmition type. We could add those later as a separate type.

Josh: The propsal is: let's add a type and constructor and basic arithmetic implementation. So it's a vocabulary type the ecosystem can use and build on

Amanieu: Does complex number multiplication work differently?

Josh: Yes, the imaginaries times each other become negative.

Amanieu: Why does this need to be done with compiler builtins?

Josh: Acceleration.

Amanieu: Can we allow this type to be used with bignums?

Josh: I think the `Float` is a bit of a vestige. I don't think we should be requiring `Float`. In theory we should support it with integers and other arbitratyr types.

Amanieu: Let's use the sealed type

Josh: We should have the sealed Fload bound on the operations. And nothing else.

The 8472: Would we make the trait public or remove it?

Josh: I'm not sure we want to stabilise the trait. I think we should implement this using teh underlying traits (e.g. add depending on `Add`)

The 8472: Yes, I was going to ask to keep it unstable.

Amanieu: That seems fine.

The 8472: Do compiler backends optimize these?

Josh: I don't think you'd optimize complex operations specifically, but most of the operations can be vectorized easily.

The 8472: If you have a complex number the layout is having them side-by-side and if you have them in memory, the real and imaginary parts would be interleaved.

Josh: There are unswizzling operations you can use here. But I'd expet having these in vectors two at a time seems very SIMDable

The 8472: I think we should ask what the SIMD story for these types would be

Amanieu: You'd probably want to separate them out per components.

Josh: I'd say let's not figure out how to make them better for SIMD from day one

Amanieu: I think LLVM IR doesn't haev complex numbers. It's all handled in the clang frontend.

The 8472: Then there may be multiple separate types for SIMD handling complex numbers in the future.

The 8472: I'm mostly concerned about the current design possibly blocking us doing something better in the future. But I can't think of anything.

Josh: For the time being what's our next step? I'd propose making a few changes to the RFC (moving a few things from the RFC to future work section and drop `Float` from more places where it's not needed) but I think it's broadly reasonable for us to FCP?

The 8472: Aren't there integer complex numbers?

Amanieu: Not in C I think

### (new change proposal) rust.tf/libs709 *Add \`str::copy\_from\_str\` and other mutating \`str\` methods*

### (new change proposal) rust.tf/libs706 *More arithmetic functions for Duration*

### (new change proposal) rust.tf/libs705 *\`File::close\`*

### (new change proposal) rust.tf/libs700 *Mapped Arc and UniqueArc*

### (new change proposal) rust.tf/libs699 *Bring \`hashbrown::Equivalent\` into std*

### (new change proposal) rust.tf/libs698 *Stabilize trait \`ZeroablePrimitive\`*

### (new change proposal) rust.tf/libs691 *\`std::io::Read\` provides byte\-order reading trait*

### (new change proposal) rust.tf/libs688 *Initial state once cell value*

### (new change proposal) rust.tf/libs659 *Generalize ExactSizeIterator to QuantifiedIterator*

### (new change proposal) rust.tf/libs656 *implement Default for more iterators*

### (stalled change proposal) rust.tf/libs457 *APC: split\_pattern on slices*

### (stalled change proposal) rust.tf/libs543 *ACP: Slice to array version of \`split\_off\`*

### (stalled change proposal) rust.tf/libs544 *\`Arc\<impl !Sized\>\` constructors*

### (stalled change proposal) rust.tf/libs540 *Add Unicode XID related functionalities to \`proc\_macro\` crate*

### (stalled change proposal) rust.tf/libs520 *Add out of the box support for mapping custom error types that implement \`std::error::Error\` to \`Box\<dyn Error\>\`*

### (stalled change proposal) rust.tf/libs462 *impl fmt::Write for BufWriter*

### (stalled change proposal) rust.tf/libs379 *Combine, an iterator adapter which statefully maps multiple input iterations to a single output iteration*

### (stalled change proposal) rust.tf/libs261 *add \`write\_fmt\` method to String, to make \`write!\` macro work without imports*

### (stalled change proposal) rust.tf/libs347 *Context reactor hook*

### (stalled change proposal) rust.tf/libs111 *Restructure ptr\_metadata to minimal support*

_Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_