---
# System prepended metadata

title: Libs-API Meeting 2022-10-04
tags: [Minutes, Libs Meetings]

---

# Libs-API Meeting 2022-10-04

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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


[joshtriplett (6)](https://rfcbot.rs/fcp/joshtriplett), [dtolnay (4)](https://rfcbot.rs/fcp/dtolnay), [Amanieu (8)](https://rfcbot.rs/fcp/Amanieu), [m-ou-se (9)](https://rfcbot.rs/fcp/m-ou-se), [BurntSushi (14)](https://rfcbot.rs/fcp/BurntSushi), [yaahc (15)](https://rfcbot.rs/fcp/yaahc)

### Nominated

- [6 `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/99939 *Sort tests at compile time, not at startup*
     - Just needs to be reviewed. Doesn't need libs-api approval.
  - rust.tf/100021 *made \`unreachable\_unchecked\` panic in debug mode*
     - Seems good, but shouldn't unwind.
     - Left a comment. 
  - rust.tf/101698 *Constify \`TypeId\` ordering impls*
    - Seems like a hash or similar will always suffice for this. Which means this change is fine.
    - Nominated for compiler team to check.
  - rust.tf/101899 *#95295 causes unsoundness in multiple existing crates*
    - Amanieu: Letting a size greater than isize::MAX reach the global allocator is already UB, because of LLVM optimizations that understand allocations.
    - "library UB" vs "language UB"? Should Layout have a niche?
    - Is there a reason to have a niche?
      - LLVM could remove checks, if it knows that it's always < isize::MAX.
    - Problem is that we're changing the requirements for from_size_align_unchecked.
    - Adding a check to it for the new requirement would 'fix' the issue, but not desirable because it defeats the purpose of the unchecked version.
    - We could only check it in debug mode, by purposely causing an overflow (with inherit-overflow-checks) on >= isize::MAX. Doesn't fix anything for release mode though.
    - Alternative is to deprecate the existing function, add an assert in it, and have a new unchecked function with the new requirement.
    - Mara to comment.
  - rust.tf/101991 *Stabilize proc\_macro Span::source\_text*
    - Should it fail on any joined span? Or only for extreme cases like in the example.
    - Hard to answer. We should check what people do with joined spans / source_text.
    - The assert2 crate would use this with a joined span, to get the span of the entire expression.
    - We probably need some rule like 'it only works for tokens from the macro invocation itself'.
    - We consider the extreme case a bug that should be fixed, without breaking the assert2 case (stringifying an expression).
    - Is it a blocking bug?
      - Josh: Yes?
      - David, Mara: No
        - Of all the weird things people can do in macros, this one is very far down the list.
    - David to reply / resolve concerns. 
  - rust.tf/102225 *Allow const iterator implementations*
    - This would mean committing to never add a non-const method to the Iterator trait.
    - Maybe partially (non-)const traits should just be a thing. (Just like `where Self: Sized` on methods for exclusion from trait objects.)
    - How const traits work is still experimental, so it's hard for us to make decisions around it, since it's not clear yet what it means.
    - As long as this has no stable effect, it's fine to merge. But these questions should be tracked for const trait stabilizations.
      - That's already tracked using `#[rustc_const_unstable]`.
- [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/rfc3271 *RFC: Add more support for fallible allocations in Vec*
    - `try_` prefix already used on e.g. `try_insert` for maps, meaning something else. `try_push` could mean multiple things (try within capacity (without allocating?)
    - Mara: Feels like a similar issue as with lock poisoning: having two interfaces: one for manual error handling, one for just panicking/ignoring the issue (without verbosity like unwrap everywhere). Rust doesn't have the right tools to express this nicely. :(

### Waiting on team

- [1 `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/99032 *Disable unwinding for \`catch\_unwind\` error payloads.*

### Needs decision

None

### Stalled Tracking Issues

- [30 `rust-lang/rust` `T-libs-api` `C-tracking-issue` items](https://github.com/rust-lang/rust/issues?q=label:T-libs-api+label:C-tracking-issue+is:open+sort:updated-asc)
  - rust.tf/79676 *Tracking Issue for \`backtrace\_frames\`*
  - rust.tf/42839 *Peer credentials on Unix socket*
  - rust.tf/55132 *Tracking issue for thread::Builder::spawn\_unchecked*
  - rust.tf/66893 *Tracking issue for atomic\_mut\_ptr*
  - rust.tf/72505 *Tracking issue for \`#!\[feature(const\_float\_classify)\]\`*

## 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)_