---
# System prepended metadata

title: Triage meeting 2024-08-28
tags: [triage-meeting, T-lang, minutes]

---

---
title: Triage meeting 2024-08-28
tags: ["T-lang", "triage-meeting", "minutes"]
date: 2024-08-28
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Design.20meeting.202024-08-28
url: https://hackmd.io/9Jpc-qoxQPqGcuLkLuFpEw
---

# T-lang meeting agenda

- Meeting date: 2024-08-28

## Attendance

- People: TC, Josh, scottmcm, tmandry, nikomatsakis, eholk, Santiago, Xiang, Urgau, CE

## Meeting roles

- Minutes, driver: TC

## Scheduled meetings

- 2024-08-28: Extended triage
- 2024-09-04: "Planning meeting: 2024-09-04" [#285](https://github.com/rust-lang/lang-team/issues/285)

Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.

## Announcements or custom items

(Meeting attendees, feel free to add items here!)

### Guest attendee items

TC: For any guests who are present, please note in this section if you're attending for the purposes of any items on (or off) the agenda in particular.

### Moving right along

TC: As we've been doing recently, due to the impressive backlog, I'm going to push the pace a bit.  If it's ever too fast or you need a moment before we move on, please raise a hand and we'll pause.

### Design meeting at 12:30 EST / 09:30 PST / 17:30 CET

TC: Remember that we have a design/planning meeting that starts half an hour after this call ends.

### Next meeting with RfL

We're next meeting with RfL on 2024-08-28 to review the status of RfL project goals.

https://github.com/rust-lang/rfcs/pull/3614

## Rust 2024 review

Project board: https://github.com/orgs/rust-lang/projects/43/views/5

None.

### Meta

TC: We have tracking issues for the Rust 2024 aspects of every item queued for the edition:

https://github.com/rust-lang/rust/issues?q=label%3AA-edition-2024+label%3AC-tracking-issue

For each item, we've identified an *owner*.

Our motivating priorities are:

- Make this edition a success.
- Do so without requiring heroics from anyone.
    - ...or stressing anyone or everyone out.

The current timeline is:

| Date       | Version       | Edition stage                  |
|------------|---------------|--------------------------------|
| 2024-09-05 | Release v1.81 | Checking off items...          |
| 2024-10-11 | Branch  v1.83 | Go / no go on all items        |
| 2024-10-17 | Release v1.82 | Rust 2024 nightly beta         |
| 2024-11-22 | Branch  v1.84 | Prepare to stabilize...        |
| 2024-11-28 | Release v1.83 | Stabilize Rust 2024 on master  |
| 2025-01-03 | Branch  v1.85 | Cut Rust 2024 to beta          |
| 2025-01-09 | Release v1.84 | Announce Rust 2024 is pending! |
| 2025-02-20 | Release v1.85 | Release Rust 2024              |

### Tracking Issue for Lifetime Capture Rules 2024 (RFC 3498) #117587

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

TC: With precise capturing now in FCP, this is in good shape for the edition.

### Reserve gen keyword in 2024 edition for Iterator generators #3513

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

TC: This item is now ready for Rust 2024.

### Tracking issue for promoting `!` to a type (RFC 1216) #35121

**Link:** https://github.com/rust-lang/rust/issues/35121
**Link:** https://github.com/rust-lang/rust/pull/123508

TC: This item is now ready for Rust 2024.

## Nominated RFCs, PRs, and issues

### "Tracking Issue for updating `expr` macro fragment specifier for Rust 2024" rust#123742

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

TC: Should we name this new specifier `expr_2015` instead?

Josh: +1 to that.

eholk: Or we could add `expr_2015` and `expr_2018` and `expr_2021` and make them all synonyms.

Josh: Probably that'd add confusion.

scottmcm: To confirm, we're not expecting people to ever used these after the migration.

TC: Correct.

scottmcm: I could go either way on it.  Since people are only seeing this during the migration.

NM: We could always add more aliases.  They're both OK. I vaguely prefer `2021` because it feels more like what people might expect, even though `2015` is strictly speaking more correct (basically naming it after the time it changed, vs the time it was introduced).

tmandry: I could go either way also.  If there were more than one, I'd like 2021 better.

NM: That's compelling to me.  I like that.  People shouldn't have to look up when it was introduced.  When something exists, it should exist forever.  It makes more sense in that light to name it after when it changed.

TC: We'll name this `expr_2021` then, it'll be available in all editions, and we'll get this stabilized in all editions as soon as possible.

### "Make destructors on `extern "C"` frames to be executed" rust#129582

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

Related:

- https://github.com/rust-lang/rust/issues/123231

TC: On Rust 1.80, this code:

```rust
struct Noise;
impl Drop for Noise {
    fn drop(&mut self) {
        eprintln!("Drop!");
    }
}

extern "C" fn test() {
    let _v = Noise;
    panic!("panic");
}

fn main() {
    test();
}
```

...has undefined behavior.  We didn't support unwinding from an `extern "C" fn`.  But, in practice, on most platforms, it would print:

```
panic
Drop!
```

In Rust 1.81, we stabilized `c_unwind`, and we decided that unwinding within an `extern "C" fn` is defined to cause an abort.  But we were a bit vague about when that abort should happen.  Should it abort immediately, or when the unwind hits the function boundary?

Rust 1.81 currently aborts immediately, so it just prints:

```
panic
```

Aborting immediately is a bit weird, as then moving the body to an inner function, like this:

```rust
extern "C" fn test() {
    fn inner() {
        let _v = Noise;
        panic!("panic");
    }
    inner()
}
```

...changes the semantics appreciably, and prints:

```
panic
Drop!
```

To solve this, and other issues discussed, including 2-phase unwinding, RalfJ proposes a particular semantic:

> I think we should guarantee that we run all destructors during unwind, and leave room for "unwind might fail to initiate and abort immediately instead" to account for 2-phase unwinding. That's reasonably easy to understand. This is currently not the case but #129582 implements that, IIUC.
>
> I'm not aware of any code that would _rely_ on the abort happening "early", i.e. skipping some destructors. On current stable, the destructor in the OP example actually does run, so the proposed guarantee (implemented by #129582) is also closer to the status quo than what happens in current beta.

That sounds right to me, and I've proposed FCP merge.

TC: What do we think?

TC: We also need to decide what to do about Rust 1.81.  Are we OK stabilizing `c_unwind` with a note that the behavior has gone from undefined to semi-defined (and that we'll be defining it further later, e.g. in Rust 1.82 / Rust 1.83)?

NM: I like RalfJ's proposal.  On the Rust 1.81 situation, I feel like we have multiple options and it'd be fine.

scottmcm: If it's UB, then we don't need to worry about what it does in Rust 1.81.  If putting it in an inner function changes the behavior, that is weird, and we should fix that.

Josh: As long as we can ship a future version that's better about running these destructors, I don't think we necessarily need to guarantee it, and it's OK to ship what we have in Rust 1.81.

pnkfelix: I'm trying to figure out whether we should guarantee less here and say only something to the effect of what order the destructors will run without guaranteeing anything about whether any run.

tmandry: I'm inclined to go ahead and specify what RalfJ proposes.

Josh: I feel like we might want some third option, a maybe abort of kinds.

tmandry: That's the 2-phase unwinding though.  That's what we're leaving space for here.  We could always then later stabilize the 2-phase unwinding on all platforms.

NM: It feels like there's a cost to users when we leave space for ourselves by leaving space.  It seems like we should do that when we see something worth leaving space for.  I'm not seeing that here.

Josh: I feel like we should leave more space there for functions that may possibly abort.

NM: The language I'm proposing is that it either runs all, or it runs nothing, and that we may later add a new unwinding mode, but if we do that, it'll have to take into account that code may have already relied on the earlier rule.

TC: See also:

- https://github.com/rust-lang/reference/pull/1226

TC: Checkboxes are here:

- https://github.com/rust-lang/rust/pull/129582#issuecomment-2313670698

TC: OK, I'll update my FCP comment to reflect the idea that we may later add new unwinding modes.

TC: ...and this will go into FCP.

### "Decide whether we want MSRV-gating" rust#129445

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

TC: There's an open proposal to add an `--msrv` flag to the compiler:

- https://github.com/rust-lang/compiler-team/issues/772

The idea is that this could be used, in a similar way to the current `--edition` flag, to gate lints based on the MSRV.

Since lang approves new lints and how they are gated, it seems that it might be helpful to T-compiler to know whether and how lang might intend to use this gating.

This is probably inspired at least partially by:

- https://github.com/rust-lang/rust/issues/129031

TC: What do we think?

CE: This flag has turned into a bit of a kitchen sink of how people think it might be used.  Callin the flag `msrv` gives people the wrong idea of what it can or should be used for.  The flag should give people the idea that it's best effort and that it's for lints.

Josh: I don't think we want to declare for all time that this will be used for lints and nothing else.  We'd be adding a general mechanism to the compiler and a way for Cargo to pass this in to the compiler.

CE: Maybe I'd be happy if one of the two parts were addressed.

Josh: We could call it `--hint-msrv`.

CE: That'd be fine.

(The first part of the meeting ended here.)

---

(The second part of the meeting starts here.)

People: TC, tmandry, Josh, scottmcm, pnkfelix, CE, eholk, Xiang, Urgau, Abdou

TC: tmandry, tell us if you would about what you proposed here:

https://github.com/rust-lang/rust/issues/129445#issuecomment-2307909872

tmandry: (Summary.)

TC: What are the use cases for the separate `lint-version` and `msrv`?

tmandry: (Summary to the effect of the use cases within a large monorepo.)

TC: It seems we should write down a policy here and that may be helpful to T-compiler.

TC: So we're agreeing?:

- We want some kind of `*msrv*` flag.
- We'd plan to use it for best-effort gating of certain lints.

NM: I think, if we could use this for maintaining compatibility with older things, we should use it for that.  It seems we should set out what goals we intend for this to serve.

Josh: Mainly, the goal I want here is for Cargo to provide the information it has to the compiler.

### "Don't warn empty branches unreachable for now" rust#129103

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

Related:

- https://github.com/rust-lang/rust/issues/129031

TC: Here's some code we accept:

```rust
fn main() {
    enum Empty {}
    match None::<Empty> {
        None => {}
        _ => unreachable!(),
    }
}
```

We can see that unreachable arm is actually unreachable, but Rust 1.81 can't.  However, Rust 1.82 can see this, so that arm isn't needed and we can write:

```rust
fn main() {
    enum Empty {}
    match None::<Empty> {
        None => {}
    }
}
```

Of course, this also means that if we do write the arm, it's an `unreachable_pattern`:

```rust
fn main() {
    enum Empty {}
    match None::<Empty> {
        None => {}
        _ => unreachable!(), //~ WARN unreachable pattern
    }
}
```

If we don't want to remove the arm, e.g. so we can maintain an MSRV, we can add an `allow` on that arm:

```rust
fn main() {
    enum Empty {}
    match None::<Empty> {
        None => {}
        #[allow(unreachable_patterns)]
        _ => unreachable!(), //~ WARN unreachable pattern
    }
}
```

[We discussed this 2024-08-14](https://hackmd.io/Ctx21X_CRNe9u3-G6-NjPQ#unreachable_patterns-lint-due-to-min_exhaustive_patterns-rust129031).  We considered proposals such as not firing the lint on these unreachable patterns until Rust 2024.  However, we decided that we wanted to lint this case even though we were moving directly from requiring these arms to linting against them.  Our feeling at the time, among those present, was that this was the purpose of lints, to move along the language in this way and communicate to users the changes.

After that discussion, some things happened:

- Josh put up a proposal for a general MSRV-gating mechanism.
  - https://github.com/rust-lang/rust/issues/129445
- There was temporarily a belief some cases couldn't be handled in a reasonable way.  See here for analysis:
  - https://github.com/rust-lang/rust/issues/129352#issuecomment-2306137856
- libs-api took some heat for breaking 5400 crates in Rust 1.80.
  - https://github.com/rust-lang/rust/issues/127343

The set of options seems to include:

1. Do what we had planned and fire the lint on all unreachable patterns.
2. Don't fire the lint on these unreachable patterns indefinitely, or at least for now.
3. Don't fire the lint on these unreachable patterns until Rust 2024.
  - Maybe consider later firing them in all editions.
4. Don't fire the lint on these unreachable patterns until a crate raises its MSRV to Rust 1.82.

An additional wrinkle is that we're continuing to improve exhaustiveness checking, so even if we split the lint, we'd expect to encounter more or less this same quandary in the future.

Josh has proposed FCP to not lint on these unreachable patterns.

TC: What do we think?

Nadri: I propose that we revert the linting behavior to what it was prior to stabilizing `min_exhaustive_patterns`, before the stabilization makes it to stable; to avoid unnecessary churn for users.

Nadri: that gives us more time to decide how we want to handle this.

scottmcm: I'm fine with delaying the lint; compiler can always do that based on quality issues.  Personally, I liked splitting it.

CE: I'd still like to split the lint.

Nadri: Unfortunately, splitting the lint is difficult, as we do a analysis that is global to a match expression.

### "Update `catch_unwind` doc comments for `c_unwind`" rust#128321

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

TC: Opsem has a proposal for us:

> Updates `catch_unwind` doc comments to indicate that catching a foreign exception _will no longer_ be UB. Instead, there are two possible behaviors, though it is not specified which one an implementation will choose.
>
> Nominated for t-lang to confirm that they are okay with making such a promise based on t-opsem FCP, or whether they would like to be included in the FCP.
>
> Related: #74990, #115285, [rust-lang/reference#1226](https://github.com/rust-lang/reference/pull/1226)

TC: What do we think?

TC: ...actually, this went into FCP.  We're good here.

### "const-eval interning: accept interior mutable pointers in final value" rust#128543

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

TC: RalfJ proposes to remove the lint in cases like:

```rust
pub enum JsValue {
    Undefined,
    Object(Cell<bool>),
}
impl Drop for JsValue {
    fn drop(&mut self) {}
}
// This does *not* get promoted since `JsValue` has a destructor.
// However, the outer scope rule applies, still giving this 'static lifetime.
const UNDEFINED: &JsValue = &JsValue::Undefined;
```

TC: What do we think?

NM: I think this is fine.  There is a caveat that RalfJ and I are going back and forth on.  That's somewhat separable from this though.

*some discussion and reviewing of https://github.com/rust-lang/unsafe-code-guidelines/issues/493#issuecomment-2028674105*

1. promotion can take a `&X` and make it static when value doesn't have any cells but the type does.
2. if the type has a cell, stacked borrows etc generally permit mutation (even changing what variant it is) in unsafe code at least (not UB).
3. but if pointer is pointing into static (read-only) memory, this will segfault, i.e., UB, which is bad.
4. ralf's preferred solution:
    - `const { &X }` and you've opted into the limitation that this is read-only.
    - this UB is still the result of not just the type but something provenance-like.
5. but today, if you do this, you hit a lint because we don't let you have an explicit const with a cell (presumably because of the above)
    - but we can't just remove the promotion which just does this, tons of stuff relies on it

tmandry: thinking aloud about local reasoning:

```rust!
pub enum JsValue {
    Undefined,
    Object(UnsafeCell<bool>),
}

impl JsValue {
    fn make_true(&self) {
        match self {
            Object(x) => {
                unsafe {
                    // Write to the cell
                }
            }
        }
    }
}

const X: &JSValue = const {
    let x = JSValue::Object(Cell::new(false));
    x.make_true(); // <-- ERROR: make_true is not const fn
    &x // <-- ERROR: Value has interior mutability, too
}

fn main() {
    X.make_true()
    // ^ Can't do UB because of the "value has inteior mutability" restriction.
}
```

..having to opt in to being a `const fn` preserves local reasoning with the unsafe. But also, we need to have the "value has interior mutability" restriction.

NM: I'll write a comment and clarify a point with RalfJ here, and then we'll revisit this next week.

### "Decide about generics in arbitrary self types" rust#129147

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

Over [here](https://github.com/rust-lang/rust/issues/44874#issuecomment-2292369151), @adetaylor gave an update about arbitrary self types that included this bit:

> During the preparation of the RFC it was broadly felt that we should ban "generic" self types but we didn't really define what "generic" meant, and I didn't pin it down enough.
>
> Some of the commentary:
>
> * [Arbitrary self types v2 rfcs#3519 (comment)](https://github.com/rust-lang/rfcs/pull/3519#discussion_r1390267286)
> * [Arbitrary self types v2 rfcs#3519 (comment)](https://github.com/rust-lang/rfcs/pull/3519#discussion_r1435282566)
> * [Arbitrary self types v2 rfcs#3519 (comment)](https://github.com/rust-lang/rfcs/pull/3519#discussion_r1474221554)
> * [A zulip comment](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Arbitrary.20self.20types.20v2.20RFC/near/416086169)
> * I've a feeling there's more which I've been unable to find, including the initial impetus to ban generics from arbitrary self types.
>
> It seems to be widely felt that:
>
> ```rust
> impl SomeType {
>  fn m<R: Deref<Target=Self>>(self: R) {}
> }
> ```
>
> would be confusing, but (per those comments) it's actually pretty hard to distinguish that from various legitimate cases for arbitrary self types with generic receivers:
>
> ```rust
> impl SomeType {
>   fn method1(self: MyBox<Self, impl Allocator>) {}
>   fn method2<const ID: u64>(self: ListArc<Self, ID>) {}
> }
> ```
>
> I played around with different tests here on the `self` type in `wfcheck.rs` but none of them yield the right sort of filter of good/bad cases (which is unsurprising since we haven't quite defined what that means, but I thought I might hit inspiration).
>
> From those comment threads, the most concrete proposal (from @joshtriplett) is:
>
> > just disallow the case where the top-level receiver type itself is not concrete.
>
> I plan to have a crack at that, unless folks have other thoughts. cc @Nadrieril who had opinions here.
>
> If we do this, I [might need to revisit the diagnostics mentioned in the bits of RFC _removed_ by this commit](https://github.com/rust-lang/rfcs/pull/3519/commits/fad04aee7e432acc31fb39464300debfa9abd244).

We never made a decision about this.  Perhaps if we could offer more clarity, it would save @adetaylor some time here, so it may be worth us discussing.

TC: What do we think?

tmandry: The cases marked as legitimate.  Are there known use cases?

NM: Yes, the examples there are like what the RfL people want.

Josh: The first case is marked as confusing, but I think we were also worried about resolution ambiguities.

TC: It'd be good to know whether there are or not.

NM: The rule Josh proposes, I could see being implemented, but I'm not sure what goal it serves.

Josh: Three cases:

1) Implementation difficulty? Apparently not, this was implemented.
2) Limiting the future evolution of the compiler. Unknown at this time.
3) Confusing for the human. Unknown at this time.

tmandry: I don't find number 3, the human bit compelling.  For me, the question of whether we'd be limiting future language evolution is something we should track down.

(The meeting ended here.)

---

### "Stabilize `&mut` (and `*mut`) as well as `&Cell` (and `*const Cell`) in const" rust#129195

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

TC: RalfJ proposes to stabilize `const_mut_refs`.

> This stabilizes `const_mut_refs`. That allows a bunch of things on stable:
>
> * Mentioning `&mut` types
> * Creating `&mut` and `*mut` values
> * Dereferencing `&mut` and `*mut` values (both for reads and writes)

(...and many more details he describes.)

TC: What do we think?

### "clarify that addr_of creates read-only pointers" rust#129653

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

TC: RalfJ proposes adding some language to the docs of `addr_of!` to the effect that it's currently UB to write:

```
fn main() {
    let x = &mut 0;
    let y: *const i32 = x;
    unsafe { *(y as *mut i32) = 1; }
    assert_eq!(*x, 1);
}
```

This is due to the fact that we implicitly first create a shared reference when coercing a `&mut` to a `*const`.  See:

- https://github.com/rust-lang/rust/issues/56604

It seems worth reminding ourselves of this situation, so I nominated it to discuss that and this language.

TC: What do we think?

### "Make deprecated_cfg_attr_crate_type_name a hard error" rust#129670

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

TC: est31 nominates for us to turn into a hard error:

```rust
#![cfg_attr(foo, crate_name = "foobar")]
#![cfg_attr(foo, crate_type = "bin")]
```

It's still allowed to write:

```rust
#![crate_name = "foobar"]
#![crate_type = "lib"]
```

This goes back to:

- https://github.com/rust-lang/rust/pull/83744

...which we did in Rust 1.59.

Then, in Rust 1.65, we made the lint `deny-by-default`:

- https://github.com/rust-lang/rust/pull/99784

TC: What do we think?

### "ill-typed unused FFI declarations can cause UB" rust#46188

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

TC: pnkfelix nominates for us:

> The proposed fixes for this issue might not practical, at least not without some help from the LLVM side, so we should consider what we want to do about this _as a language_.
>
> Members of T-compiler in particular suspect that merely issuing a hard error in response to a pair of FFI declarations with distinct types may not suffice; we suspect there are users who are relying on being able to do that, and there is some underlying notion of "compatible" pairs of types that is being used to justify such code.

TC: What do we think?

### "Emit error when calling/declaring functions with unavailable vectors." rust#127731

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

TC: RalfJ nominates for us:

> There's only 2 crates.io failures and they are both spurious. And the github failures I checked were also all spurious. So looking pretty good I would say. :)
>
> Seems like the next step process-wise is to check back in with the lang team, now that we have crater results. (That's based on [this message](https://github.com/rust-lang/lang-team/issues/235#issuecomment-1865489298).) @rust-lang/lang this aims to fix #116558, which is part of the discussion we had in [rust-lang/lang-team#235](https://github.com/rust-lang/lang-team/issues/235). The way it is fixed is by making it a hard error to call or declare an `extern "C"` function that passes a SIMD type by-value without enabling the target feature that enables SIMD vectors of the appropriate size. The reason it is made a hard error is that these functions end up having a different ABI depending on whether that target feature is enabled or not. "Rust" ABI functions are not affected as those functions pass SIMD vectors indirectly (they do that precisely to avoid these ABI issues).
>
> There are two points we'd like your take on:
>
> * How to stage this. Should it become a hard error immediately, or first be reported as a future-compat lint (I would say we can make it show up in dependencies immediately)? Crater found no regressions (probably because `extern "C"` functions are generally fairly rare), but of course crater doesn't see all the codebases out there.
> * What exactly should be checked? Right now, the check is extremely low-level and looks at the computed effective ABI of the function, ensuring it doesn't end up with a too large by-value SIMD vector argument. The check is done during monomorphization, each time a function is instantiated, to make sure that we can even know the actual effective ABI. More mono-time checks are unfortunate, but there's no good way to test this in generic code since we can't know whether a generic argument is a SIMD vector or not. Give that it should be rather rare to run into this, hopefully a mono-time check is acceptable.
>   The other concern is semver compatibility: if a library changes a public type, e.g., from being an array of `i32` to being a SIMD vector instead, that can now break downstream code. However, it can only break downstream code that passes types of this library by-value across an  `extern "C"`. If that is an FFI boundary, this is already extremely sketchy to do due to all the concerns around FFI safety and ABI compatibility. The most realistic scenario I could come up with is code using `extern "C"` for Rust-to-Rust calls; not sure how much we worry about such code -- I presume it is fairly rare. Still, we could try to mitigate this by making the check some sort of overapproxomation that generally refuses to pass types from other crates across an `extern "C"` boundary if those types could in the future be changed such that the ABI ends up with a by-value SIMD vector (i.e., `(i32, ForeignType)` would be okay but `TransparentWrapper<ForeignType>` would not). I personally am not convinced that is worth the effort.

TC: What do we think?

### "Lint against &T to &mut T and &T to &UnsafeCell<T> transmutes" rust#128351

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

TC: CE nominates for us a proposal by ChayimFriedman2:

> Conversion from `&` to `&mut` are and always were immediate UB, and we already lint against them, but until now the lint did not catch the case were the reference was in a field.
>
> Conversion from `&` to `&UnsafeCell` is more nuanced: Stacked Borrows makes it immediate UB, but in Tree Borrows it is sound.
>
> However, even in Tree Borrows it is UB to write into that reference (if the original value was `Freeze`). In all cases crater found where the lint triggered, the reference was written into.

More details here:

https://github.com/rust-lang/rust/pull/128351#issue-2435783651

TC: What do we think?

### "`optimize` attribute applied to things other than methods/functions/c…" rust#128943

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

TC: jieyouxu nominates for us:

> This needs a T-lang FCP since it diverges from the original [RFC 2412](https://github.com/rust-lang/rust/issues/54882) specified behavior. cc @rust-lang/lang
>
> ### Summary for T-lang
>
> **This PR proposes to elevate `#[optimize]` attribute (as specified in [RFC 2412](https://github.com/rust-lang/rfcs/blob/master/text/2412-optimize-attr.md)) applied to unsupported HIR nodes from a warn-by-default `unused_attributes` lint to a hard error.**

More details are here:

https://github.com/rust-lang/rust/pull/128943#issuecomment-2282357407

TC: What do we think?

### "Trait method impl restrictions" rfcs#3678

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

TC: Josh nominates a new RFC for us.  What do we think?

### "Simplify lightweight clones, including into closures and async blocks" rfcs#3680

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

TC: Josh nominates a new RFC for us.  What do we think?

### "edition lint: migrating `extern crate` with `#[macro_use]`" rust#52043

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

TC: Code like this today isn't idiomatic, since we would use `use` to import any macros, but it doesn't lint:

```
#[macro_use]
extern crate rayon;

fn main() { }
```

TC: Josh nominates as it seems perhaps beyond time that we do so.  What do we think?

### "Consider deprecation of UB-happy `static mut`" rust#53639

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

TC: Long ago, eddyb opened an issue to consider deprecating `static mut`.  This is because handling long-lived references to `static mut` items is hard to do right.

We decided for Rust 2024 to lint at `deny-by-default` against long-lived references to `static mut` items, thus apparently solving the problem that motivated opening the issue.  And there seem to be use cases for `static mut`.  As RalfJ says:

> Sometimes, you need global mutable state. We already had several cases of people being quite confused and concerned by the lints we started emitting, and it turns out that what they were doing is completely fine and we basically told them to add a bit of noise to their code to silence the lint. Those people will be even more confused if we now tell them that `static mut` will be banned entirely, and I am not convinced that replacing `addr_of_mut!(STATIC)` with `STATIC.get()` is really doing anything for ensuring the safety of global mutable state.
>
> Many people that use `static mut` now are entirely aware of what they are doing, they didn't accidentally stumble into global mutable state. People that just mindlessly run into `static mut` will equally mindlessly start using `SyncUnsafeCell` (probably by copying some online resource telling them how to silence that annoying borrow checker, or by following helpful compiler hints).
>
> So overall I am not convinced that the churn caused on existing code, and the overhead caused for people that know what they are doing, is balanced by a sufficient risk reduction for people that don't know what they are doing.

Given all this, it's hard to me to imagine that we've soon depracet `static mut`, so I propose FCP close.

TC: What do we think?

### "Tracking Issue for the C-cmse-nonsecure-call ABI" rust#81391

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

TC: T-compiler nominates for us:

> Nominating for both T-lang and T-compiler discussion: there is a request for the stabilization of the `C-cmse-nonsecure-call` ABI (posted above at [#81391 (comment)](https://github.com/rust-lang/rust/issues/81391#issuecomment-2258346708)), there's also the seemingly related `#[cmse_nonsecure_entry]` attribute (#75835). This is mostly nominated for several reasons stated below.
>
> For **T-compiler**:
>
> * Procedure questions:
>
>   * Does this need an MCP/FCP for stabilization, or does this need further design?
>   * Does this need a joint T-compiler/T-lang FCP?
> * We should help the people working on cmse-related things to find knowledgeable reviewers / domain experts who can help with reviewing the changes, or otherwise provide advice on how to split related PRs into smaller PRs that reviewers feel more confident to review. [add `extern "C-cmse-nonsecure-entry" fn`  #127766](https://github.com/rust-lang/rust/pull/127766) already got rerolled a bunch of times (currently, the dice landed on Wesley ^^).
>
> For **T-lang**:
>
> * Procedure questions:
>
>   * Does this need T-lang sign-off, like a T-lang FCP or a joint T-lang/T-compiler FCP?
>
> For **both T-compiler and T-lang**:
>
> * Is the cmse-related efforts being tracked anywhere?

TC: What do we think?

### "Tracking Issue for enum access in offset_of" rust#120141

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

TC: There's a proposed FCP merge for us:

https://github.com/rust-lang/rust/issues/120141#issuecomment-2161507356

TC: What do we think?

### "Fixup Windows verbatim paths when used with the `include!` macro" rust#125205

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

TC: Chris Denton asks us:

> On Windows, the following code can fail if the `OUT_DIR` environment variable is a [verbatim path](https://doc.rust-lang.org/std/path/enum.Prefix.html) (i.e. begins with `\\?\`):
>
> ```rust
> include!(concat!(env!("OUT_DIR"), "/src/repro.rs"));
> ```
>
> This is because verbatim paths treat `/` literally, as if it were just another character in the file name.
>
> The good news is that the standard library already has code to fix this. We can simply use `components` to normalize the path so it works as intended.
>
> I think it could just be considered a bug fix but it might also be considered a change in language.

TC: What do we think, is this a bug fix or a change to the language, and if the latter, do we want it?

### "Reword trait-object compatibility in rustdoc" rust#126554

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

TC: Josh nominates this for us.  What do we think?

### "Support for pointers with asm_const" rust#128464

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

TC: Josh nominates for us the question:

> Nominating this for lang to discuss the question of whether we should support use of `const` in `asm!` for things that can't just be textually substituted, or whether we should give that a different name.
>
> @Amanieu, any input you'd like to provide would be helpful.

To which Amanieu replies:

> After thinking about it a bit, I think it's probably fine to add this functionality to `const`. I'm a bit bothered about the duplication with `sym`, which is already stable.

TC: What do we think?

### "repr(int) fieldless enums are ABI-compatible with int" rust#128600

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

TC: RalfJ wants to extend some ABI compatibility guarantees.  What do we think?

### "Decide on name for `derive(SmartPtr)`" rust#129104

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

TC: We need to resolve the open question on:

- https://github.com/rust-lang/rfcs/pull/3621

...regarding what name to use.

Tracking:

- https://github.com/rust-lang/rust/issues/123430

TC: What do we think?

### "Stabilize `extended_varargs_abi_support`" rust#116161

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

TC: This stabilization was nominated for us, with pnkfelix commenting:

> Just to add on to @cjgillot 's comment above: @wesleywiser and I could not remember earlier today whether T-lang _wants_ to own FCP'ing changes like this that are restricted to extending the set of calling-conventions (i.e. the `conv` in `extern "conv" fn foo(...)`), which is largely a detail about what platforms one is interoperating with, and not about changing the expressiveness of the Rust language as a whole in the abstract.
>
> (My own gut reaction is that T-compiler is a more natural owner for this than T-lang, but I wasn't certain and so it seems best to let the nomination stand and let the two teams duke it out.)

TC: What do we think about 1) this stabilization, and 2) whether we want to own this?

### "Emit a warning if a `match` is too complex" rust#122685

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

TC: Nadri nominates this for us and describes the situation:

> Dear T-lang, this PR adds a warning that cannot be silenced, triggered when a match takes a really long time to analyze (in the order of seconds). This is to help users figure out what's taking so long and fix it.
>
> We _could_ make the limit configurable or the warning `allow`able. I argue that's not necessary because [crater](https://github.com/rust-lang/rust/pull/121979#issuecomment-2003089646) showed zero regressions with the current limit, and it's be pretty easy in general to split up a `match` into smaller `match`es to avoid blowup.
>
> We're still figuring out the exact limit, but does the team approve in principle?

(As an aside, awhile back someone [showed](https://niedzejkob.p4.team/rust-np/) how to [lower](https://github.com/NieDzejkob/rustc-sat) SAT to exhaustiveness checking with `match`.  Probably that would hit this limit.)

TC: What do we think?

### "Stabilize `count`, `ignore`, `index`, and `length` (`macro_metavar_expr`)" rust#122808

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

TC: c410-f3r proposes the following for stabilization:

> # Stabilization proposal
>
> This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically, the stabilization of `count`, `ignore`, `index` and `length`.
>
> ## What is stabilized
>
> ### Count
> The number of times a meta variable repeats in total.
>
```rust
macro_rules! count_idents {
    ( $( $i:ident ),* ) => {
        ${count($i)}
    };
}

fn main() {
    assert_eq!(count_idents!(a, b, c), 3);
}
```
>
> ### Ignore
> Binds a meta variable for repetition, but expands to nothing.
>
```rust
macro_rules! count {
    ( $( $i:stmt ),* ) => {{
        0 $( + 1 ${ignore($i)} )*
    }};
}

fn main() {
    assert_eq!(count!(if true {} else {}, let _: () = (), || false), 3);
}
```
>
> ### Index
> The current index of the inner-most repetition.
>
```rust
trait Foo {
    fn bar(&self) -> usize;
}

macro_rules! impl_tuple {
    ( $( $name:ident ),* ) => {
        impl<$( $name, )*> Foo for ($( $name, )*)
        where
            $( $name: AsRef<[u8]>, )*
        {
            fn bar(&self) -> usize {
                let mut sum: usize = 0;
                $({
                    const $name: () = ();
                    sum = sum.wrapping_add(self.${index()}.as_ref().len());
                })*
                sum
            }
        }
    };
}

impl_tuple!(A, B, C, D);

fn main() {
}
```
>
> ### Length
>
> The current index starting from the inner-most repetition.
>
```rust
macro_rules! array_3d {
    ( $( $( $number:literal ),* );* ) => {
        [
            $(
                [
                    $( $number + ${length()}, )*
                ],
            )*
        ]
    };
}

fn main() {
    assert_eq!(array_3d!(0, 1; 2, 3; 4, 5), [[2, 3], [4, 5], [6, 7]]);
}
```
>
> ## Motivation
>
> Meta variable expressions not only facilitate the use of macros but also allow things that can't be done today like in the `$index` example.
>
> An initial effort to stabilize this feature was made in #111908 but ultimately reverted because of possible obstacles related to syntax and expansion.
>
> Nevertheless, [#83527 (comment)](https://github.com/rust-lang/rust/issues/83527#issuecomment-1744822345) tried to address some questions and fortunately the lang team accept #117050 the unblocking suggestions.
>
> Here we are today after ~4 months so everything should be mature enough for wider use.
>
> ## What isn't stabilized
> `$$` is not being stabilized due to unresolved concerns.

TC: I asked WG-macros for feedback on this here:

https://rust-lang.zulipchat.com/#narrow/stream/404510-wg-macros/topic/Partial.20macro_metavar_expr.20stabilization

TC: Josh proposed FCP merge on this stabilization.

### "Add support for `use Trait::func`" rfcs#3591

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

This RFC would add support for:

```rust
use Default::default;

struct S {
    a: HashMap<i32, i32>,
}

impl S {
    fn new() -> S {
        S {
            a: default()
        }
    }
}
```

Josh has proposed FCP merge and has nominated.  There are outstanding concerns about the handling of turbofish and associated constants.

TC: What do we think?

### "Supertrait item shadowing v2" rfcs#3624

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

TC: On 2024-04-24, we had discussed (on a gut check basis) a proposal from Amanieu to change method resolution such that when both a subtrait and one of its supertraits are in scope, shadowed methods from the subtrait would be chosen rather than resulting in ambiguity errors.

Most notably, this would allow the standard library to uplift methods from `itertools`, which they've been deferring for years due to no way to do so without causing breakage.  But there are many other possible uses and reasons to believe this might be a good rule.

After our last discussion, we had asked for an RFC.  This is that RFC.  What do we think?

### "Tracking issue for the `start` feature" rust#29633

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

TC: Nils proposes to us that we delete the unstable `#[start]` attribute:

> I think this issue should be closed and `#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction.
>
> I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple:
>
> * `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail)
> * `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things _anyways_
>
> `#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on Windows, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program. So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving _any_ stability guarantees on), and where there's a pretty easy way to get things working without it in the first place.
>
> Note that this feature has **not** been RFCed in the first place.

TC: What do we think?

### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378

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

TC: We unnominated this back in October 2023 as more analysis seemed to be needed. Since then, nikomatsakis and tmandry have posted substantive analysis that it seems we should discuss.

### "#[cold] on match arms" rust#120193

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

TC: Apparently our unstable `likely` and `unlikely` intrinsics don't work.  There's a proposal to do some work on fixing that and stabilizing a solution here.  The nominated question is whether we want to charter this as an experiment.

### "Disallow deriving (other than Copy/Clone) on types with unnamed fields" rust#121270

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

TC: pnkfelix nominates this for us:

> This PR that addresses some ICEs arising for the unstable `feature(unnamed_fields)`, by conservatively mapping the ICE'ing cases to static errors instead.
>
> The T-compiler team wants to know the opinion of T-lang of whether `feature(unnamed_fields)` is sufficiently likely, in the near future, to be removed (or significantly reworked) to such a degree that it would make more sense to close this PR rather than have contributors spend further time on it.
>
> (See also the context established by https://hackmd.io/7r0i-EWyR8yO6po2LnS2rA#Tracking-issue-for-RFC-2102-Unnamed-fields-of-struct-and-union-type-rust49804 (where I think there was supposed to be an eventual writeup of the concerns people had with `feature(unnamed_fields)`) and [#49804 (comment)](https://github.com/rust-lang/rust/issues/49804#issuecomment-2106381721) )

On 2024-05-12, Josh said:

> It sounds like, from the minutes, that some folks would like to see this feature designed differently than it was when it was previously accepted. It wouldn't be the first or last feature to need some design adjustments when lang design met compiler reality. Happy to help with that, so that we can find a design that meets the requirements in the original RFC and any new issues that have arisen since then.

This is about RFC 2102:

https://github.com/rust-lang/rfcs/pull/2102

We discussed this in the meeting on 2024-06-12 without consensus.

Some felt that this was still needed, others first wanted to look for a more minimal approach.

We left this for further discussion.

TC: What do we think?

### "Skip pub structs with repr(c) and repr(transparent) in dead code analysis" rust#127104

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

TC: The background here is in:

- https://github.com/rust-lang/rust/issues/126169

TC: What do we think?

### "Tracking Issue for unicode and escape codes in literals" rust#116907

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

TC: nnethercote has implemented most of RFC 3349 ("Mixed UTF-8 literals") and, based on implementation experience, argues that the remainder of the RFC should not be implemented:

> I have a partial implementation of this RFC working locally (EDIT: now at #120286). The RFC proposes five changes to literal syntax. I think three of them are good, and two of them aren't necessary.

TC: What do we think?

### "Proposal: Remove `i128`/`u128` from the `improper_ctypes` lint" lang-team#255

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

TC: Trevor Gross describes the situation:

> For a while, Rust's 128-bit integer types have been incompatible with those from C. The original issue is here [rust-lang/rust#54341](https://github.com/rust-lang/rust/issues/54341), with some more concise background information at the MCP here [rust-lang/compiler-team#683](https://github.com/rust-lang/compiler-team/issues/683)
>
> The current Beta of 1.77 will have [rust-lang/rust#116672](https://github.com/rust-lang/rust/pull/116672), which manually sets the alignment of `i128` to make it ABI-compliant with any version of LLVM (`clang` does something similar now). 1.78 will have LLVM18 as the vendored version which fixes the source of this error.
>
> Proposal: now that we are ABI-compliant, do not raise `improper_ctypes` on our 128-bit integers. I did some testing with abi-cafe and a more isolated https://github.com/tgross35/quick-abi-check during the time https://reviews.llvm.org/D86310 was being worked on, and verified everything lines up. (It would be great to have some fork of abi-cafe in tree, but that is a separate discussion.)
>
> @joshtriplett mentioned that changing this lint needs a lang FCP https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/LLVM.20alignment.20of.20i128/near/398422037. cc @maurer
>
> Reference change from when I was testing [rust-lang/rust@c742908](https://github.com/rust-lang/rust/commit/c742908c4b9abde264b8c5e9663e31c649a47f2f)

TC: Josh nominates this for our discussion.  What do we think?

### "`is` operator for pattern-matching and binding" rfcs#3573

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

TC: Josh proposes for us that we should accept:

```rust
if an_option is Some(x) && x > 3 {
    println!("{x}");
}
```

And:

```rust
func(x is Some(y) && y > 3);
```

TC: The main topic discussed in the issue thread so far has been the degree to which Rust should have "two ways to do things".  Probably the more interesting issue is how the binding and drop scopes for this should work.

TC: In the 2024-02-21 meeting (with limited attendance), we discussed how we should prioritize stabilizing let chains, and tmandry suggested we may want to allow those to settle first.

TC: What do we think, as a gut check?

### "Unsafe fields" rfcs#3458

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

TC: Nearly ten years ago, on 2014-10-09, pnkfelix proposed unsafe fields in RFC 381:

https://github.com/rust-lang/rfcs/issues/381

On 2017-05-04, Niko commented:

> I am pretty strongly in favor of unsafe fields at this point. The only thing that holds me back is some desire to think a bit more about the "unsafe" model more generally.

Then, in 2023, Jacob Pratt refreshed this proposal with RFC 3458.  It proposes that:

> Fields may be declared `unsafe`. Unsafe fields may only be mutated (excluding interior mutability) or initialized in an unsafe context. Reading the value of an unsafe field may occur in either safe or unsafe contexts. An unsafe field may be relied upon as a safety invariant in other unsafe code.

E.g.:

```rust
struct Foo {
    safe_field: u32,
    /// Safety: Value must be an odd number.
    unsafe unsafe_field: u32,
}

// Unsafe field initialization requires an `unsafe` block.
// Safety: `unsafe_field` is odd.
let mut foo = unsafe {
    Foo {
        safe_field: 0,
        unsafe_field: 1,
    }
};
```

On 2024-05-21, Niko nominated this for us:

> I'd like to nominate this RFC for discussion. I've not read the details of the thread but I think the concept of unsafe fields is something that comes up continuously and some version of it is worth doing.

TC: What do we think?

### "RFC: Allow symbol re-export in cdylib crate from linked staticlib" rfcs#3556

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

TC: This seems to be about making the following work:

```rust
// kind is optional if it's been specified elsewhere, e.g. via the `-l` flag to rustc
#[link(name="ext", kind="static")]
extern {
    #[no_mangle]
    pub fn foo();

    #[no_mangle]
    pub static bar: std::ffi::c_int;
}
```

There are apparently use cases for this.

What's interesting is that apparently it already does, but we issue a warning that is wrong:

```rust
warning: `#[no_mangle]` has no effect on a foreign function
  --> src/lib.rs:21:5
   |
21 |     #[no_mangle]
   |     ^^^^^^^^^^^^ help: remove this attribute
22 |     pub fn foo_rfc3556_pub_with_no_mangle();
   |     ---------------------------------------- foreign function
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: symbol names in extern blocks are not mangled
```

TC: One of the author's asks of us is that we don't make this into a hard error (e.g. with the new edition).

TC: What do we think?

### "Better errors with bad/missing identifiers in MBEs" rust#118939

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

TC: The idea here seems to be to improve some diagnostics around `macro_rules`, but this seems to be done by way of reserving the `macro_rules` token more widely, which is a breaking change.  Petrochenkov has objected to it on that basis, given that reserving `macro_rules` minimally has been the intention since we hope it will one day disappear in favor of `macro`.  What do we think?

### "Uplift `clippy::invalid_null_ptr_usage` lint" rust#119220

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

TC: Urgau proposes this for us:

> This PR aims at uplifting the `clippy::invalid_null_ptr_usage` lint into rustc, this is similar to the [`clippy::invalid_utf8_in_unchecked` uplift](https://github.com/rust-lang/rust/pull/111543) a few months ago, in the sense that those two lints lint on invalid parameter(s), here a null pointer where it is unexpected and UB to pass one.
>
> ## `invalid_null_ptr_usages`
>
> (deny-by-default)
>
> The `invalid_null_ptr_usages` lint checks for invalid usage of null pointers.
>
> ### Example
>
```rust
// Undefined behavior
unsafe { std::slice::from_raw_parts(ptr::null(), 0); }
// Not Undefined behavior
unsafe { std::slice::from_raw_parts(NonNull::dangling().as_ptr(), 0); }
```
>
> Produces:
>
```
error: calling this function with a null pointer is undefined behavior, even if the result of the function is unused, consider using a dangling pointer instead
  --> $DIR/invalid_null_ptr_usages.rs:14:23
   |
LL |     let _: &[usize] = std::slice::from_raw_parts(ptr::null(), 0);
   |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^-----------^^^^
   |                                                  |
   |                                                  help: use a dangling pointer instead: `core::ptr::NonNull::dangling().as_ptr()`
```
>
> ### Explanation
>
> Calling methods who's safety invariants requires non-null pointer with a null pointer is undefined behavior.
>
> The lint use a list of functions to know which functions and arguments to checks, this could be improved in the future with a rustc attribute, or maybe even with a `#[diagnostic]` attribute.

TC: What do we think?

### "Uplift `clippy::double_neg` lint as `double_negation`" rust#126604

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

TC: This proposes to lint against cases like this:

```
fn main() {
    let x = 1;
    let _b = --x; //~ WARN use of a double negation
}
```

TC: What do we think?

### "Language vs. implementation threat models and implications for TypeId collision resistance" rust#129030

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

TC: We use SipHash-1-3-128 in Rust for hashing types to form TypeIds.  If these TypeIds collide in a single program, UB may result.

If SipHash-1-3-128 is a secure PRF, then the probability of such collisions happening accidentally in a program that contains an enormous 1M types is one in 2^-89.

But, if someone wanted to brute-force a collision -- that is, find two entirely random types that would have the same TypeId -- the work factor for that is no more than about 2^64 on average.

The question being nominated for lang is whether we consider that good enough for soundness, for now.

TC: What do we think?

### "Lang discussion: Item-level `const {}` blocks, and `const { assert!(...) }`" lang-team#251

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

TC: This issue was raised due to discussion in a T-libs-api call.  Josh gives the context:

> In discussion of [rust-lang/libs-team#325](https://github.com/rust-lang/libs-team/issues/325) (a proposal for a compile-time assert macro), the idea came up to allow `const {}` blocks at item level, and then have people use `const { assert!(...) }`.
>
> @rust-lang/libs-api would like some guidance from @rust-lang/lang about whether lang is open to toplevel `const { ... }` blocks like this, which would influence whether we want to add a compile-time assert macro, as well as what we want to call it (e.g. `static_assert!` vs `const_assert!` vs some other name).
>
> Filing this issue to discuss in a lang meeting. This issue is _not_ seeking any hard commitment to add such a construct, just doing a temperature check.

CAD97 noted:

> To ensure that it's noted: if both item and expression `const` blocks are valid in the same position (i.e. in statement position), a rule to disambiguate would be needed (like for statement versus expression `if`-`else`). IMO it would be quite unfortunate for item-level `const` blocks to be evaluated pre-mono if that same `const` block but statement-level would be evaluated post-mono.
>
> Additionally: since `const { assert!(...) }` is post-mono (due to using the generic context), it's potentially desirable to push people towards using `const _: () = assert!(...);` (which is pre-mono) whenever possible (not capturing generics).

TC: What do we think?

### "Add lint against function pointer comparisons" rust#118833

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

TC: In the 2024-01-03 call, we developed a tentative consensus to lint against direct function pointer comparison and to push people toward using `ptr::fn_addr_eq`.  We decided to ask T-libs-api to add this.  There's now an open proposal for that here:

https://github.com/rust-lang/libs-team/issues/323

One question that has come up is whether we would expect this to work like `ptr::addr_eq` and have separate generic parameters, e.g.:

```rust
/// Compares the *addresses* of the two pointers for equality,
/// ignoring any metadata in fat pointers.
///
/// If the arguments are thin pointers of the same type,
/// then this is the same as [`eq`].
pub fn addr_eq<T: ?Sized, U: ?Sized>(p: *const T, q: *const U) -> bool { .. }
```

Or whether we would prefer that `fn_addr_eq` enforced type equality of the function pointers.  Since we're the ones asking for this, we probably want to develop a consensus here.  We discussed this in the call on 2024-01-10, then we opened a Zulip thread:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Signature.20of.20.60ptr.3A.3Afn_addr_eq.60

TC: On this subject, scottmcm raised this point, with which pnkfelix seemed to concur:

> I do feel like if I saw code that had `fn1.addr() == fn2.addr()` (if `FnPtr` were stabilized), I'd write a comment saying "isn't that what `fn_addr_eq` is for?"
>
> If the answer ends up being "no, actually, because I have different types", that feels unfortunate even if it's rare.
>
> (Like how `addr_eq(a, b)` is nice even if with strict provenance I could write `a.addr() == b.addr()` anyway.)

TC: scottmcm also asserted confidence that allowing mixed-type pointer comparisons is correct for `ptr::addr_eq` since comparing the addresses of `*const T`, `*const [T; N]`, and `*const [T]` are all reasonable.  I pointed out that, if that's reasonable, then `ptr::fn_addr_eq` is the higher-ranked version of that, since for the same use cases, it could be reasonable to compare function pointers that return those three different things or accept them as arguments.

TC: Adding to that, scottmcm noted that comparing addresses despite lifetime differences is also compelling, e.g. comparing `fn(Box<T>) -> &'static mut T` with `for<'a> fn(Box<T>) -> &'a mut T`.

TC: Other alternatives we considered were not stabilizing `ptr::fn_addr_eq` at all and instead stabilizing `FnPtr` so people could write `ptr::addr_eq(fn1.addr(), fn2.addr())`, or expecting that people would write instead `fn1 as *const () == fn2 as *const ()`.

TC: Recently CAD97 raised an interesting alternative:

> From the precedent of `ptr::eq` and `ptr::addr_eq`, I'd expect a "`ptr::fn_eq`" to have one generic type and a "`ptr::fn_addr_eq`" to have two. Even if `ptr::fn_eq`'s implementation is just an address comparison, it still serves as a documentation point to call out the potential pitfalls with comparing function pointers.

TC: What do we think?

---

TC: Separately, on the 2024-01-10 call, we discussed some interest use cases for function pointer comparison, especially when it's indirected through `PartialEq`.  We had earlier said we didn't want to lint when such comparisons were indirected through generics, but we did address the non-generic case of simply composing such comparisons.

One example of how this is used is in the standard library, in `Waker::will_wake`:

https://doc.rust-lang.org/core/task/struct.Waker.html#method.will_wake

It's comparing multiple function pointers via a `#[derive(PartialEq)]` on the `RawWakerVTable`.

We decided on 2024-01-01 that this case was interesting and we wanted to think about it further.  We opened a discussion thread about this:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Function.20pointer.20comparison.20and.20.60PartialEq.60

Since then, another interesting use case in the standard library was raised, in the formatting machinery:

https://doc.rust-lang.org/src/core/fmt/rt.rs.html

What do we think about these, and would we lint on derived `PartialEq` cases like these or no?

### "RFC: inherent trait implementation" rfcs#2375

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

TC: We had a design meeting on 2023-09-12 about inherent trait impls.  In that meeting, I proposed a `use` syntax for this:

> In the discussion above, we had left two major items unresolved.
>
> - How do we make blanket trait impls inherent?
> - How can we allow only *some* items from the trait impl to be made inherent?
>   - This is especially tricky for associated functions and methods with a default implementation.
>
> (Part of the motivation for wanting to allow only some items to be made inherent is to prevent or to fix breakage caused when a trait later adds a new method with a default implementation whose name conflicts with the name of an existing inherent method.)
>
> Coming up with a syntax for these that combines well with the `#[inherent]` attribute could be challenging.
>
> One alternative that would make solving these problems straightforward is to add some syntax to the inherent `impl` block for the type.  Given the desugaring in the RFC, there is some conceptual appeal here.  (quaternic proposed this arrangement; TC is proposing the concrete syntax.)
>
> We can use `use` syntax to make this concise and intuitive.
>
> Here's an example:

```rust
trait Trait1<Tag, T> {
    fn method0(&self) -> u8 { 0 }
    fn method1(&self) -> u8 { 1 }
}
trait Trait2<Tag, T> {
    fn method2(&self) -> u8 { 2 }
    fn method3(&self) -> u8 { 3 }
    fn method4(&self) -> u8 { 4 }
}

struct Tag;

struct Foo<T>(T);
impl<T> Foo<T> {
    // All methods and associated items of Trait1 become inherent,
    // except for `method0`.  The inherent items are only visible
    // within this crate.
    pub(crate) use Trait1<Tag, T>::*;
    // Only `method2` and `method3` on Trait2 become inherent.
    pub use Trait2<Tag, T>::{method2, method3};

    fn method0(&self) -> u64 { u64::MAX }
}

impl<T> Trait1<Tag, T> for Foo<T> {}
impl<U: Trait1<Tag, T>, T> Trait2<Tag, T> for U {}
```

> This solves another problem that we discussed above.  How do we prevent breakage in downstream crates when a trait later adds a new method with a default implementation?  Since a downstream crate might have made an impl of this trait for some local type inherent and might have an inherent method with a conflicting name, this could be breaking.
>
> We already handle this correctly for `use` declarations with wildcards.  Any locally-defined items override an item that would otherwise be brought into scope with a wildcard import.  We can reuse that same behavior and intuition here.  When a wildcard is used to make all items in the trait inherent, any locally-defined inherent items in the `impl` prevent those items from the trait with the same name from being made inherent.
>
> Advantages:
>
> - It provides a syntax for adopting as inherent a blanket implementation of a trait for the type.
> - It provides a syntax for specifying which methods should become inherent, including methods with default implementations.
> - The wildcard import (`use Trait::*`) makes it very intuitive what exactly is happening and what exactly your API is promising.
> - The `use` syntax makes it natural for a locally-defined item to override an item from the wildcard import because that's exactly how other `use` declarations work.
> - `rust-analyzer` would probably support expanding a wildcard `use Trait::*` to an explicit `use Trait::{ .. }` just as it does for other `use` declarations, which would help people to avoid breakage.
> - We can support any visibility (e.g. `use`, `pub use`, `pub(crate) use`, etc.) for the items made inherent.
>
> Disadvantages:
>
> - There's some redundancy, especially when the items to make inherent are specifically named.

During the meeting, this emerged as the presumptive favorite, and we took on a TODO item to updated the RFC.

After follow-on discussion in Zulip, Niko agreed, and also raised a good question:

> Per the discussion on zulip, I have become convinced that it would be better to make this feature use the syntax `use`, like:
>
```rust
impl SomeType {
    pub use SomeTrait::*;  // re-export the methods for the trait implementation
}
```
>
> This syntax has a few advantages:
>
> * We can give preference to explicit method declared in the impl blocks over glob re-exports, eliminating one source of breakage (i.e., trait adds a method with a name that overlaps one of the inherent methods defined on `SomeType`)
> * Can make just specific methods (not all of them) inherent.
> * Easier to see the inherent method when scanning source.
> * You can re-export with different visibility levels (e.g., `pub(crate)`)
> * It would work best if we planned to permit `use SomeTrait::some_method;` as a way to import methods as standalone fns, but I wish we did that.
>
> However, in writing this, I realize an obvious disadvantage -- if the trait has more generics and things, it's not obvious how those should map. i.e., consider
>
```rust
struct MyType<T> {
}

impl<T> MyType<T> {
    pub use MyTrait::foo;
}

impl<T: Debug> MyTrait for MyType<T> {
    fn foo(&self) { }
}
```
>
> This would be weird -- is this an error, because the impl block says it's for all `T`? And what if it were `trait MyTRait<X>`?

TC: My sense is that we've just been awaiting someone digging in and updating the RFC here.

### "Raw Keywords" rfcs#3098

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

TC: We've at various times discussed that we had earlier decided that if we wanted to use a new keyword within an edition, we would write it as `k#keyword`, and for that reason, we prefer to not speculatively reserve keywords ahead of an edition (except, perhaps, when it's clear we plan to use it in the near future).

TC: Somewhat amusingly, however, we never in fact accepted that RFC.  Back in 2021, we accepted scottmcm's proposal to **cancel**:

> We discussed this RFC again in the lang team triage meeting today.
>
> For the short-term goal of the reservation for the edition, we'll be moving forward on #3101 instead. As such, we wanted to leave more time for conversations about this one, and maybe use crater results from 3101 to make design changes,
>
> @rfcbot cancel

Instead we accepted RFC 3101 that reserved `ident#foo`, `ident"foo"`, `ident'f'`, and `ident#123` starting in the 2023 edition.

Reading through the history, here's what I see:

- What do we want to do about Rust 2015 and Rust 2018?  It's a breaking change to add this there.  Is this OK?  Do we want to do a crater run on this?
- Would we have the stomach to actually do this?  It's one thing to *say* that if we wanted to use a new keyword within an edition, we'd write `k#keyword`, but it's another to actually do it in the face of certain criticism about that being e.g. unergonomic.  Would we follow through?

TC: What do we think?

### "RFC: Implementable trait aliases" rfcs#3437

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

TC: We discussed this in the lang planning meeting in June, and it looks like there have been updates since we last looked at this, so it's time for us to have another look since we seemed interested in this happening.

TC: What do we think?

### "Should Rust still ignore SIGPIPE by default?" rust#62569

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

TC: Prior to `main()` being executed, the Rust startup code makes a syscall to change the handling of `SIGPIPE`.  Many believe that this is wrong thing for a low-level language like Rust to do, because 1) it makes it impossible to recover what the original value was, and 2) means things like `seccomp` filters must be adjusted for this.

It's also just, in a practical sense, wrong for most CLI applications.

This seems to have been added back when Rust had green threads and then forgotten about.  But it's been an ongoing footgun.

Making a celebrity appearance, Rich Felker, the author of MUSL libc, notes:

> As long as Rust is changing signal dispositions inside init code in a way that the application cannot suppress or undo, it is _fundamentally unusable to implement standard unix utilities that run child processes_ or anything that needs to preserve the signal dispositions it was invoked with and pass them on to children. Changing inheritable process state behind the application's back is just unbelievably bad behavior and does not belong in a language runtime for a serious language...
>
> As an example, if you implement `find` in Rust, the `-exec` option will invoke its commands with `SIGPIPE` set to `SIG_IGN`, so that they will not properly terminate on broken pipe. But if you just made it set `SIGPIPE` to `SIG_DFL` before invoking the commands, now it would be broken in the case where the invoking user intentionally set `SIGPIPE` to `SIG_IGN` so that the commands would not die on broken pipe.

There was discussion in 2019 about fixing this over an edition, but nothing came of it.

Are we interested in fixing it over this one?

Strawman (horrible) proposal: We could stop making this pre-main syscall in Rust 2024 and have `cargo fix` insert this syscall at the start of every `main` function.

(In partial defense of the strawman, it gets us directly to the arguably best end result while having an automatic semantics-preserving edition migration and it avoids the concerns about lang/libs coupling that Mara raised.  The edition migration could add a comment above this inserted code telling people under what circumstances they should either keep or delete the added line.)

### "types team / lang team interaction" rust#116557

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

TC: nikomatsakis nominated this:

> We had some discussion about types/lang team interaction. We concluded a few things:
>
> * Pinging the team like @rust-lang/lang is not an effective way to get attention. Nomination is the only official way to get attention.
> * It's ok to nominate things in an "advisory" capacity but not block (e.g., landing a PR), particularly as most any action can ultimately be reversed. But right now, triagebot doesn't track closed issues, so that's a bit risky.
>
> Action items:
>
> * We should fix triagebot to track closed issues.

TC: What do we think?

### "[RFC] `core::marker::Freeze` in bounds" rfcs#3633

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

TC: There's a proposal on the table for the stabilization of the `Freeze` trait in bounds.

We discussed this in our design meeting on 2024-07-24.

TC: What's next here?

### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418

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

TC: We discussed this last in the meeting on 2024-03-13.  scottmcm has now raised on concern on the issue and is planning to make a counter-proposal:

> I remain concerned about exposing this with no opt-out on an unrestricted generic type @rfcbot concern overly-broad
>
> I'm committing to making an alternative proposal because I shouldn't block without one. Please hold my feet to the fire if that's no up in a week.
>
> Basically, I have an idea for how we might be able to do this, from [#106418 (comment)](https://github.com/rust-lang/rust/pull/106418#issuecomment-1698887324)
>
> > 2. Expose the variant ordering privately, only accessible by the type owner/module.
> >
> > Solution 2. is obviously more desirable, but AFAIK Rust can't do that and there is no proposal to add a feature like that.

https://github.com/rust-lang/rust/pull/106418#issuecomment-1994833151

### "Fallout from expansion of redundant import checking" rust#121708

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

TC: We discussed this in the meeting on 2024-03-13.  The feelings expressed included:

- We don't want to create a perverse incentive for people to expand existing lints rather than to create new ones where appropriate just because there's less process for expanding the meaning of an existing lint.
- It would be good if potentially-disruptive expansions of an existing lint either:
  - Had a machine-applicable fix.
  - Or had a new name.
- We don't want to require a new lint name for each expansion.
- We don't want to require a crater run for each change to a lint.
- There are two ways to prevent disruption worth exploring:
  - Prevent potentially-disruptive changes from hitting master.
  - Respond quickly to early indications of disruption once the changes hit master.
- Compiler maintainers have a sense of what might be disruptive and are cautious to avoid it.  It may be OK to have a policy that is not perfectly measurable.

TC: tmandry volunteered to draft a policy proposal.

### "What are the guarantees around which constants (and callees) in a function get monomorphized?" rust#122301

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

TC: The8472 asks whether this code, which compiles today, can be relied upon:

```rust
const fn panic<T>() {
    struct W<T>(T);
    impl<T> W<T> {
        const C: () = panic!();
    }
    W::<T>::C
}

struct Invoke<T, const N: usize>(T);

impl<T, const N: usize> Invoke<T, N> {
    const C: () = match N {
        0 => (),
        // Not called for `N == 0`, so not monomorphized.
        _ => panic::<T>(),
    };
}

fn main() {
    let _x = Invoke::<(), 0>::C;
}
```

The8472 notes that this is a useful property and that there are use cases for this in the compiler and the standard library, at least unless or until we adopt something like `const if`:

https://github.com/rust-lang/rfcs/issues/3582

RalfJ has pointed out to The8472 that the current behavior might not be intentional and notes:

> It's not opt-dependent, but it's also unclear how we want to resolve the opt-dependent issue. Some [proposals](https://github.com/rust-lang/rust/issues/122814#issuecomment-2015090501) involve also walking all items "mentioned" in a const. That would be in direct conflict with your goal here I think. To be clear I think that's a weakness of those proposals. But if that turns out to be the only viable strategy then we'll have to decide what we want more: using `const` tricks to control what gets monomorphized, or not having optimization-dependent errors.
>
> One crucial part of this construction is that everything involved is generic. If somewhere in the two "branches" you end up calling a monomorphic function, then that may have its constants evaluated even if it is in the "dead" branch -- or it may not, it depends on which functions are deemed cross-crate-inlinable. That's basically what #122814 is about.

TC: The question to us is whether we want to guarantee this behavior.  What do we think?

### "Policy for lint expansions" rust#122759

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

TC: In the call on 2024-03-13, we discussed this issue raised by tmandry:

"Fallout from expansion of redundant import checking"

https://github.com/rust-lang/rust/issues/121708

During the call, the thoughts expressed included:

- We don't want to create a perverse incentive for people to expand existing lints rather than to create new ones where appropriate just because there's less process for expanding the meaning of an existing lint.
- It would be good if potentially-disruptive expansions of an existing lint either:
  - Had a machine-applicable fix.
  - Or had a new name.
- We don't want to require a new lint name for each expansion.
- We don't want to require a crater run for each change to a lint.
- There are two ways to prevent disruption worth exploring:
  - Prevent potentially-disruptive changes from hitting master.
  - Respond quickly to early indications of disruption once the changes hit master.
- Compiler maintainers have a sense of what might be disruptive and are cautious to avoid it.  It may be OK to have a policy that is not perfectly measurable.

TC: tmandry volunteered to draft a policy proposal.  He's now written up this proposal in this issue.

TC: What do we think?

### "Tracking Issue for externally implementable items" rust#125418

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

TC: We reviewed in triage an RFC for externally implementable functions on 2024-05-22 along with a companion/alternative RFC for externally implementable statics.  That discussion produced two more proposals, one from Amanieu and one from tmandry.

TC: We're likely going to need a design meeting to work through these.

### "Decide on path forward for attributes on expressions" rust#127436

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

TC: We decided recently to unblock progress on attributes on expressions (RFC 16) by allowing attributes on blocks.  We have a proposed FCP to this effect.

After we did this, the question came up what we want to do about attributes in list contexts, e.g.:

```rust
call(#[foo] { block1 }, #[bar] { block2 })
```

...in particular, macro attributes.

Petrochenkov says:

> It needs to be decided how proc macros see the commas, or other separators in similar cases.
>
> Ideally proc macros should be able to turn 1 expression into multiple (including 0) expressions in this position, similarly to `cfg`s or macros in list contexts without separators. So it would be reasonable if the separators were included into both input and output tokens streams (there are probably other alternatives, but they do not fit into the token-based model as well). The "reparse context" bit from [#61733 (comment)](https://github.com/rust-lang/rust/issues/61733#issuecomment-509626449) is likely relevant to this case as well.

We filed a concern to figure this all out.

We discussed this on 2024-07-24 and came up with these options:

> Options ordered from least to most conservative (and then from most to least expressive):
>
> - Option A: Punt this case and don't support attributes in this position without parens (e.g. `call((#[attr] arg), (#[attr] arg2))`)
> - Option B (exactly one): Specify that, for now, if you use a macro attribute on an expression, that macro can only expand to a single expresion (not zero tokens, and no tokens following in the output).
> - Option C (zero or one): Specify that, for now, if you use a macro attribute on an expression, that macro can only expand to zero tokens or an expression with nothing following (extra tokens, including `,`, are an error for now)
> - Option D (zero or more): Specify that an attribute in this position can expand to tokens that may include a `,`, and that if they expand to zero tokens then we elide the comma.
> - Option E (flexible): include comma, let macro decide, etc
>    - We find it surprising that comma would be included.

In discussion, we seemed generally interested in allowing at least zero and 1.  We weren't sure about N, and we weren't sure about the handling of the comma in the input.

TC: What do we think?

### "Decide on bounds syntax for async closures (RFC 3668)" rust#128129

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

In the special design meeting 2024-07-23, we discussed five syntaxes for async closures:

- `F: async FnMut() -> T`
- `F: AsyncFnMut() -> T`
- `F: async mut fn() -> T`
- `F: async mut () -> T`
- `F: async mut || -> T`

Our current straw poll is:

| name         | `async Fn*() -> T` | `AsyncFn*() -> T` | `async fn * () -> T` | `async * () -> T` | `async * \|A, B\| -> T` |
|--------------|--------------------|-------------------|----------------------|-------------------|-------------------------|
| nikomatsakis |       +1           |         +0        |         -1           |          -1       |          -1             |
| tmandry      |       +1           |         +1        |         -0.5         |          -1       |          -0.5           |
| Josh         |       -1           |         +0.75     |         +0.5         |          +1       |          +0.5           |
| pnkfelix     |       +0           |         -0        |         -0.5         |          +0       |          -1             |
| scottmcm     |                    |                   |                      |                   |                         |
| TC           |       +1           |         -0.5      |         -1           |          -1       |          -1             |
| CE           |       +1           |         -1        |         -1           |          -0.5     |          -1             |
| eholk        |       +1           |         +0        |         -1           |          -0.75    |          -0.5           |

- +1: "This is what I would do."
- +0: "I'm OK with this, leaning positive."
- -0: "I'm neutral to this, leaning negative."
- -1: "I would block this."

We agreed to:

- Move this to an unresolved question in RFC 3668.
- Allow that RFC to proceed to FCP.
- Implement both of the two main syntax options in nightly.
- Give both syntaxes equal billing in any blog posts about this.

There was substantial discussion of this after the design meeting itself in the thread here:

https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Design.20meeting.202024-07-23

TC: This is just an FYI for those that didn't follow this closely.

### "Effective breakage to `jiff` due to `ambiguous_negative_literals`" rust#128287

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

We recently adopted a lint againstn `ambiguous_negative_literals` like:

```rust
assert_eq!(-1.abs(), -1);
```

However, immediately after this landed, BurntSushi reported that this effectively breaks a pattern he had used in the API of his `jiff` datetime library:

> This completely broke Jiff once the change landed. Because it specifically supports negating spans like `-1.hour()`. [In the case of Jiff, there is no ambiguity because `-1.hour()` and `(-1).hour()` and `-(1.hour())` are all precisely equivalent.](https://docs.rs/jiff/latest/jiff/struct.Span.html#negative-spans)

This seems worth our consideration.

One option proposed is that, perhaps, we should have a way to notate functions that are sensitive to the order of operations here, and lint on calls to those with unparenthesized negative literals.

Another option proposed is to go the other way, and introduce some way to notate functions that are *not* sensitive to the order of operations.

TC: What do we think?

### "`unreachable_patterns` lint due to `min_exhaustive_patterns`" rust#129031

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

TC: We talked about this on 2024-08-14 and decided:

> We discussed this in our triage meeting today. We didn't feel that separating out this lint was necessary because, among other reasons, the `allow` could be placed directly on the match arm for anyone who wants to preserve MSRV. If T-compiler does want to separate out this lint, that's fine by us as long as `unreachable_patterns` then becomes a lint group that includes `impossible_patterns`.
>
> We also discussed how this could be a good use case for `cfg(rust_version)` ([tracking issue](https://github.com/rust-lang/rust/issues/64796)).
>
> Our feeling, among those on the call, was that we do want this lint to fire, and that this is the purpose of lints, even though, yes, we're unfortunately going from requiring it to warning about it.

TC: In part in the context of libs-api recently breaking 5400 crates in Rust 1.80, this has been renominated for our consideration of impact.  What do we think?

### "Tracking issue for release notes of #128771: Stabilize `unsafe_attributes`" rust#129566

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

### "Tracking issue for release notes of #128596: stabilize const_fn_floating_point_arithmetic" rust#129567

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

### "Tracking issue for release notes of #128570: Stabilize `asm_const`" rust#129569

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

### "Tracking issue for release notes of #127921: Stabilize unsafe extern blocks (RFC 3484)" rust#129575

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

### "Tracking issue for release notes of #127679: Stabilize `raw_ref_op` (RFC 2582)" rust#129576

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

### "Tracking issue for release notes of #127672: Stabilize opaque type precise capturing (RFC 3617)" rust#129577

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

### "Tracking issue for release notes of #122792: Stabilize `min_exhaustive_patterns`" rust#129579

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

## Action item review

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

## Pending lang team project proposals

None.

## PRs on the lang-team repo

### "Add soqb`s design doc to variadics notes" lang-team#236

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

### "Update auto traits design notes with recent discussion" lang-team#237

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

### "Update hackmd link to a public link" lang-team#258

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

### "Adding a link to "how to add a feature gate" in the experimenting how-to" lang-team#267

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

## RFCs waiting to be merged

None.

## `S-waiting-on-team`

### "Allow dropping `dyn Trait` principal" rust#126660

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

### "const-eval interning: accept interior mutable pointers in final value" rust#128543

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

### "Stabilize `&mut` (and `*mut`) as well as `&Cell` (and `*const Cell`) in const" rust#129195

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

### "Emit error when calling/declaring functions with unavailable vectors." rust#127731

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

### "`optimize` attribute applied to things other than methods/functions/c…" rust#128943

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

### "`repr(tag = ...)` for type aliases" rfcs#3659

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

### "Fixup Windows verbatim paths when used with the `include!` macro" rust#125205

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

### "repr(int) fieldless enums are ABI-compatible with int" rust#128600

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

### "Don't make statement nonterminals match pattern nonterminals" rust#120221

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

### "Initial support for auto traits with default bounds" rust#120706

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

### "Stabilize `count`, `ignore`, `index`, and `length` (`macro_metavar_expr`)" rust#122808

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

### "Skip pub structs with repr(c) and repr(transparent) in dead code analysis" rust#127104

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

### "Better errors with bad/missing identifiers in MBEs" rust#118939

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

### "Rename `AsyncIterator` back to `Stream`, introduce an AFIT-based `AsyncIterator` trait" rust#119550

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

### "Allow `#[deny]` inside `#[forbid]` as a no-op" rust#121560

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

### "Non-exhaustive structs may be empty" rust#128934

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

## Proposed FCPs

**Check your boxes!**

### "Make destructors on `extern "C"` frames to be executed" rust#129582

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

### "Allow dropping `dyn Trait` principal" rust#126660

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

### "Update `catch_unwind` doc comments for `c_unwind`" rust#128321

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

### "Don't warn empty branches unreachable before edition 2024" rust#129103

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

### "`repr(tag = ...)` for type aliases" rfcs#3659

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

### "Trait method impl restrictions" rfcs#3678

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

### "Consider deprecation of UB-happy `static mut`" rust#53639

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

### "Tracking Issue for enum access in offset_of" rust#120141

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

### "Stabilize `count`, `ignore`, `index`, and `length` (`macro_metavar_expr`)" rust#122808

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

### "Add support for `use Trait::func`" rfcs#3591

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

### "Supertrait item shadowing v2" rfcs#3624

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

### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378

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

### "[RFC] externally implementable functions" rfcs#3632

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

### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418

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

### "Policy for lint expansions" rust#122759

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

### "Decide on path forward for attributes on expressions" rust#127436

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

### "Don't allow unwinding from Drop impls" rfcs#3288

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

### "Add text for the CFG OS Version RFC" rfcs#3379

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

### "[RFC] Add `#[export_ordinal(n)]` attribute" rfcs#3641

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

### "Stabilize associated type position impl Trait (ATPIT)" rust#120700

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

### "atomics: allow atomic and non-atomic reads to race" rust#128778

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

## Active FCPs

### "Proposal: stabilize `const_refs_to_static`" rust#128183

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

### "Guard Patterns" rfcs#3637

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

## P-critical issues

None.
