---
title: Triage meeting 2022-08-30
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-08-30

## Attendance

* Team members: nikomatsakis, pnkfelix
* Others: Tyler, Mark, vincenzopalazzo

## Meeting roles

* Action item scribe: pnkfelix
* Note-taker: nikomatsakis

## Announcements or custom items

### backlog bonanza next steps

[Niko posted some stuff](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/backlog.20bonanza.20next.20steps/near/296183076), did some of the follow-up from our previous backlog bonanza meeting with the goal of getting folks involved in writing summaries / stabilization reports.

### let-else update

joshtriplett: est31 managed to fix drop order issues. Still some minor things but we are hoping we can get it into 1.65! One issue that might benefit from some help, something only showing up in release mode: https://github.com/rust-lang/rust/issues/99975

### Last-known status of variadic tuples / variadic generics?

joshtriplett: Variadics have come up a few times, most recently on the [thread Niko started](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/.22DSL-like.22.20projects/near/294955999) about programs that might benefit from having more control over error generating process and similar. Came up there that variadics would help with giving better errors by hand-rolling types. I wanted to ask whether anybody had any idea what the current status was.

scottmcm: I think there was a design note somewhere, but no active work.

nikomatsakis: I'm not aware of anything going on.

### Style team

joshtriplett: I've been working with Caleb Cartwright on an RFC recreating the style team. The rustfmt team does not want to have the job of deciding the best style. The current proposal is to make it a subteam of rustfmt and lang, since lang is the most connected to the concept (e.g., formatting for new language constructs). Wanted to make folks aware, happy to provide the link to that as well.

nikomatsakis: :tada:

## Action item review

* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)

## Pending lang team project proposals
### "Support platforms with size_t != uintptr_t" lang-team#125

**Link:** https://github.com/rust-lang/lang-team/issues/125

### "Positional Associated Types" lang-team#126

**Link:** https://github.com/rust-lang/lang-team/issues/126

### "Interoperability With C++ Destruction Order" lang-team#135

**Link:** https://github.com/rust-lang/lang-team/issues/135

### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143

**Link:** https://github.com/rust-lang/lang-team/issues/143

### "Async fns in traits" lang-team#150

**Link:** https://github.com/rust-lang/lang-team/issues/150

### "dyn* trait" lang-team#158

**Link:** https://github.com/rust-lang/lang-team/issues/158

### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160

**Link:** https://github.com/rust-lang/lang-team/issues/160

### "Initiative: Ghost types and blocks" lang-team#161

**Link:** https://github.com/rust-lang/lang-team/issues/161

### "Keyword generics" lang-team#162

**Link:** https://github.com/rust-lang/lang-team/issues/162

### "Add const evaluatable `where const { <block> }`" lang-team#163

**Link:** https://github.com/rust-lang/lang-team/issues/163

### "#[repr(Interoperable_2024)]" lang-team#165

**Link:** https://github.com/rust-lang/lang-team/issues/165

### "add `#[never_call]` attribute" lang-team#170

**Link:** https://github.com/rust-lang/lang-team/issues/170

## PRs on the lang-team repo
### "Note design constraints on hypothetical `DynSized`" lang-team#166

**Link:** https://github.com/rust-lang/lang-team/pull/166

### "Link to the agenda-generation front end" lang-team#167

**Link:** https://github.com/rust-lang/lang-team/pull/167

Merged!

### "Add planning meeting agenda-generation link" lang-team#168

**Link:** https://github.com/rust-lang/lang-team/pull/168

Merged!

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**
### "Tracking issue for `..X`, and `..=X` (`#![feature(half_open_range_patterns)]`)" rust#67264

- **Link:** https://github.com/rust-lang/rust/issues/67264
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/67264#issuecomment-1209771069):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
>
> Concerns:
>
> * rust-reference (https://github.com/rust-lang/rust/issues/67264#issuecomment-1217057223)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/67264#issuecomment-1209771052):
> @rfcbot merge
>
> We discussed this in a (not-so-recent) lang team meeting. My recollection of the consensus was that it wasn't obvious that there's a lint here obviously-valuable enough to block the existence of the feature on having it. (And, by analogy, you don't have to write `x <= 0 || x < 2` for signed numbers, just `x < 2` is enough, so a `..=2` pattern seems enough as well.) As such, I propose that we just accept this as a feature, and let people propose lints once we find out whether there's actually any confusion that results from it.
>
> Especially since patterns like this are the only way to use exhaustive matching on `isize` without a catch-all, the same way that `X..` patterns are the only way to do exhaustive matching on `usize` without a catch-all.
>
> (As an example for lints, I'd happily turn on a lint for something like "hey, that `..X` could be `0..X` because the type is unsigned", since that's easy to read+type and exhaustive integer patterns allow that without an extra wildcard arm. That would then mean that `..2` that's *not* `0..2` would subtly hint that it's signed. But that's not something I think this feature should be *blocked* on having, nor is it even something I would necessarily say belongs as warn-by-default in rustc.)

### "Tracking Issue for `#[instruction_set]` attribute (RFC 2867)" rust#74727

- **Link:** https://github.com/rust-lang/rust/issues/74727
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/74727#issuecomment-1202855460):
> Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * documentation-pr (https://github.com/rust-lang/rust/issues/74727#issuecomment-1217055285)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/74727#issuecomment-1202855405):
> Okay, I reviewed the update from last year and fixed the first godbolt link (`asm!` has stabilized since it had been posted).
>
> Its an interesting question, whether to stabilize something that has clear performance issues (in terms of not meeting typical zero-cost expectations). But that is a quality-of-life issue; if users can find utility in this feature even in its current state, then that's an argument for stabilization.
>
> I'll go ahead and fire off a stabilization FCP.
>
> @rfcbot fcp merge

### "Tracking Issue for asm_sym" rust#93333

- **Link:** https://github.com/rust-lang/rust/issues/93333
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/93333#issuecomment-1182038632):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * rust-reference (https://github.com/rust-lang/rust/issues/93333#issuecomment-1217057760)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/93333#issuecomment-1182038596):
> Shall we stabilize sym in `asm!`?
>
> @rfcbot merge
>
> EDIT: Link to above stabilization report: https://github.com/rust-lang/rust/issues/93333#issuecomment-1101813004

### "Stabilize `let else`" rust#93628

- **Link:** https://github.com/rust-lang/rust/pull/93628
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/93628#issuecomment-1029383585):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
>
> Concerns:
>
> * need-consistency-rvalue-temporary-rules-between-let-and-let-else (https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523)
> * ~~not-while-rustfmt-breaks-on-it~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1032936704
> * ~~semicolon~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1059799661
> * ~~stabilization-report~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1033846359
> * ~~summarize-concerns~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1056785904
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/93628#issuecomment-1029383577):
> Shall we stabilize `let else` syntax? We've had many demonstrated uses, including extensively throughout `rust-lang/rust`, we've seen the value of it, and there aren't any known issues with it.
>
> @rfcbot merge

### "Stabilize generic associated types" rust#96709

- **Link:** https://github.com/rust-lang/rust/pull/96709
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/96709#issuecomment-1181931476):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @compiler-errors
> * [ ] @cramertj
> * [x] @jackh726
> * [x] @joshtriplett
> * [ ] @lcnr
> * [x] @nikomatsakis
> * [x] @oli-obk
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [x] @spastorino
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/96709#issuecomment-1181931456):
> (snipped)

we'll cover this tomorrow!

### "Holding a non-Send Copy type across a yield should be allowed" rust#99104

- **Link:** https://github.com/rust-lang/rust/issues/99104
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/99104#issuecomment-1201982157):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * needs-exact-proposed-rule (https://github.com/rust-lang/rust/issues/99104#issuecomment-1209723811)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/99104#issuecomment-1201982136):
> @rfcbot merge

### "Fix `#[derive(Default)]` on a generic `#[default]` enum adding unnecessary `Default` bounds" rust#101040

- **Link:** https://github.com/rust-lang/rust/pull/101040
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/101040#issuecomment-1229165030):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/101040#issuecomment-1229165029):
> Nominating for discussion. Also kicking off an FCP: shall we remove the apparently unintended bound here?
>
> @rfcbot merge

scottmcm: isn't this libs-api? My head says a 3rd party crate could implement it as a proc-macro derive.

nikomatsakis: I tend to agree this is libs-api. Mechanism = lang, how it's used, libs-api?

scottmcm: I agree it should prob match the RFC, which I recall as saying "do not add that bound", but in the same way that "what should `derive(PartialOrd)` emit and should it override `ne`" was libs-api...so...

joshtriplett: happy to post a comment and start a libs-api FCP.

nikomatsakis: [the RFC did indeed say it](https://rust-lang.github.io/rfcs/3107-derive-default-enum.html#generated-bounds), seems like a bugfix to me... but agree about libs-api.

joshtriplett: indeed but I'd like to just get confirmation that it wasn't intentional.

scottmcm: this was one of the main questions that got settled in the RFC discussion as I recall; if it got changed, *somebody* should remember, as that would be a decision.

resolved: re-opened with libs-api.

## Active FCPs
### "Positional Associated Types" lang-team#126

**Link:** https://github.com/rust-lang/lang-team/issues/126

### "Interoperability With C++ Destruction Order" lang-team#135

**Link:** https://github.com/rust-lang/lang-team/issues/135

### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143

**Link:** https://github.com/rust-lang/lang-team/issues/143

### "Async fns in traits" lang-team#150

**Link:** https://github.com/rust-lang/lang-team/issues/150

### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160

**Link:** https://github.com/rust-lang/lang-team/issues/160

### "Initiative: Ghost types and blocks" lang-team#161

**Link:** https://github.com/rust-lang/lang-team/issues/161

### "Keyword generics" lang-team#162

**Link:** https://github.com/rust-lang/lang-team/issues/162

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "Consider `#[must_use]` annotation on `async fn` as also affecting the `Future::Output`" rust#100633

**Link:** https://github.com/rust-lang/rust/pull/100633#issuecomment-1220134323

> @rustbot label +I-lang-nominated
>
> Lang team, are you ok with expanding the meaning of `#[must_use]` on _both_ of the following?
>
> * `#[must_use] async fn foo() -> T`
> * `#[must_use] fn foo() -> impl Future<Output = T>`
>
> In each case the target of the attribute is `T`.
>
> I think this is a win for users (and doing otherwise would be a potential performance/implementation headache), but it relates to some questions about how it might interact with future expansions of `#[must_use]`.
>
> 1. `#[must_use] fn foo() -> F` where `F: Future<Output = T>`
> 2. Generalizing to other traits marked `#[must_use]`
> 3. Generalizing to `#[must_use]` wrapper types, like `Result<T, E>`
> 4. Finding a solution that works for e.g. `Option<T>` (not must_use)
>
> See this [#t-lang thread](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/.23.5Bmust_use.5D.20on.20async.20fn.20and.20-.3E.20impl.20Future.20.23100633) for more context.

tmandry: a PR applies `#[must_use]` to an async function, but also any function that returns a future; we now apply it to the output of the future.

joshtriplett: definitely had a lot of discussion before about when we would expand `#[must_use]` to the "innards" of a type.

nikomatsakis: slightly different though.

tmandry: I wanted to nominate it because it could have implications for future expansions we might want to make. Overall I think this is a positive change in isolation, really a matter of considering whatever knock-on effects there may be. I'm in favor of the change but I wanted to check for concerns before moving forward.

joshtriplett: If type T is must-use, that will already work, right? You do `.await` and if you don't assign it to something, it'll trip over must-use.

tmandry: Do you mean the future itself?

joshtriplett: No, the type that is the output of the future... e.g., an async fn that returns a `Result`, what happens if you just await but don't `?` mark it?

joshtriplett: So the problem is that `#[must_use]` when applied to the fn...

tmandry: ...will make the future must-use, which it already is, and we already warn about it.

joshtriplett: only conflict I could see is if we had a mechanism in the future for managing must-use inheritance?

tmandry: did have a thread on zulip discussing some possibilities. for example I like the idea of must-use being applied to a type.

nikomatsakis: feels like an orthogonal consideration to me. Anything that put `#[must_use]` on a type would change one axis, but must-use on a function indicates the must-use-ness comes from the fn that was called.

tmandry: I'm saying you might have a proposal that lets you change what must-use means on the type. e.g.,

#[must_use]
enum Result<T, E> {
    Ok(#[must_use_applies] T),
    Err(E),
}

#[must_use]
fn foo() -> Result<usize, E> { ... }

foo().unwrap(); // Error
foo()?; // Error

joshtriplett: does anybody think we shouldn't have a way for `#[must_use]` to apply to the result of an async fn?

scottmcm: I would say something weaker, it is a valuable warning for when someone isn't using the result of an async fn?

joshtriplett: just clarifying, does anybody think it should not be POSSIBLE to make "output" of a future must-use?

scottmcm: makes sense to me, but I wonder if it should also be true for `?`. Same way that `?` applied to a `Result` gives back the main value, maybe I want to say that *it* is must-use?

joshtriplett: this feels a bit like a problem of our own making, in that we don't have a `try fn` that makes it "look" as though it returned the ok type, whereas we do for async function.

scottmcm: agree that this is a way to distinguish async fn from try.

joshtriplett: I'm comfortable with saying that async fn is special, given that it has its own syntax. (ed: paraphrased a bit, but hopefully accurately)

scottmcm: must-use on async fn feels obvious to me, because everything with async fn should be as close as possible, but `-> impl Trait` doesn't have that case. Not a 1-way door, we could change it.

joshtriplett: we don't have to stabilize the mechanism, just the effects.

scottmcm: other thing that makes me ponder about the impl trait thing, if you put `#[must_use]` on a fn that returns `Result` today, you get a warning, part of me says that `impl Trait` is analogous...

tmandry: ... I think we do warn about that, we certainly do for async fn.

joshtriplett: I'm in favor of opening up some experimentation here. If we currently warn about it, we could leave that warning in place and add a feature-gate, which gives us the ability to stabilize later. Presumably that's feasible?

tmandry: Right?

simulacrum: a feature-gate here appears likely to produce very little feedback. The amount of people that will opt in to nightly for the marginal benefit here feels limited.

joshtriplett: Fair. Another option is to make it insta-stable and have a feature-gated mechanism for declaring it, then people could experiment to see if this would be useful on anything other than Future.

simulacrum: It was my impression that it's not something that is able to be generic, you need a fairly concrete implementation.

tmandry: impl is special cased on whether it returns an opaque type returning something that implements future.

nikomatskais: it feels like this is clearly useful and there's a perfect-enemy-of-good phenomenon to block progress because of the behavior for `?` functions.

joshtriplett: my only half concern is "are we prepared to commit to having a mechanism for things other than future" -- we either have to have a mechanism or decide that future is a special case?

pnkfelix: why? if somebody wants to have a more general design in the future, they can do it, but we're not committing to anything by approving this PR.

joshtriplett: right, but if we approve the PR, we are accepting that we have special cased future on an ongoing basis.

pnkfelix: right, but we still have the option of creating a more genreal design later.

joshtriplett: right, I'm just saying we have to be comfortable with the surface area we are stabilizing.

nikomatsakis: I think the answer for my part is just "yes", this is a best-effort lint to avoid bugs, it's not deeply integrated into the type system, I want it to be useful.

joshtriplett: the one thing I would want to avoid is encouraging people to use must-use and then breaking it later by making it redundant.

nikomatsakis: I can't really imagine people applying `#[must_use]` to an async function without meaning this.

joshtriplett: then let's start an FCP. Warning: currently tagged t-compiler.

in meeting: scottmcm, joshtriplett, nikomatsakis agree to have pnkfelix check boxes.

scottmcm: meta-comment: I feel like we're going more and more to the "must use everything" approach, would love to see somebody come up with a plan that doesn't mean that everybody puts must-use on almost everything.

nikomatsakis: everything that's not unit is must-use!

scottmcm: we have a lint that does that ...

nikomatsakis: I don't really feel like everything is must-use in the code that I write.

scottmcm: afaik basically nobody uses the "you must use everything" version of the lint.

nikomatsakis: I guess scott you're proposing a "need not use" sort of lint?

scottmcm: I feel like there ought to be some sort of heuristic about your argument and return types, e.g., if you only pass in frozen stuff, you ought to be using the response, etc etc.

joshtriplett: it sounds like you're saying we should detect pure functions and say they should be must-use?

scottmcm: detect pure feels fairly strong, but yes.

nikomatsakis: ...or you could imagine analyzing where must-use is being used and looking for patterns.

joshtriplett: needs moar ML/AI (kidding)

scottmcm: similar to how lifetime elision tried to identify patterns used in practice. could imagine something similar for must-use.

nikomatsakis: would be stronger if we could correlate to things causing bugs in practice.

tmandry: read API! it has a clippy lint.

### "De-RFC: Remove type ascription" rfcs#3307

**Link:** https://github.com/rust-lang/rfcs/pull/3307

joshtriplett, punning: let's remove type ascription, it's a pain in the colon! Gets in the way of parsing and good error messages, don't seem to have a path for stabilizing type ascription in its current form. Proposal is to remove it, stop parsing it, and if somebody wants to make a design for it, they can write a new RFC, probably using a different syntax.

Also read the section headings of the RFC, which are edited and amusing.

nikomatsakis: we've talked about, in backlog bonanza, removing older features that are not seeing motion. I'm in favor from that perspective.

joshtriplett: the RFC points out that the current syntax doesn't fit into a method chain.

scottmcm: I still want this, and `:` was the only obvious syntax, but I can't disagree that it's old, and we never resolved the coercion point questions, doesn't seem to be stabilization track.

joshtriplett: I also really want this, but not with this syntax. Some of the proposed syntaxes: `.keyword::<T>` or `.::<T>` or `.<T>`.

scottmcm: if we successfully moved as into library methods, could use `as`...

joshtriplett: ...could also make `.as` be ascription, but it'd be confusing.

nikomatsakis: sounds like we should FCP merge this?

joshtriplett: agree but I wanted to give people a chance to leap to the rescue of type ascription.

scottmcm: I kind of want to, but I can't jump that far.

joshtriplett: started an FCP

### "Regression transmuting `RwLockReadGuard<T: ?Sized>`." rust#101081

**Link:** https://github.com/rust-lang/rust/issues/101081

simulacrum: some stdlib change caused a problem transmuting. the nomination for lang is whether or not we can always transmute between two different types that vary only by lifetime. Brought up by me suggesting we want to forbid transmuting stdlib types in general because we keep hitting people doing that and not knowing that they're going to break. Not time sensitive though in the sense that we are not going to be rollback the change.

joshtriplett: I remember us agreeing that there would be an error if you transmute between things of known different sizes... what does `?Sized` have to do with this?

simulacrum: that's because you can't transmute things with generics, have to do pointer casting.

joshtriplett: did this work before but doesn't work now?

joshtriplett: I would be in favor of some kind of crater run that detects how much breakage we'd get if we banned transmuting stdlib types.

## Nominated RFCs, PRs and issues NOT discussed this meeting
### "RFC: Statics in patterns" rfcs#3305

**Link:** https://github.com/rust-lang/rfcs/pull/3305

### "Tracking issue for RFC 2383, "Lint Reasons RFC"" rust#54503

**Link:** https://github.com/rust-lang/rust/issues/54503

### "Tracking issue for `std::hint::black_box`" rust#64102

**Link:** https://github.com/rust-lang/rust/issues/64102

### "Tracking issue for dyn upcasting coercion" rust#65991

**Link:** https://github.com/rust-lang/rust/issues/65991

### "`#[track_caller]` erroneously points to macro call" rust#95152

**Link:** https://github.com/rust-lang/rust/issues/95152

### "Implement pointee metadata unsizing via a TypedMetadata<T\> container" rust#97052

**Link:** https://github.com/rust-lang/rust/pull/97052

### "Loosen shadowing check inside macro contexts (attempt 2)." rust#100453

**Link:** https://github.com/rust-lang/rust/pull/100453

### "let_chains desugaring is wrong" rust#100513

**Link:** https://github.com/rust-lang/rust/issues/100513

### "repr(transparent) could accept singleton ZST with alignment > 1." rust#100954

**Link:** https://github.com/rust-lang/rust/issues/100954