---
title: Triage meeting 2023-10-25
tags: T-lang, triage-meeting, minutes
date: 2023-10-25
discussion: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Triage.20meeting.202023-10-25
url: https://hackmd.io/JlwVhfTFRa-0b23kfHuv9g
---

# T-lang meeting agenda

- Meeting date: 2023-10-25

## Attendance

- People: TC, Josh, Felix, nikomatsakis, scottmcm, waffle

## Meeting roles

- Minutes, driver: TC

## Scheduled meetings

- 2023-10-25: "Design meeting: Implementable trait aliases" [#224](https://github.com/rust-lang/lang-team/issues/224)

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

## Announcements or custom items

### 2024 Edition

JT: We should work on the lang roadmap for the 2024 Edition. Proposal: use multiple design meetings in November for that.

TC: The 2024 Edition survey:

https://hackmd.io/itGzgM1fQl-oh4d1iP8sFg

JT: We should work on this in November.

NM: Good idea. Last I heard, Tyler, bstrie, Esteban were working on that. We should get a survey of the work they've done so far.

JT: My understanding is they're shepherding; so we should work together with them on that.

NM: I was expecting someone on that team come in with a list of candidates.

TC: Maybe we should start by looking back through the 2024 edition survey.

NM: This is when we may want to start saying "no" as well.

JT: And looking for items that are borderline, prioritizing them, and encouraging people to push a couple of them forward.

*Consensus*: We'll talk about this during the planning meeting on the 1st.

## Nominated RFCs, PRs, and issues

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

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

TC: In the 2023-10-10 meeting, we discussed this. The main open question is whether these lifetimes should be higher ranked. We decided we wanted an analysis that went deeper than just pointing out consistency with an accidental stabilization (and we were hoping to get feedback from @nikomatsakis). @tmandry has now done that [analysis](https://github.com/rust-lang/rust/pull/107378#issuecomment-1767448648):

> ### Associated types
>
> The first position to consider is associated types; I think lifetimes here should clearly be associated with the function, because we want this sample to compile:
>

fn fun(t: impl Iterator<Item = &u32>) {}
let v = vec![1, 2, 3];
fun(v.iter());

>
> If we made it higher-ranked the only way to call `fun` would be with an iterator over `'static` data.
>
> ### Generics and `Self`
>
> The second position is in generics of the trait itself.
>
> @Manishearth convinced me that we shouldn't try to follow the Fn* traits, which make lifetimes in generic types higher-ranked, for the reason that they are weird _because their generics are contravariant_ (used in method argument position). In other words, this example is _not representative_ of uses of APIT...
>

trait Foo<T> {
    fn foo(&self, _: T) { }
}

// Error! Lifetime is associated with the function
mod foo {
    fn fun(t: impl crate::Foo<&u32>, n: u32) {
        t.foo(&n);
    }
}

>
> ...and we should not expect it to compile, meaning the behavior on nightly is correct.
>
> The result of the current behavior, putting implicit lifetimes on the function signature, is that they are constrained when calling our function (`fun` above) rather than in the body. I would argue that this is reasonable because of the common places where lifetime generics come from:
>
> 1. Within the `Self` type, as in the all-pervasive `'tcx` lifetime in rustc ([example](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/visit/trait.Visitor.html)). In this case the lifetime is already decided by the time our function is called because it is embedded in the argument we are accepting. [`serde::Deserialize`](https://docs.rs/serde/latest/serde/trait.Deserialize.html) is another example where the lifetime (which happens to be used in some arguments of the Visitor methods) ends up in the Self type.
> 2. In the return type of a method such as [Into::into](https://doc.rust-lang.org/stable/std/convert/trait.Into.html). In this case the lifetime must also be decided by the caller. `AsRef` and `Borrow` are other examples.[1](#user-content-fn-asref-9cb1f3fe736818ee2e0bda7497146f54)
>
> It is of course possible to write a trait like `Foo` above, but that would be considered the exception and not the rule. The behavior of our special `Fn` syntax is very useful for those kinds of cases; I'd be hard pressed to come up with an example that isn't working around a lack of dedicated closure traits for a given use case.
>
> And given that these examples would all break if we tried to make their elided lifetimes higher ranked, we should definitely go with the current behavior.
>
> ## Footnotes
>
> 1. Note that you could still use `impl AsRef<T>` freely in the function because the lifetime in this trait is created by the call to `as_ref()`, not embedded in T. If there are any lifetimes embedded in T, they again would be constrained outside our function that uses AFIT. [↩](#user-content-fnref-asref-9cb1f3fe736818ee2e0bda7497146f54)

JT: Does this affect plans to maybe make Iterator into a LendingIterator.

NM: It depends. If we wanted to go that way, we'd have to decide what to do about the fact that Item doesn't have a lifetime parameter. E.g.:

fn fun(t: impl LendingIterator<Item<'_> = &u32>) {}
    //                             ^^^^ we are not specifying what happens
let v = vec![1, 2, 3];
fun(v.iter());

NM: Some notes:

* First part, I agree.
* Second part, I am not sure, and especially unsure because of interactions with GATs.

NM: On the first one, the lifetimes in an associated type have to come from some input types in the trait. So if there are no input lifetimes, there's nothing else you could write there.

For GATs, at least in my uses, the vast majority are higher-ranked:

fn foo(x: impl for<'a> Foo<Item<'a> = &'a u32>)

// Niko wanted to write something like this to mean the above...
fn foo(x: impl Foo<Item<'_> = &u32>)
// '_ would implicitly borrow from &u32.
//
// analogous to `fn(&u32) -> &u32`
//
// and in my case I was being specific to GAT w/ 1 lifetime parameter.
//
// normally: in output position, we try to link to an input, and in this case that's what I would expect.

// but also this is very common (alias is `T: DeserializeOwned`):
where
    for<'a> T: Deserialize<'a>,

where
    T: Deserialize<'_>, // not sure what else THIS could mean BUT for<'a> 

NM: I'd like `'_` to mean "for all lifetimes" in general.

JT: That makes sense. If you're parameterizing a type or trait with a generic parameter that has a reference in it, it *seems* like you're probably intending that to mean the reference type in general, not *one specific* reference type with a specific lifetime. (Though there are use cases for the latter too.)

TC: On the first part, NM, could you clarify a bit for the minutes?

NM: What I'm trying to say is:

// this is not possible:
fn foo(x: impl for<'a> Foo<Item = &'a u32>)
trait Foo { type Item; }
impl<'a> Foo for u32 {
    type Item = &'a X; // 'a does not appear in impl header
}

fn bar(x: impl for<'a> Bar<'a, Item = &'a u32>)
trait Bar<'a> { type Item; }
impl<'a> Bar<'a> for u32 {
    type Item = &'a X; // 'a does not appear in impl header
}


fn baz(x: impl for<'a> Baz<&'a u32, Item = &'a u32>)
trait Baz<T> { type Item; }
impl<'a> Baz<&'a u32> for u32 {
    type Item = &'a X; // 'a does not appear in impl header
}

NM: For the value to appear in an associated type, it has to appear as an input. So in this scenario, the first above, `'static` is the only option anyway. So having `'a` be a fresh lifetime that appears in the value of an associated type and is bound on the `impl` block is definitely useless, no impl could fulfill it. But I'm not sure about second point.

TC: You've convinced me. Proposal: if you have the time, NM, could you write up this counterpoint on the ticket?

NM: My takeaway for second part is that I'd like to see more examples. It sounds like Tyler was saying `fn foo(x: impl Visitor<'_>)` would probably not want to be `for<'a>`, which seems...true-ish. But it probably wants to be `'tcx`.

pnkfelix: ?

NM: What's happening here is that it's analogous to functions. These are outputs in an input position, which is what makes it funky.

pnkfelix: As soon as you have multiple parameters with reference type, you can't do that anymore, right?

NM: Yes, but it's extremely common to have a GAT with one lifetime parameter. In inputs, we make a fresh input. In outputs, we try to link it to one of the inputs. But it's complicated because we're talking about a contravariant thing here. We want to work out the patterns some more.

NM: In retrospect, I wish we had some way to inline declare you want a fresh name. E.g., I wish you could something like this:

// e.g. I wish instead of for<'a> you did...
x: impl LendingIterator<Item<lt 'a> = &'a u32>
//                           ^^ (though I'd want a different keyword)

// and even like this:
struct Foo<type T> { } // for consistency, use `type` here...
impl Foo<type T> { ... } // ...and then we can write this instead of `impl<T> Foo<T>`

NM: We pun on whether the thing in the brackets is a fresh identifier or a reference to an existing identifier. With GATs, it's getting particularly painful, because sometimes you want both.

JT: :+1: for having inline declaration syntax, though it seems ambiguous whether that would mean `for` or a generic...

scottmcm: It reminds me of the `impl Trait` conversation.

TC: It has similarities to adding `dyn` in the sense that it's not breaking.

*Consensus*: This needs further discussion and analysis. In particular, we need more worked examples of the cases here.

TC: After the meeting, NM wrote up a thoughtful common on the PR here:

https://github.com/rust-lang/rust/pull/107378#issuecomment-1779629217

### "RFC: Syntax for embedding cargo-script manifests" rfcs#3503

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

TC: This proposed RFC was proposed for priority treatment in the meeting on Zulip by tmandry and JT.

TC: We have a planning meeting on the 1st. What do we want from this meeting on this issue versus what might we want to defer to later discussion, since there is a lot to discuss here?

JT: Regarding the edition, the proposal is that any program that *doesn't* specify an edition will emit a warning, but still run. That way, people can successfully run the program, but will have a warning they need to fix (ideally with a `cargo fix` you can apply).

NM/pnkfelix: Let's defer.

*Consensus*: Let's defer discussion on this for now.

---

(The remainder of this section is being deferred to later discussion.)

TC: The following syntax is being proposed for addition to Rust:

#!/usr/bin/env cargo

[dependencies]
clap = { version = "4.2", features = ["derive"] }

use clap::Parser;

TC: tmandry commented:

> With my lang hat on, I don't see a reason we should RFC a feature that only allows `cargo` front matter, without specifying a path to generalizing it to other tooling. If we want to be conservative in what we stabilize, let's approach that in the stabilization rather than in the RFC.
>
> At the language level we should acknowledge that not all projects get to use cargo, and the generalization here seems trivial to do in the RFC. Note that I'm fine with the RFC being conservative in other ways (only allowing one, right after the shebang, etc).
>
> Taking off my lang hat now – using `cargo` sure makes it awkward to extend to embedding a second front matter with Cargo.lock. It'd be nice if the RFC addressed that. (Maybe just say "we can use `cargo-lock` for consistency with `cargo`"?)

TC: +1 from me there.

TC: To perhaps prompt discussion, here are some thoughts I earlier wrote down when reviewing this RFC:

- The code string literals RFC had also proposed to use Markdown code block syntax. In the discussion surrounding that, the feeling was that may be a bridge too far. Would we feel differently here?

- Even if cargo never wanted to support `Cargo.lock` or other files, it's clear that other build tools may want to support these. Go's similar feature, `gorun`, has this same problem and therefore spells out the name of each file in the syntax. Are we sure we don't want to do that?

- The key T-lang concern here is specifying "what's allowed in a .rs file?" This has wider ecosystem implications on editors, syntax highlighters, rust-analyzer, etc. To what degree are we willing to break existing such tools with new syntax? And to what degree does this influence whether we should adopt a more general solution than just what works for Cargo's planned feature?

- Perhaps we should consider a new kind of comment for frontmatter in Rust 2024 that preserves the symmetry with existing comment types? E.g. we could use `//+` and `/*+ */`. This would have the advantage of not breaking existing parsers as it would be a legal comment in the old edition.

- There's overlap between this and the code string literals RFC. Both want to embed some structured non-Rust file in a Rust file. Both are hoping for eventual support from editors and other tools. Is there perhaps a way to build one on the other? E.g., perhaps we could add a `set_build_file!("Cargo.toml", ..)` macro where the second argument is expected (by convention) to be spelled with a code string literal. We could lint or error on "complicated" uses of that macro that may not be understood by tools.

- Some of the examples in the RFC don't specify the edition. The related RFC 3502 suggests these would be interpreted as refering to whatever the current edition is, and that breakage on `rustc` upgrades may be expected. Is this acceptable to T-lang?

TC: What thoughts do people have about this?

### "Stabilize `const_maybe_uninit_zeroed` and `const_mem_zeroed`" rust#116218

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

TC: This is a constification. Last week we decided to ask a question. NM:

> Ralf can you elaborate on what this means:
>
> > LGTM, but the FCP should probably include t-lang since this makes the internal mutable referece/ptr support in our const-eval engine accessible from stable for the first time.
>
> What is "internal mutable reference support"? @scottmcm suggested that it meant "a mutable reference appears in the implementation, but it is not leaked out and does not permit `&mut` to be used more broadly"?
>
> I have to admit that I don't have a solid mental model of what the exact invariants are and the edges to stay away from when it comes to const eval. This stabilization certainly _feels_ harmless, but I'd like to understand better. What happens if you do `MaybeUninit::<&mut 32>::zeroed`?

TC: scottmcm replied:

> > What happens if you do `MaybeUninit::<&mut 32>::zeroed`?
>
> Well if you try to _return_ it it's an error for `const_mut_refs`: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=3681ac7985d977e473ba421e2fc3c898
>
> Hmm, and even if it's just a local variable it's _also_ an error:
>
> ```
> error[E0658]: mutable references are not allowed in constant functions
> --> src/lib.rs:4:9
> |
> 4 | let x = unsafe { MaybeUninit::<&mut i32>::zeroed() };
> | ^
> ```
>
> And if you turn on a bunch of features and suppress a bunch of warnings, it's a hard error in the validity check https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=8daceedff345b9f1372ef592a714b79c
>
> ```
> error[E0080]: it is undefined behavior to use this value
> --> src/lib.rs:5:1
> |
> 5 | const FOO: &mut i32 = unsafe { MaybeUninit::<&mut i32>::zeroed().assume_init() };
> | ^^^^^^^^^^^^^^^^^^^ constructing invalid value: encountered mutable reference in a `const`
> |
> = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.
> = note: the raw bytes of the constant (size: 8, align: 8) {
> 00 00 00 00 00 00 00 00 │ ........
> }
> ```

TC: As did RalfJ:

> > LGTM, but the FCP should probably include t-lang since this makes the internal mutable referece/ptr support in our const-eval engine accessible from stable for the first time.
>
> It means that the internal CTFE engine already supports mutable references, but so far this code was not reachable on stable. That code is very mature though, it's used in Miri.
>
> > "a mutable reference appears in the implementation, but it is not leaked out and does not permit &mut to be used more broadly"
>
> Yes.

TC: Let's read, consider, and discuss whether it can move forward based on those replies.

scottmcm: According to Ralf, this is very mature because it's what Miri is doing, and we have a fallback path.

NM: +1. Can't imagine that we wouldn't want this.

JT: If the folks doing CTFE think it's fine, it's probably fine.

wffl: +1, seems uncontroversial

TC: Josh, NM, if you check, this will go into FCP.

NM: I'll check my box.

*Consensus*: This is going into FCP merge.

### "Guarantee that `char` has the same size and alignment as `u32`" rust#116894

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

TC: Last week we discussed the corresponding issue on the reference:

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

TC: We decided we were +1 on that. Two things. First, GH says the reference PR can't be merged without a reviewer OKing it, and all the listed reviewers are on T-lang. Does someone need to / want to OK the review?

TC: Second, do we want to propose FCP on the addition to the core docs here?

scottmcm: Josh has proposed, I'll check a box.

NM: I'll check a box and mark as reviewed.

Consensus: We're in FCP merge.

### "Lifetime Capture Rules 2024" rfcs#3498

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

TC: FCP merge has been proposed. Given that RPITIT relies on this behavior and will be stabilized in Rust 1.75, it would be good to move this RFC forward before we start announcing RPITIT more widely. It's also, of course, related to the 2024 edition.

TC: Proposal: If any of scottmcm, pnkfelix, or Josh are able to stay on after this call, I feel like we could probably knock this off the list in about 10 minutes. Any takers?

(After the meeting, people stayed on for a few minutes. JT checked his box, and this is now in FCP.)

### "MaybeDangling" rfcs#3336

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

TC: We [discussed](https://hackmd.io/ifgF0ThcTSWvKnYRWEM8nw) this in an RFC read on 2023-09-27. The consensus was that someone would proposed FCP merge, but that has not yet been done.

TC: RalfJ has asked recently what our plan is here?

scottmcm: I'll propose FCP merge.

*Outcome*: This is now in proposed FCP merge with one box checked.

### "Never consider raw pointer casts to be trival" rust#113262

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

TC: @lcnr nominated this with a good explanation:

> going to nominate for @rust-lang/lang. I consider this to be a pure bugfix.
>
> We currently do not generate any MIR for pointer casts which only transmute lifetimes. This happens as HIR typeck does not consider the source and target to have distinct types. This causes the following snippet to error:
>
> ```rust
> struct Foo<'a>(&'a ());
>
> fn foo<'a>(v: *const Foo<'a>) -> *const Foo<'static> {
> v as *const Foo<'static>
> //~^ ERROR lifetime may not live long enough
> }
> ```
>
> This can already be avoided by first casting to an unrelated type:
>
> ```rust
> struct Foo<'a>(&'a ());
>
> fn foo<'a>(v: *const Foo<'a>) -> *const Foo<'static> {
> v as *const () as *const Foo<'static>
> }
> ```
>
> With this PR both snippets now compile. Unfortunately this means that we now don't emit the `trivial_casts` lint when casting raw pointers as we don't know whether the cast is trivial during HIR typeck:
>
> ```rust
> #![warn(trivial_casts)]
> struct Foo<'a>(&'a ());
> fn foo<'a>(v: *const Foo<'a>) -> *const Foo<'a> {
> v as *const Foo<'a>
> //~^ WARN trivial cast: `*const Foo<'a>` as `*const **Foo<'a>`
> }
> ```
>
> We could check raw pointer casts during MIR borrowck and lint there, but that may not be worth it 🤷 I think it's fine to open an issue for it and merge this as is, as it does not seem too important to me.

TC: Do we agree this is a bug fix?

scottmcm: ...

NM: +1 on what lcnr wrote. The fix has its own bug that's less important than the original bug.

JT: +1

scottmcm: No idea about the right fix. +1.

NM: I'd rather we accept correct code.

JT: We should make sure there's a bug filed about not emitting the warning, but we should prioritize not rejecting correct code.

pnkfelix/NM/waffle: There's a copy/paste error at the end of the description there.

NM: The bug is that we currently emit an error when we don't expect one.

*Consensus*: This is a bug. We'll leave a comment to that effect.

### "Guarantee that raw pointer conversions preserve slice element count" reference#1417

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

TC: The proposal is to add the following language to the reference:

> #### Slice DST pointer to pointer cast
>
> When `T` and `U` are both "slice DSTs" - i.e., slice types or types whose trailing field
> is a slice type - the raw pointer types `*const T`, `*mut T`, `*const U`, and `*mut U`
> encode the number of elements in this slice. Casts between these raw pointer types
> preserve the number of elements. Note that, as a consequence, such casts do *not*
> necessarily preserve the size of the pointer's referent (e.g., casting `*const [u16]`
> to `*const [u8]` will result in a raw pointer which refers to an object of half the size
> of the original).

TC: What do we think?

NM: The substance of the text, I agree. I have a nitpick about the wording.

scottmcm: This boils down to pointer casts don't change metadata?

waffle: For trait upcasting, you do change the metadata. So it's only for slices.

NM: That's weird but true.

waffle: The code mentioned, this has been true of stable Rust since forever.

scottmcm: Makes sense to me to write in the reference then.

pnkfelix: The only alternative would be to look at the bit width and modify the metadata, which sounds dangerous.

scottmcm: If we had done that in 2013, maybe, but not now.

waffle: Even then, there are cases where that doesn't work.

tmandry: +1, seems fine.

pnkfelix: Should we be linting on this (i.e. when the bitwidths within the slice differ)?

tmandry: i can imagine going to `*const [()]` and then back to the original type later could make sense...

scottmcm: Some sort of clippy lint would make sense. It's a bit questionable.

NM: In general, `as` wants to be deprecated. But we need to think hard about this.

JT: We need something equally ergonomic to replace its key uses, but we should do it anyway.

scottmcm: We need to get various things stabilized for this to work.

wffl: for reference we do have APIs to do this by hand -- `ptr::slice_from_raw_parts(s.as_ptr() ..., s.len()...)`

NM: I'll propose FCP merge.

### "document that the null pointer has the 0 address" rust#116988

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

TC: RalfJ has proposed to document that:

/// let p: *const i32 = ptr::null();
/// assert!(p.is_null());
/// assert_eq!(p as usize, 0); // this pointer has the address 0

*Outcome*: This went into FCP ahead of the meeting with all boxes checked.

### "Rescope temp lifetime in let-chain into IfElse" rust#107251

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

TC: See also:

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

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

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

TC: The idea here is to drop scrutinee temporaries sooner in `if-let`. This would solve lifetime problems that are particularly annoying for `let-chains`. To do this, we would be changing the drop order, as we did in [#103293](https://github.com/rust-lang/rust/pull/103293).

TC: Here's an example of the kind of code that would fail to compile now:

fn opt() -> Option<String> {
    None
}

fn main() {
    _ = if let Some(ref v) = opt() { v } else { "" };
}

TC: People have been submitting PRs to the regressed crates from the crater run.

TC: est31 [pointed out](https://github.com/rust-lang/rust/issues/103108#issuecomment-1280134557) how this same logic could be consistently applied to `match`:

> Good point about the consistency. There are analogous drop order optimization for matches too: You can drop the scrutinee temporaries before entering the body of any arm that is binding free and only followed by other binding-free arms, so cases like:
>
> ```rust
> match foo {
> Enum::ValA(a) => {},
> Enum::ValB => {},
> _ => {},
> }
> ```
>
> for example, you would drop the temporaries before entering the bodies of the `ValB` and `_` arms. Applied to `if let`, this would mean always dropping before `else`, and iff the pattern is binding free, also dropping before the then body.

TC: Josh nominated this issue. What do we think here?

NM: Mara, RJ, and I are proposing to change the rules in Rust 2024. Our proposal is even stronger in that we wouldn't even extend it into the then block. What we've observed is that the behavior in matches is a common source of bugs. I'm a bit skeptical about changing the execution order in earlier editions.

JT: I would have been as well. But we already did a change like this that was observed to have low impact.

NM: That one's a little different.

JT: It is, but here the proposal is to shorten the lifetime in a way that you can barely observe.

scottmcm: Can you have a pointer to something that goes away because it's ended.

pnkfelix: JT's example is one case, but I can imagine other cases where it would be reasonable to believe you were still holding a lock depending on which way you went.

JT: Do we feel like this is something where a crater run could guage impact?

NM: I'd feel better about a run that flagged examples and then we manually checked them.

NM: I'm not sure the test failures tell us enough.

NM: If we are going to adjust this for Rust 2024, then do we want to change the rules now, or should we leave it?

JT: This may be a blocker to `let-chains` in earlier editions.

JT: This is the first I've heard that your RFC work would shorter the lifetimes for `if-let`. So maybe we shouldn't block on a speculative RFC?

NM: I'm expecting the RFC to go out in the next month.

JT: This seems like something where just shortening the temporary lifetime wouldn't be incompatible with the RFC behavior.

NM: It'd be interesting to find out.

scottmcm: The most common pattern would be using the lock object to access the data.

NM: I want to think about this. I wouldn't make this decision super-lightly.

JT: If you have a concrete proposal for further investigation, could you post it to the issue?

scottmcm: Agree with NM there is danger here.

JT: I'd expect a race, if anything, here.

NM: But I'm not sure it'd show up as a test failure.

pnkfelix: This is making me regret not distinguishing drops with side effects.

*Consensus*: This needs more analysis and discussion.

TC: After the meeting, NM left a comment summarizing the concerns raised in this discussion:

https://github.com/rust-lang/rust/pull/107251#issuecomment-1779644448

(The meeting ended here.)

### "`c_unwind` full stabilization request: change in `extern "C"` behavior" rust#115285

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

TC: See also:

https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md

TC: This is in proposed FCP with two boxes checked. There's an open question of whether we should do a crater run here. What do people think? (And if that's what is needed, how can we make that happen?)

### "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.

### "Decision: semantics of the `#[expect]` attribute" rust#115980

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

TC: @nikomatsakis gives this background:

> This issue is spun out from #54503 to serve as the decision issue for a specific question. The question is what the 'mental model' for the `expect` attribute should be. Two proposed options:
>
> 1. The expectation is fulfilled, if a #[warn] attribute in the same location would cause a diagnostic to be emitted. The suppression of this diagnostic fulfills the expectation. ([src](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Expect.20attribute.20mental.20model/near/341522535)) (Current implementation in rustc)
> 2. The expectation is fulfilled if removing the `#[expect]` attribute would cause the warning to be emitted. ([src](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Expect.20attribute.20mental.20model/near/354082551))
>
> @xFrednet created a [list of use cases](https://hackmd.io/@xFrednet/expect-attr-use-cases) to help with the discussion of these two models; they found both models work equally well, except for [use case 4](https://hackmd.io/@xFrednet/expect-attr-use-cases#Use-case-4-Suppress-lints-from-CI) which would only be possible with the first model.

TC: ...and proposes that we adopt option 1.

### "`.await` does not perform autoref or autoderef" rust#111546

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

TC: This was nominated for T-lang (and for T-types) by WG-async. @tmandry said:

> We discussed this in a recent wg-async meeting ([notes](https://hackmd.io/G6ULofyXSIS4CK9u-jwYRg)). The consensus was that we thought the change was well-motivated. At the same time, we want to be cautious about introducing problems (namely backwards compatibility).
>
> There should probably be a crater run of this change, and we should also work through any problematic interactions that could be caused by this change. (@rust-lang/types should probably weigh in.)
>
> The main motivation for the change is the analogy to `.method()`, as well as to wanting async and sync to feel similarly convenient in most cases.
>
> Note that there is another analogy that works against this, the analogy to `IntoIterator`, where the lang-effect form (`for _ in foo {}`) does not do autoref/autoderef. However, given that this _looks_ very different from `foo.await`, and taking a reference with that form is significantly more convenient (`for x in &foo` or `for x in foo.iter()` vs `(&foo).await`), it seemed the analogy was stretched pretty thin. So we elected to put more weight on the above two considerations.
>
> That being said, this change would need lang team signoff. You can consider this comment wg-async's official recommendation to the lang team.

### "Tracking Issue for the Rust specification" rust#113527

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

TC: On 2023-10-12, pnkfelix [posted](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/unsticking.20us/near/396373682) a [vision document](https://hackmd.io/R_YYc4dXQCuOhCHPjqqudA) for the Rust specification. We all might want to have a look at that.

### "Support overriding `warnings` level for a specific lint via command line" rust#113307

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

TC: We discussed in the 2023-09-26 meeting, but were unsure of the question we were being asked. @jieyouxu has since replied:

> I believe I wanted to ask that if the command line indeed forms the root of the tree, or if it actually overrides the source annotations.

TC: On that basis, @tmandry replied:

> ### Nesting
>
> I think the command line (specifically `-A`, `-W`, `-D` flags) should form the root of the tree. We have `--cap-lints`, `--force-warn`, and `-F` (forbid) for overriding the source. (Actually the mental model documented in the [rustc book](https://doc.rust-lang.org/rustc/lints/levels.html) is that `force-warn` and `forbid` still form the root of the tree, but cannot be overridden; I think the distinction is mostly academic.)
>
> That's almost all the expressive power one could want along this axis. One wrinkle is that `--forbid` is overridden by `--cap-lints`, while `--force-warn` is not. If we wanted full fine-grained control we could always add `--force-allow` and `--force-deny`.
>
> ### `warnings`
>
> Regarding the meaning of `warnings`, it _is_ a simpler mental model for this to mean "the set of things that are warn-by-default". But this ignores what I perceive to be a common (and valid) use case, which is to disallow _all_ warnings in a codebase: In other words, prevent code from being checked in that causes warnings to be printed to a user's screen. Of course, for this to be practical one must control the version of rustc being used to build a codebase, but that is common in monorepo setups.
>
> ### Conclusion
>
> Given that there is an existing use case that relies on documented behavior, I think we should continue to treat `warnings` as a "redirect" for all warnings that come out of a particular level of the tree. Interpreting `-Awarnings -Wfoo` in the way proposed by this PR would muddy the (already complicated) mental model and add inconsistency between CLI and the command line, as noted by @oli-obk.
>
> A different group, like `default-warnings`, could be used to mean "the set of things that are warn-by-default". The compiler could further warn users that specify `-Awarnings -Wfoo` on the command line to use `-Adefault-warnings -Wfoo` instead.

### "Fix `non_camel_case_types` for screaming single-words" rust#116389

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

TC: @petrochenkov nominated this for us:

> A relaxed version of this PR could be bumping the length limit from 3 letters to 4. E.g. `ABC` would still be considered camel case, but `ABCD`/`ABCDF`/etc not.

This is related to [#116336](https://github.com/rust-lang/rust/issues/116336) and [#60570](https://github.com/rust-lang/rust/issues/60570).

### "dyn Trait comparison should not include the vtable pointer" rust#106447

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

TC: The FCP to close this issue has been completed. However, @Amanieu is still [looking](https://github.com/rust-lang/rust/issues/106447#issuecomment-1566147477) for a way forward. There's been some [discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/dyn.20Trait.20pointer.20comparisons) on Zulip about this.

TC: We discussed this in the 2023-09-26 triage meeting without a full resolution, but decided that adding `ptr::addr_eq` may be one small step forward. scottmcm has now opened a PR for this:

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

TC: The next step seems to be to write the stabilization report.

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

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

TC: We discussed in the 2023-09-26 meeting. We decided to simply let T-libs-api know about what we had discussed. Niko [left a comment](https://github.com/rust-lang/rust/pull/106418#issuecomment-1736377423) to the effect that "right now we seem to have no good options."

TC: There has since been further discussion on the issue. E.g., Amanieu noted:

> While discussing this in the libs-api meeting today, we noticed that the documentation for `mem::discriminant` [doesn't guarantee stability for the discriminant](https://doc.rust-lang.org/nightly/std/mem/fn.discriminant.html#stability). This means that the actual ordering of `Discriminant` is _not_ tied to the source code order of the variants.
>
> This makes it unsuitable for many use cases, including the one in the PR description, which is to manually implement `Ord` for an enum. To enable this use case, we need to guarantee that the ordering of `Discriminant` matches that of the variants in the source code.

TC: Do we have any further thoughts here?

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

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

TC: This proposed RFC is scheduled for a design meeting on 2023-10-25.

TC: We last discussed this on 2023-09-26. We decided that this needed more discussion and that we'd leave a comment about what was discussed in the issue. Niko [posted](https://github.com/rust-lang/rfcs/pull/3437#issuecomment-1736102047) that comment.

## Action item review

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

## Pending lang team project proposals

None.

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## `S-waiting-on-team`

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

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

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

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

### "remove 'illegal_floating_point_literal_pattern' future-compat lint" rust#116098

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

## Proposed FCPs

**Check your boxes!**

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

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

### "unsafe attributes" rfcs#3325

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

### "Lifetime Capture Rules 2024" rfcs#3498

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

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

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

### "Stabilise inline_const" rust#104087

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

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

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

### "TAIT defining scope options" rust#107645

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

### "Report monomorphization time errors in dead code, too" rust#112879

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

### "FCP process: Require 2/3 majority for FCP" rust#114986

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

### "`c_unwind` full stabilization request: change in `extern "C"` behavior" rust#115285

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

### "Decision: semantics of the `#[expect]` attribute" rust#115980

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

### "Stabilize `const_maybe_uninit_zeroed` and `const_mem_zeroed`" rust#116218

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

### "document that the null pointer has the 0 address" rust#116988

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

## Active FCPs

### "Tracking Issue for const `mem::discriminant`" rust#69821

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

### "Stabilize Ratified RISC-V Target Features" rust#116485

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

## P-critical issues

None.