---
title: Triage meeting 2023-12-06
tags: ["T-lang", "triage-meeting", "minutes"]
date: 2023-12-06
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202023-12-06
url: https://hackmd.io/Jtaa3G0SSsuSpZt897l2iQ
---

# T-lang meeting agenda

- Meeting date: 2023-12-06

## Attendance

- People: TC, Josh, scottmcm, pnkfelix, tmandry, eholk, waffle, Santiago, Urgau

## Meeting roles

- Minutes, driver: TC

## Scheduled meetings

- 2023-12-06 - Planning meeting.

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!)

## Nominated RFCs, PRs, and issues

### "Introduce support for `async gen` blocks" rust#118420

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

TC: We have an ongoing experiment for `gen { .. }` blocks. CE is working on `async gen { .. }` blocks and wants the nod from T-lang that this can land under the auspices of the same initiative and experiment.

TC: scottmccm [said](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Generators.2C.20lang-team.20experiments.2C.20RFCs.2C.20oh.20my!/near/406164586):

> (Speaking for me, not the team)
>
> It's generally my policy that the compiler team can land unstable things at their own discretion, assuming they're properly feature-gated and that the people landing the code acknowledge that lang still has the right to say "that's nice; we're nevertheless not going to stabilize it".
>
> For this case specifically, so as long as it didn't land reserving a keyword, I'm happy to see it in nightly.... We discussed it enough in lang meetings that I think it's fine to consider it seconded enough to nightly under the "an experienced contributor" path -- which does need a full FCP before it could be stabilized.

TC: There's a lot of overlap between these. I propose we give that nod.

scottmcm: This seems default approve.

tmandry: I'd like to see this land personally.

Josh: Yeah, let's see this experiment. We can always make a decision later on stabilization.

*Consensus*: Let's land this.

### "Enforce `must_use` on associated types and RPITITs that have a must-use trait in bounds" rust#118504

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

TC: CE nominated this for us:

> Warn when an RPITIT or (un-normalized) associated type with a `#[must_use]` trait in its bounds is unused.
>
> This is pending T-lang approval, since it changes the semantics of the `#[must_use]` attribute slightly, but I think it strictly catches more strange errors.
>
> I could also limit this to just RPITITs, but that seems less useful.

E.g.:

pub trait Tr {
    fn foo() -> impl std::future::Future<Output = ()>;
}

pub async fn bar<T: Tr>() {
    T::foo(); //~ Doesn't warn currently.
}

TC: Are we OK with this?

tmandry: Seems like applying `must_use` to more places where it should be applied.

Josh: Seems like an obvious bug fix.

scottmcm: RPIT cares and `dyn` cares. So I'm happy to say anything like that should do this. And it's all just lints.

pnkfelix: +1.

Josh: I'll write the comment.

*Consensus*: Let's do this.

### "Overflow check is not removed from naive strlen" rust#117003

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

TC: The issue is:

> The overflow check for the addition here is not removed. If we overflow the length then we have wrapped around address space, and the use of `ptr::add` guarantees that we didn't.
>
> ```rust
> pub unsafe fn strlen(mut s: *const core::ffi::c_char) -> usize {
> let mut n = 0;
> while *s != 0 {
> n += 1;
> s = s.add(1);
> }
> n
> }
> ```
>
> Godbolt: https://godbolt.org/z/dGYWKfeeP Alive2: https://alive2.llvm.org/ce/z/T7yFbc

TC: lcnr had communicated to me shortly before the meeting that he would like to see this merged.

scottmcm: I'm not sure what exactly is talking about being merged here? It's an issue, not a PR. Maybe there was a typo here.

TC: Agreed. I've double-checked it on my side, but it looks like what came to me must have had some error. I've asked lcnr to clarify.

*Consensus*: We'll review after sorting this out.

### "Stabilize THIR unsafeck" rust#117673

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

TC: We discussed on 2023-11-29 and decided we wanted to hear from T-opsem. RalfJ has since replied:

> Great to see this project nearing completion. :)
>
> IIUC, this makes strictly _more_ code unsafe than was unsafe before? If so, no concerns from my side. ;)...

After the meeting, scottmcm mentioned:

> One thing I'm uncertain about: I see far fewer scopes in the MIR tests. Now, overall I'm generally happy for that, since simpler MIR good, but I'm not sure how changing the unsafe checker is changing the MIR build(?)ing? Is there another change in here? I'm paranoid about accidental scoping changes for `Drop`s.

The author has since responded:

> I'll remove the MIR changes and MIR unsafeck removal and rebase once this has lang team sign-off.

TC: Are there any open questions that need answering before we propose FCP merge?

Josh: This is about separating it?

TC: Right, it would make it easier to undo on a regression.

scottmcm: I was about to FCP it before seeing it was mixed together.

pnkfelix: Let's tell the person to do what they said they'd do.

scottmcm: We could FCP merge and file an immediate concern.

Josh: It's not the lang team's role to review the precise PR. It's our job to say what content we're expecting.

waffle: The author is saying they don't want to change it and rebase until they're sure T-lang wants to move forward.

Josh: +1.

pnkfelix: +1.

pnkfelix: I'll FCP merge.

*Consensus*: Let's do this.

### "static mut: allow mutable reference to arbitrary types, not just slices and arrays" rust#117614

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

TC: RalfJ nominated this for us:

> For historical reasons, we allow this:
>
> ```rust
> static mut ARRAY: &'static mut [isize] = &mut [1];
> ```
>
> However, we do not allow this:
>
> ```rust
> static mut INT: &'static mut isize = &mut 1;
> ```
>
> I think that's terribly inconsistent. I don't care much for `static mut`, but we have to keep it around for backwards compatibility and so we have to keep supporting it properly in the compiler. In recent refactors of how we deal with mutability of data in `static` and `const`, I almost made a fatal mistake since I tested `static mut INT: &'static mut isize = &mut 1` and concluded that we don't allow such `'static` mutable references even inside `static mut`. After all, nobody would expect this to be allowed only for arrays and slices, right?!?? So for the sake of our own sanity, and of whoever else reverse engineers these rules in the future to understand what the Rust compiler accepts or does not accept, I propose that we accept this for all types, not just arrays and slices.

TC: Josh proposed FCP merge after the 2023-11-29 meeting where we didn't quite make it to this issue. Is there anything we'd like to discuss here?

scottmcm: Why are mutable references allowed in mutable statics but not statics? I wish we could just kill this.

Josh: As long as it exists, let's be consistent about it.

scottmcm: Do we know how this divergence came about?

Josh: I'm guessing it's because e.g. `&'static'...`.

scottmcm: Right, because we don't have unsized statics.

scottmcm: As RalfJ said here, consistency is probably better than making sense.

scottmcm: I wonder if we should just make unsized statics work.

*Consensus*: Let's do this.

### "revert stabilization of const_intrinsic_copy" rust#117905

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

TC: RalfJ nominated this for us:

> @rust-lang/wg-const-eval I don't know what we were thinking when we approved #97276... const-eval isn't supposed to be able to mutate anything yet! It's also near impossible to actually call `copy` in const on stable since `&mut` expressions are generally unstable. However, there's one exception...
>
> ```rust
> static mut INT: i32 = unsafe {
> let val = &mut [1]; // `&mut` on arrays is allowed in `static mut`
> (val as *mut [i32; 1]).copy_from(&[42], 1);
> val[0]
> };
>
> fn main() { unsafe {
> dbg!(INT);
> } }
> ```
>
> Inside `static mut`, we accept some `&mut` since ~forever, to make `static mut FOO: &mut [T] = &mut [...];` work. We reject any attempt to actually write to that mutable reference though... except for the `copy` functions.
>
> I think we should revert stabilizing these functions that take `*mut`, and then re-stabilize them together with `ptr.write` once mutable references are stable.
>
> (This will likely fail on PowerPC until [rust-lang/stdarch#1497](https://github.com/rust-lang/stdarch/pull/1497) lands. But we'll need a crater run first anyway.)

This was stabilized over a year ago.

T-libs-api has agreed to revert the stabilization. Amanieu:

> We discussed this in the libs-api meeting today. We agree that this should never have been stabilized. Seeing as this has been stable for over a year, we considered just disallowing this at const-eval-time, which is what #118324 does. However we agree with @RalfJung that the fact that this function is even available in `const fn` "encourages" people to write code that has UB. As such we are in favor of reverting the stabilization.

TC: What do we think?

scottmcm: I agree. It seems strange, but it makes sense, because it's the one hole in, "no you don't get reference-wise mutability in const".

Josh: +1, we should sign off on this.

tmandry: We verified the econsystem impact?

Josh: There was a crater run.

scottmcm: I want to treat this as a bug. But this was talked about very explicitly. It even had RalfJ sign-off. But I'm willing to trust the analysis.

waffle: The main point here was that this may funnel users into writing UB. Until we provide a way to use mutable references in const, then we can restabilize it.

*Consensus*: Let's do it, or undo it, as the case may be.

### "lint “non_upper_case_globals” wrongly warns the consumer" rust#25207

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

TC: The main issue here seems to be that the person whose code is getting the warning is not necessarily well positioned to change the name, and the upstream who is well placed to change the name may have already silenced this warning but we still warn in the downstream code.

TC: Do we agree on whether this should be fixed and what that would mean?

waffle: Why do we even lint on uses and not just definitions?

scottmcm: We usually don't lint on uses. So I agree with this one. We even said recently that if you use field shorthand in a pattern that we don't want to warn as you're just adopting someone else's decision.

For example, if someone else had `struct Foo { BAR: u32 }` and you do `let Foo { BAR } = foo;` then we don't lint today on the `let`, just on the `struct` declaration (if not suppressed).

waffle: This is another case of the binding vs use distinction.

scottmcm: This is the 30 year old problem we adopted from SML.

scottmcm: We could force the use site to use a path. But maybe that's more of a clippy lint.

Josh: I could see this as a rustc lint. It should be a different lint though about this specific ambiguity.

scottmcm: We have a lint for bindings that look like variants. But we don't have one for constants.

Josh: We could say to give the full path. For things in the same module, do we want to say, use `self::`?

scottmcm: It's still ambiguous there, but if they've suppressed the lint for the whole crate, then the author has probabaly already addressed it.

Josh: This comes up in FFI code where you're matching non-Rust code. It can be annoying. Maybe the answer is that they should suppress the new lint as well.

tmandry: If you're importing these constants, that might mean that you're also in a context where it's obvious what you mean. I'm not sure it's relevant which module in your crate in which it's defined.

tmandry: I guess I'm saying, even if it is a different crate, if you're doing a wildcard import of these constants, you might be in a context where you want to think about these... It shouldn't matter whether it's in the same crate.

pnkfelix: Theoretically you could rename these when importing.

scottmcm: The issue is that these may be well-known names from the FFI.

pnkfelix: One idea would be to change the language to make it clear whether this is a binding.

scottmcm: We have const blocks on nightly.

pnkfelix: But don't have the other way of forcing it to be a binding.

scottmcm: Maybe `mut` const.

pnkfelix: I like your thinking. If we added `let` there.

Josh: It sounds like there is support for a lint to catch problems. We could say we'd like a separate lint here with ways to usefully suppress that. Then defer the fine-tuning of the details.

pnkfelix: We do have a syntax for this today `id @ _`.

Josh: I'll write a comment about this.

*Consensus*: We're in favor of a separate lint here. The problem is that this is the same lint. And that lint should suggest what people should do to suppress it.

### "Extend `UNUSED_LIFETIMES` lint to detect lifetimes which are semantically redundant" rust#118391

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

TC: lcnr nominated this for us:

> > There already is a `UNUSED_LIFETIMES` lint which is fired when we detect where clause bounds like `where 'a: 'static`, however, it doesn't use the full power of lexical region resolution to detect failures.
>
> This now adds the following warnings as part of the `unused_lifetimes` lint.
>
> ```rust
> #![allow(unused)]
> #![deny(unused_lifetimes)]
>
> fn a<'a, 'b>(x: &'a &'b &'a ()) {} //~ ERROR unnecessary lifetime parameter `'b`
>
> fn b<'a: 'b, 'b: 'a>() {} //~ ERROR unnecessary lifetime parameter `'b`
>
> struct Foo<T: 'static>(T);
> fn c<'a>(_: Foo<&'a ()>) {} //~ ERROR unnecessary lifetime parameter `'a`
>
> struct Bar<'a>(&'a ());
> impl<'a> Bar<'a> {
> fn d<'b: 'a>(&'b self) {} //~ ERROR unnecessary lifetime parameter `'b`
> }
>
> fn ok(x: &'static &()) {} // ok, we do not suggest naming anonymous lifetimes
>
> trait Tr<'a> {}
> impl<'a: 'static> Tr<'a> for () {} //~ ERROR unnecessary lifetime parameter `'a`
> ```
>
> This lint is `ALLOW`-by default right now, should probably add a structured suggestion here and increase it to `WARN` in a separate PR.
>
> T-lang nominating as I on how to proceed here, does this require an FCP? I think even though "detecting whether lifetimes are semantically equal" is very much a T-types question, the decision whether to lint this is completely owned by @rust-lang/lang. I personally believe it to be a clear yes.

TC: Do we agree this is a clear yes?

TC: (Do we need to take any care since early-bound lifetime parameters against which we would linting might be part of a stable API for the function?)

scottmcm: I like the idea of the lint, but I feel like it should be a separate lint. It's not unused, it's unnecessary.

waffle: I think the same goes for other cases where this lint is already fired. E.g. `where 'a: 'static`. This is also unnecessary but not unused.

pnkfelix: You're saying we could just rename the lint? Alliemjay made a comment yesterday that this should be a separate lint due to macro-generated code.

Josh: So that macros could suppress only one lint?

pnkfelix: I think it was about separating which should be warn-by-default.

Josh: We today have the ability to warn-by-default but suppress the warning in macro-generated code.

scottmcm: I'm not sure that macros wouldn't want to just suppress both of these.

waffle: To answer pnkfelix's question. There already do seem some cases where the name is not correct. But it may also lint on cases where the name is appropriate. So maybe we should add a second one and move some cases from one to the other.

tmandry: I'm in favor of either renaming it or splitting it and moving some behavior to the new name.

scottmcm: Do we know why it's not already warn-by-default?

*Consensus*: We do want to lint on these cases, but we'd like to see more analysis about whether either this lint should be renamed or whether this should be split into two lints potentially moving some existing linting behavior from one to the other.

### "Properly reject `default` on free const items" rust#117818

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

TC: fmease explains:

> The following code compiles successfully while it should lead to an error due to the presence of the contextual keyword `default` on the _free_ constant item:
>
> ```rust
> default const K: () = ();
> fn main() {}
> ```
>
> The AST validation code was incorrectly implemented and only rejects `default` on free const items that _don't_ have a body:
>
> ```rust
> default const K: ();
> ```
>
> Technically speaking, this is a breaking change but I doubt it will lead to any real-world regressions (maybe in some macro-trickery crates?). Doing a crater run probably isn't worth it.

TC: Though it was nominated, we never discussed this in triage, and on 2023-11-22, scottmcm proposed FCP merge with:

> Personally I'd be fine considering this a bug fix, since it's clearly not something that was ever supposed to work.
>
> Let's see if the team agrees.

TC: Do we agree?

scottmcm: This felt to me like other technically-breaking changes that we've approved. `default` used in this way has never been stable for anything.

tmandry: Agree we should merge it. I've checked my box.

*Consensus*: Let's do this.

### "incorrect UB when when a `!` place is constructed (but not loaded!)" rust#117288

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

TC: @RalfJ found some interesting examples where `rustc` generates SIGILL on code that shouldn't have UB. T-compiler marked this P-high. RalfJ:

> Nominating this to get first vibes on which of the following lines should be accepted, and which should be UB. (Currently they are all accepted and all UB but that's a bug.)
>

#![feature(never_type)]
fn deref_never<T>() {
    unsafe {
        let x = 3u8;
        let x: *const ! = &x as *const u8 as *const _;
        let _val = addr_of!(*x); // must be OK
        let _ = *x; // should probably be OK since we said `_` discards the place (and is UB-equivalent to `addr_of!`)
        let _: ! = *x; // does a no-op type annotation force the place to be loaded and hence cause UB?
        let _: () = *x; // is this UB? should we even accept such code?
        let _: String = *x; // what about this?
        let _: T = *x; // is this UB even if T = ! ?
    }
}

TC: I asked RalfJ for a proposal for the right behavior on the ones with question marks. RalfJ:

> I don't know how to arrive at a principled answer to this. There's no obvious "correct" here, it's a judgment call.
>
> If you are asking for my personal preference ignoring backwards compatibility constraints, then my immediate gut feeling is that _places_ of type `!` should not be subject to never-to-any coercions (the coercion should apply only to _values_, matching the comment that justifies the coercion in the first place). So:
>

        let _: ! = *x; // OK, not UB
        let _: () = *x; // does not compile
        let _: String = *x; // does not compile
        let _: T = *x; // does not compile

TC: What do we think?

scottmcm: This feels thorny. It's a good question.

scottmcm: Maybe we should dig into this in the planning meeting if we have time, since it's P-high.

*Consensus*: Let's think about this and maybe dig into this in planning.

### "RFC: Associated const underscore" rfcs#3527

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

TC: dtolnay proposes this RFC:

> Allow `_` for the name of associated constants. This RFC builds on [RFC 2526](https://github.com/rust-lang/rfcs/pull/2526) which added support for free `const` items with the name `_`, but not associated consts.
>

// RFC 2526 (stable in Rust 1.37)
const _: () = { /* ... */ };

impl Thing {
    // this RFC
    const _: () = { /* ... */ };
}

>
> Constants named `_` are not nameable by other code and do not appear in documentation, but are useful when macro-generated code must typecheck some expression in the context of a specific choice of `Self`.
>
> [Rendered](https://github.com/dtolnay/rfcs/blob/assocunderscore/text/0000-associated-const-underscore.md)

Then programmerjake asked a critical question:

> When does associated const code get run? at type definition? when substituting concrete types into generic arguments? never? so, if I write:
>

pub struct S<T>(T);

impl<T> S<T> {
    const _: () = assert!(core::mem::size_of::<T>() % 2 == 0);
}

>
> when does the `assert` get run?

scottmcm nominated this for discussion:

> I was all set to propose merge as "of course" until I saw the note about evaluation :/
>
> I do agree that not evaluating it is consistent with named associated constants.
>
> Unfortunately, I feel like it would be particularly likely for someone to move a `const _: () = assert!(...);` into an associated constant and not notice that it's just never running.

scottmcm: This is going to be a complicated conversation. It's tricky. I like Niko's point below. It'd be good to have a real feature.

Josh: We have `const _`, which does evaluate things in addition to type checking them. The question here is what to do here, since there's no reason it would ever be run.

Josh: Does the RFC cover why it wouldn't be evaluated?

scottmcm: Not sure.

TC: There seems a consistency argument on two fronts. We allow `const _`, and we don't evaluate unused associated constants.

Josh: Let's make sure that's covered in the RFC.

Josh: I just skimmed it and it doesn't cover this as well as we might want. There's no discussion in the RFC of why it's OK to not evaluate.

Josh: One future possibility was to allow the type but not the body, but that doesn't solve what the RFC was trying to solve.

scottmcm: hmm, then I can write `const _: TakesUnitAsGeneric<{ your_expression(); }>;`

Josh: We should acknowledge the problem proposed is a problem.

*Consensus*: Let's ask for the RFC to cover explicitly that it's not evaluated and make a proposal, and discuss why that's OK and wouldn't be too error prone.

(The meeting ended here.)

---

TC: As an aside of the main point here, Niko noted:

> One further thought: the whole `const _: () = { .. }` thing was a total hack -- albeit, a useful one. I do wonder if it's time to add something more first-class, e.g. "anonymous modules", something like that.

TC: Writing an RFC for anonymous modules is something I've been intending to do, as it could have some utility for TAIT and the 2024 lifetime capture rules.

### Document that (left arrow) is a single token reference#1424

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

TC: The question is whether to add this line to the reference:

> | `<-` | LArrow | The left arrow symbol has been unused since before Rust 1.0, but it is still treated as a single token

The background, per mattheww, is that:

> `<-` was the "move operator", removed in Rust 0.5, but is still lexed as a single token.

ehuss notes:

> Since there was an attempt to remove this that was then later backed out, I'm assuming the language team agrees that the emplacement operator has to stay permanently. However, I'm not 100% sure based on [rust-lang/rust#50832 (comment)](https://github.com/rust-lang/rust/issues/50832#issuecomment-389884751).
>
> Since I'm not completely confident that the language team doesn't want to try to remove this in the future, I'm going to nominate this for their attention for approval. I think this PR probably should be merged. I wouldn't be surprised if there were more macros using it since the last time it was attempted to be removed.

Back in 2018, Niko had said:

> Discussed in the @rust-lang/compiler meeting. I think we reached this consensus:
>
> * in this case, yes, we should do as @petrochenkov suggests: keep parsing, error in AST validation
> * if in the future, if it happens that we want to repurpose the syntax, we deal with it then: best of course is to use an edition for it, but maybe by then there no longer exist crates using it
> * going forward, it would be ideal if we could do some kind of "pre-cfg / expansion" feature check to try and avoid this in the future; that may or may not be feasible though, and we couldn't do it retroactively for all existing things anyway

On 2023-11-25, scottmcm proposed FCP merge:

> I agree that we should reflect what's actually happening in the reference.
>
> (And I think that it's not worth trying to change the lexing rules for this at this point.)

TC: Do we agree?

### "Add `wasm_c_abi` `future-incompat` lint" rust#117918

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

TC: daxpedda gives the context:

> This is a warning that will tell users to update to `wasm-bindgen` v0.2.88, which supports spec-compliant C ABI.
>
> The idea is to prepare for a future where Rust will switch to the spec-compliant C ABI by default; so not to break everyone's world, this warning is introduced.
>
> Addresses https://github.com/rust-lang/rust/issues/71871

TC: Is this something we want to do?

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

### "Remove ability to disable some target features" rust#116584

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

TC: RalfJ nominated this one, and he has a corresponding design meeting proposal:

> We'd like to remove the ability to disable certain target features. The broad goal we are going for here is that **code built for the same target is ABI-compatible no matter the target features**. This is an easy rule to remember and a principle that it seems reasonable to enforce. This principle is currently violated in several ways (for x86, that's tracked in #116344 and #116558). This PR is one part of achieving that, [this pre-RFC](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Pre-RFC.20discussion.3A.20Forbidding.20SIMD.20types.20w.2Fo.20features) is another part, and then one final piece is needed to reject `+x87`/`+sse` on `x86_64-unknown-none` (or to reject float-taking/float-returning-functions) as that would similarly change the ABI.
>
> ...
>
> I have created a [design meeting proposal](https://github.com/rust-lang/lang-team/issues/235) for the wider problem space here, in case you think this needs more fundamental discussion.

TC: Do we want to handle this in a design meeting or do we think we have enough clarity on it?

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

TC: There's now been a crater run done for this. The result was that this breaks a small number of crates, but at least one of those crates has a large number of dependencies (`aws-smithy-runtime`). It can be fixed in the dependency in such a way that dependent crates do not have to make changes, but those dependent crates would need to update to a fixed version of the dependency.

(See this [discussion](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/Perform.20autoref.2Fautoderef.20on.20.2Eawait.20-.20.23111773).)

TC: What do we think?

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

TC: Where do we want to go from here?

### "TAIT decision on whether nested inner items may define" rust#117860

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

TC: The question is whether this should be true:

> Unless and until [RFC PR 3373](https://github.com/rust-lang/rfcs/pull/3373) is accepted and scheduled for stabilization in some future edition, items nested inside of other items may define the hidden type for opaques declared outside of those items without those items having to recursively be allowed to define the hidden type themselves.

The context is that we allow this:

trait Trait {}
struct S;
const _: () = {
    impl Trait for S {} // Allowed.
};

Should we accept spiritually-similar TAIT code unless and until we decide to go a different direction with the language?

### "TAIT decision on "may define implies must define"" rust#117861

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

TC: The question is whether this should be true:

> At least until the new trait solver is stabilized, any item that is allowed to define the hidden type of some opaque type *must* define the hidden type of that opaque type.

TC: This is important for the new trait solver.

TC: Here's one reason for that. The new trait solver treats strictly more code as being a defining use. It's also more willing to reveal the hidden type during inference if that hidden type is defined within the same body. This rule helps to avoid inference changes when moving from the old solver to the new solver. Adding this restriction makes TAIT roughly equivalent to RPIT with respect to these challenges.

TC: (This question is entirely orthogonal to how we notate whether an item is allowed to define the hidden type of an opaque.)

### "TAIT decision on "may not define may guide inference"" rust#117865

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

TC: The question is whether this should be true:

> The compiler is allowed to rely on whether or not an item is allowed to define the hidden type of an opaque type to guide inference.

Here's the door that this would close:

> If this rule is adopted, then after TAIT is stabilized, it will not be possible in a fully backward compatible way to later change the rules that determine whether or not an item is allowed to define the hidden type in such a way that an item in existing code that uses an opaque type could switch (without any code changes) from being not allowed to define its hidden type to being allowed to define it.

TC: This is of importance to the new trait solver.

TC: Here's one reason for this. When we're type checking a body and we find an opaque type, we sometimes have to decide, should we infer this in such a way that this body would define the hidden type, or should we treat the type as opaque (other than auto trait leakage) and infer based on that? Depending on that, we can get different answers.

TC: If we did not let inference rely on this, then we would be closing the door on later *allowing* inference to rely on this without provoking changes in inference.

TC: (This question is entirely orthogonal to how we notate whether an item is allowed to define the hidden type of an opaque. Answering this question in the affirmative would update one element of the [#107645 FCP][].)

[#107645 FCP]: https://github.com/rust-lang/rust/issues/107645#issuecomment-1571789814

### "TAIT decision on "must define before use"" rust#117866

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

TC: The question is whether the following should be true:

> If the body of an item that may define the hidden type of some opaque does define that hidden type, it must do so syntactically _before_ using the opaque type in a non-defining way.

One of the big design questions on TAIT is whether we'll be able to later lift the "may define implies must define" rule after we land the new trait solver. The answer to that question could inform other design decisions, such as how to notate whether an item is allowed to define the hidden type of an opaque.

The restriction here is designed to make it more likely (hopefully much more likely) that we can later lift the "may define implies must define" restriction.

### "Arbitrary self types v2." rfcs#3519

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

TC: We discussed this extensively in the meeting on 2023-11-22 resulting in:

> *General outcome*: We want to find some way to enable this, including for raw pointers and `NonNull` and (maybe) `Weak` but we don't know how to do that yet. We'd like more discussion about either the resolution rule Josh proposed or about what a type is committing to when it implements Receiver with respect to adding new methods. And we'd like more discussion about why the RFC distinguished `NonNull` and raw pointers.

TC: The author is making some updates.

### "Uplift `clippy::precedence` lint" rust#117161

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

TC: The proposal is to lint against:

-2.pow(2); // Equals -4.
1 << 2 + 3; // Equals 32.

These would instead be written:

-(2.pow(2)); // Equals -4.
1 << (2 + 3); // Equals 32.

Prompts for discussion:

- Is this an appropriate lint for `rustc`?
- How do other languages handle precedence here?
- Is minus special enough to treat differently than other unary operators?

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

### "RFC: constants in patterns" rfcs#3535

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

TC: On the basis of our 2023-10-18 design meeting, RalfJ wrote up this RFC and nominated it for us.

TC: Probably everyone should have a look asynchronously.

### "Match ergonomics means bindings have different types in patterns and match arm; cannot deref references in pattern" rust#64586

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

TC: There's a lot to consider here. This may need a design meeting.

### "Undeprecate lint `unstable_features` and make use of it in the compiler" rust#118639

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

TC: This is pending a write-up for the nomination. Let's discuss when that is done.

fmease: I nominate this for you:

> There exist some rustc crates that ought to compile on stable for use in rust-analyzer.
> These crates (namely: `rustc_lexer`, `rustc_parse_format`) should not use any `#![feature]`s.
> Currently this is only enforced by comments which lead to a mass-update PR to accidentally disregard this policy (it was missed by the author and the reviewer).
>
> I propose to undeprecate the lint `unstable_features` to enforce this rule automatically.
> According to https://github.com/rust-lang/rust/issues/117937#issuecomment-1812951636, the lint was previously deprecated because it was replaced by a hard error (*`#![feature]` may not be used on the stable release channel*).
>
> **Alternative**: In CI, build those crates with `RUSTC_BOOTSTRAP=0` instead. CON: Bootstrap needs to hard-code a list of “stable crates”. PRO: Nothing needs to be undeprecated.
>
> There also exists `rustc_type_ir` where we could use the lint in the form of `#![cfg_attr(not(feature = "nightly"), deny(unstable_features))]` (and build it twice, once with feature `nighly` and once without it and maybe with `RUSTC_BOOTSTAP=0`, too, for good measure).

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

## RFCs waiting to be merged

None.

## `S-waiting-on-team`

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

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

### "make matching on NaN a hard error" rust#116284

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

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

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

### "warn less about non-exhaustive in ffi" rust#116863

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

### "Add lint against ambiguous wide pointer comparisons" rust#117758

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

### "guarantee that char and u32 are ABI-compatible" rust#118032

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

### "Undeprecate lint `unstable_features` and make use of it in the compiler" rust#118639

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

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

### "MaybeDangling" rfcs#3336

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

### "add float semantics RFC" rfcs#3514

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

### "Stabilise inline_const" rust#104087

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

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

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

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

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

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

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

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

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

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

### "References refer to allocated objects" rust#116677

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

### "Prevent opaque types being instantiated twice with different regions within the same function" rust#116935

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

### "Stabilize Wasm target features that are in phase 4 and 5" rust#117457

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

### "Stabilize Wasm relaxed SIMD" rust#117468

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

### "static mut: allow mutable reference to arbitrary types, not just slices and arrays" rust#117614

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

### "Support async recursive calls (as long as they have indirection)" rust#117703

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

### "Properly reject `default` on free const items" rust#117818

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

### "revert stabilization of const_intrinsic_copy" rust#117905

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

## Active FCPs

### "Exhaustiveness: reveal opaque types properly" rust#116821

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

### "Add lint against ambiguous wide pointer comparisons" rust#117758

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

### "guarantee that char and u32 are ABI-compatible" rust#118032

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

## P-critical issues

None.