---
# System prepended metadata

title: Libs Meeting 2025-04-16
tags: [Minutes, Libs Meetings]

---

# Libs Meeting 2025-04-16

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-ujepnbwg2lzqgt6wvrndwimi
**Attendees**: Amanieu, JoshS, Chris, The 8472, Mara, Jane


## rust.tf/129485 Unstable Feature Usage Metrics

Jane: Project goal, metrics initiative. 

Jane: First prototype is unstable feature usage metrics. Implementation is pretty far. Next step is working with docs.rs to enable the feature there and collect data from them. Dashboard with usage over time is the aim.

Mara: What other types of metrics are you interested in, in the future?

Jane: Esteban is interested in error metrics. Which problems people are running into.

Jane: Niko wants to track breaking changes in the language. Times when people's code breaks when they only update their compiler.

Jane: Anything where we need insights in usage patterns. E.g. API usage, etc.

The 8472: Metrics is opt-in? So mostly on developer work-stations?

Jane: Everything is stored locally. You have to enable metrics gathering. Long term, we'd like to enable some set of metrics by default (still only stored locally).

Jane: Ideally we'd get a representative sample. So should be easy to opt-in. But transparency and trust is top priority.

The 8472: Mostly curious if we're getting real use data, or data from CI.

Jane: Docs.rs is activiating on their CI. Once we have a system where people can actualy submit it. Spam from CI is probably going to be a large chunk. Something we need to be aware of, but that's far down the road from where we're now.

The 8472: For feature tracking, we track usage or just the feature attribute?

Jane: Just the attribute.

The 8472: Curious about crates with a (conditional) nightly feature being built on stable.

Jane: No, not being parsed by the compiler. Don't think it shows up.

JoshS: Any changes needed in the library?

Jane: Nope!

Jane: I want to talk about this with libs because I want to figure out how y'all would use this. How important this feature is vs the overall system. Where libs priorities are.

The 8472: If someone uses build-std, we'd see that right? All the features that std itself uses?

Mara: We should probably skip those.

Jane: We track it per crate.

Mara: Would be useful for us to track individual items/methods of an unstable feature, rather than the feature flag itself.

JoshS: Unstable feature tracking is mainly useful for libs-api.

Mara: Metrics about breakage/regressions, etc. helps libs.

The 8472: like inferrence failures

Mara: Can whe think of any issues where more data would have helped us?

The 8472: Crater-like results from invididual workstations

Mara: Then it'd need to compile everythign with two compiler versions.

Mara: We discussed `exact_div`, `unchecked_exact_div` and `checked_exact_div`. We assumed `exact_div` would not be used much. Would be nice to have metrics for these separately. We could split the feature, but might be nice if we can get metrics on each in the future without splitting the feature.

Jane: Can look into that.

Mara: Can we get metrics on how 'confusing' an unstable API is? How many errors people get with it?

Jane: Not sure how many details we can collect. privacy concerns. but definitely the kind of error, etc.

The 8472: Distinguish public and private crates?

Jane: Probably not. Can definitely look at the crateid for std and core.

Mara: How about metrics over multiple sessions? Would be interesting to see if people modify and recompile rapidly after their first use of a certain method.

Jane: We should be able to track that in the future.

Mara: Would be nice not not just track how often a method is used, but also how often people find it confusing.

The 8472: Do we get platform information? How many people are compiling for embedded, etc.

Mara: Out of time. We're all very excited. Thanks for working on this!

## Triage

### FCPs

3 rust-lang/rust T-libs FCPs

  - merge rust.tf/115746 *Print thread ID in panic message* - (2 checkboxes left)
  - merge rust.tf/137122 *Specialize `Iterator::eq{_by}` for `TrustedLen` iterators* - (3 checkboxes left)
  - merge rust.tf/132484 *unix: Relax escaping in `Debug` impl on `Command`* - (0 checkboxes left)

[m-ou-se (1)](https://rfcbot.rs/fcp/m-ou-se), [joshtriplett (2)](https://rfcbot.rs/fcp/joshtriplett), [Amanieu (1)](https://rfcbot.rs/fcp/Amanieu), [cuviper (1)](https://rfcbot.rs/fcp/cuviper)

### (Waiting on team) rust.tf/134536 Lint on fn pointers comparisons in external macros

### (Regressions) rust.tf/119560 `cargo test` performance regression on Windows on version 1.75.0

### (Regressions) rust.tf/137971 `P-high` ReFS volumes on Windows Server 2022 break compilation

### (Regressions) rust.tf/139730 `P-high` A case of compound x86_64 performance regression caused by LLVM 20 and #124810

### (Regressions) rust.tf/139542 Type inference regression in 1.86 stable, due to unstable ByteStr

### (Regressions) rust.tf/53340 Performance regression in tight loop since rust 1.25

### (Regressions) rust.tf/112180 assertion failed: key as usize != KEY_SENTVAL in DragonFly BSD

### (Regressions) rust.tf/124216 `P-medium` Performance regression: rustc failed to optimize specific x86-64 SIMD intrinsics after 1.75.0

### (Regressions) rust.tf/138054 `P-low` unreachable pub item from portable-simd with target_feature = "avx512f"

### (Regressions) rust.tf/130320 `P-medium` stdlib code size increase in nightly-2024-09-01 for aarch64-linux-android