# Libs-API Meeting 2022-12-13

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Amanieu, David, Josh Triplett, Mara, thomcc, vincenzopalazzo

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

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

2 rust-lang/stdarch T-libs-api FCPs

[BurntSushi (18)](https://rfcbot.rs/fcp/BurntSushi), [joshtriplett (9)](https://rfcbot.rs/fcp/joshtriplett), [dtolnay (5)](https://rfcbot.rs/fcp/dtolnay), [m-ou-se (10)](https://rfcbot.rs/fcp/m-ou-se), [yaahc (17)](https://rfcbot.rs/fcp/yaahc), [Amanieu (3)](https://rfcbot.rs/fcp/Amanieu)

### Nominated

- [5 `rust-lang/rust` `I-libs-api-nominated` items](https://github.com/rust-lang/rust/issues?q=label:I-libs-api-nominated+is:open)
- rust.tf/54140 *Tracking Issue: Procedural Macro Diagnostics (RFC 1566)* + rust.tf/83363 *Implement new proc macro diagnostics API*
- Reassigned to David.
- rust.tf/90308 *Consider deprecating and/or modifying behavior of std::env::set\_var*
- Would be nice if we could make this function `#[deprecated_safe] unsafe` or something like that. Option 1 in Ralf's comment.
- Then existing set_env in unsafe blocks wouldn't turn into a warning.
- That downside is acceptable.
- Option 1 sounds good.
- Mara commented.
- Josh to comment about #[deprecated_safe].
- rust.tf/103763 *\`Arc::ptr\_eq\` does not always return "true if the two Arcs point to the same allocation" as documented*
- FCP started. Nominated label removed.
- rust.tf/104210 *expose rebuild and implement drain\_filter for BinaryHeap*
- Amanieu: We shouldn't do this. `BinaryHeap<T>` might be in the wrong order depending on T's trait impls, but `BinaryHeap<usize>` for example should always be correct.
- We can implement DrainFilter by first setting the length to zero, and then setting the length back in drop.
- Or maybe we can just go without drain_filter. :)
- David to reply.
- Exposing rebuild? We already have that as `From<Vec>`.
- [1 `rust-lang/rfcs` `I-libs-api-nominated` items](https://github.com/rust-lang/rfcs/issues?q=label:I-libs-api-nominated+is:open)
- rust.tf/rfc3308 *Add \`core::mem::offset\_of!\` RFC*
- FCP started.
- [1 `rust-lang/libs-team` `T-libs-api` `I-nominated` items](https://github.com/rust-lang/libs-team/issues?q=label:T-libs-api+label:I-nominated+is:open)
- github.com/rust-lang/libs-team/issues/122 *Revamp unstable MaybeUninit APIs*
- Mara: We should check how this overlaps with the field projection RFC. Perhaps if that proposal is extended to cover arrays, it could cover most of the funcitonality proposed here.

### Waiting on team

- [2 `rust-lang/rust` `T-libs-api` `S-waiting-on-team` items](https://github.com/rust-lang/rust/issues?q=label:T-libs-api+label:S-waiting-on-team+is:open)
- rust.tf/101179 *Deprecate uninit\_array*
- See above.
- rust.tf/103800 *Stabilize \`::{core,std}::pin::pin!\`*
- This is now using the private field of Pin through #[allow_internal_unstable], but in the future this should use an unsafe field. Not a blocker though.
- FCP proposed.

### Misc

Josh: macro that expands to the current function/item?

Mara: Like C++ `__func__`? That's not a macro, but an implicit local variable. Maybe a macro is not the right mechanism?

Amanieu: What would happen if you use this as a `const`?

Amanieu: Maybe this should be an intrinsic.

Mara: Maybe part of the existing caller location, by adding a field to Location?

The 8472: a struct with item name and module path as separate field would be nice.

### Stalled Tracking Issues

https://github.com/rust-lang/rust/issues?q=label:T-libs-api+label:C-tracking-issue+is:open+sort:updated-asc

## Actions

- [ ] Reply to all issues/PRs discussed in this meeting, or add them to the [open action items](https://hackmd.io/ovrbJj6CRduRgSA0Wzg2zg).

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