---
title: Triage meeting 2023-11-15
tags: T-lang, triage-meeting, minutes
date: 2023-11-15
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202023-11-15
url: https://hackmd.io/KFtrWlLVQHm_j2voILDXoA
---

# T-lang meeting agenda

- Meeting date: 2023-11-15

## Attendance

- People: TC, tmandry, scottmcm, JT, waffle, eholk

## Meeting roles

- Minutes, driver: TC

## Scheduled meetings

- 2023-11-15: "2024 Edition Review" [#234](https://github.com/rust-lang/lang-team/issues/234)
- 2023-11-29: "weak alias types for Rust 2024" [#227](https://github.com/rust-lang/lang-team/issues/227)

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

### "Disallow future-incompatibility lints in the next edition" rust#117921

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

TC: We'll be discussing more general 2024 edition issues later today, but this issue seems it should be discussed separately with priority. tmandry gives the context:

> We have quite a long list of [future-incompatibility lints](https://github.com/rust-lang/rust/labels/C-future-compatibility) that are waiting to be made into hard errors. The lints are so severe that we warn even when they are used by a dependency of the crate being built, because they will cause the crate to stop compiling at some point in the future.
>
> We could use the edition as an impetus to switch some or all of these lints over to hard errors (or deny-by-default lints). Note that because of the way editions work this would only affect the crate being upgraded, not its dependencies. This would mean pairing the carrot with the stick, so to speak; if any of the crates triggering these errors are upgraded to the edition they will also need to have their future-incompat issues fixed. It also means that new code (using the latest edition) won't be written that triggers these lints.
>
> On the other hand it's unlikely that the crates with future-incompat issues are being maintained in the first place, so this wouldn't do much to help the problem.
>
> Opening this issue for discussion and consideration by the lang team.
>
> For some background on past editions, see [#80165 (comment)](https://github.com/rust-lang/rust/issues/80165#issuecomment-791583502).

TC: There are 39 of these issues open, though not all are plausible candidates. Let's maybe take a few of these per meeting.

tmandry: I don't see any reason to make these at least deny-by-default lints. We could even make them hard errors and it wouldn't impact your downstream crates. So I don't see a reason to not do this.

waffle: Can we make it an automatic rule to always make future-incompat lints into hard errors in the next edition?

tmandry: Probably, in general.

JT: I don't see a reason to not do this either.

TC: Do we want to do these all by meeting consensus or by FCP?

tmandry: I was leaning toward FCP.

JT: Probably that.

TC: Should we FCP each of these or FCP a policy decision?

JT: I'm not sure whether we were clear in the past when making things future-incompat lints about what we intended.

scottmcm: We've discussed in the past this isn't exactly clear. The future-incompat lint actually means that we might break this without an edition at all. And of course, the compiler still has to support it in older editions.

JT: It does mean that a feature in a new edition doesn't need to consider the disallowed thing.

scottmcm: But we try to not add features only to new editions.

scottmcm: I really doubt that lang has made a strong decision for each of these lints.

JT: If we wanted to FCP a policy that all future-incompat lints are meant to be hard errors in future/all editions, we could do that for all such lints going forward.

JT: I'd also be OK with FCPing together making all the lints into errors in a future edition, but not for the current edition.

scottmcm: That would raise the bar on adding these lints, since we'd be committing to not change our mind.

*Consensus*: Let's maybe write up an RFC for a new policy. And let's have someone propose which should be errors in every edition and which should be errors in the next edition.

### Tracking Issue for `BYTE_SLICE_IN_PACKED_STRUCT_WITH_DERIVE` lint - #107457

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

TC: nnethercote gives the context:

> The lint detects cases where `derive` is used with a `packed` struct that contains a `[u8]` field.
>
> This lint will trigger for code like this:
>
> ```rust
> #[repr(packed)]
> #[derive(Eq, PartialEq)]
> pub struct FlexZeroSlice {
> width: u8,
> data: [u8], // triggered
> }
> ```
>
> At some point in the future this case will be disallowed.
>
> See #104429 for more details, especially the [t-lang nomination](https://github.com/rust-lang/rust/pull/104429#issuecomment-1320909245).

*Consensus*: Given the outcome above, we'll defer discussion of this.

### Multiple incompatible clashing extern fn's should be a hard error (potentially phased in via future-incompat) - #105146

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

TC: @pnkfelix gives the context:

> I tried this code ([playpen](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=5e85b3be710d8d1383fa313e6b1e832b)):
>
> ```rust
> pub mod a {
> use std::ffi::c_int;
> extern "C" { fn isalpha(_: c_int) -> c_int; }
> pub fn wrap(x: c_int) -> c_int { unsafe { isalpha(x) } }
> }
>
> pub mod b {
> use std::ffi::c_int;
> extern "C" { fn isalpha(_: c_int, _: c_int) -> c_int; }
> pub fn wrap(x: c_int, y: c_int) -> c_int { unsafe { isalpha(x, y) } }
> }
>
> fn main() {
> dbg!(a::wrap(10));
> dbg!(b::wrap(10, 20));
> }
> ```
>
> I expected to see this happen: code should be rejected as obviously wrong, since within the same codegen unit, it is using two incompatible declarations for the same external foreign function.
>
> ...
>
> I personally suspect that this error represents enough of a red flag that we really should be aiming to turn the existing lint into a hard-error, even if only over an edition boundary for the language.

*Consensus*: Given the outcome above, we'll defer discussion of this.

### Tracking Issue for deprecated_cfg_attr_crate_type_name lint - #91632

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

TC: @bjorn3 gives the context:

> The `deprecated_cfg_attr_crate_type_name` lint detects uses of the `#![cfg_attr(..., crate_type = "...")]` and `#![cfg_attr(..., crate_name = "...")]` attributes to conditionally specify the crate type and name in the source code. For example:
>
> ```rust
> #![cfg_attr(debug_assertions, crate_type = "lib")]
> ```
>
> The `#![crate_type]` and `#![crate_name]` attributes require a hack in the compiler to be able to change the used crate type and crate name after macros have been expanded. Neither attribute works in combination with Cargo as it explicitly passes `--crate-type` and `--crate-name` on the commandline. These values must match the value used in the source code to prevent an error.

TC This is already deny-by-default. The next step is to make this a hard error.

*Consensus*: Given the outcome above, we'll defer discussion of this.

### "MaybeDangling" rfcs#3336

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

TC: This was proposed for FCP merge three weeks ago. tmandry proposed this could go forward ahead of acceptance of the RFC using the process for experiments. RalfJ is certainly an "experienced Rust contributor". We would also need a liaison from this group. Any volunteers?

JT: No objection to him going forward as an experiment.

tmandry: I'll liaison it. I'll comment on the RFC.

scottmcm: It will need tracking issue anyway.

JT: We can ask RalfJ to create that.

*Consensus*: tmandry will second, and this can move forward as an experiment.

---

TC: Separately, tmandry said:

> I share a concern about the proliferation of value type wrappers, and am pretty interested in exploring attributes.

Does this merit discussion, in terms either of moving the RFC forward, or suggesting a path from this group that the experiment might explore?

scottmcm: My inclination is to accept it as-is. We'd probably want the type anyway. If there's a way to apply the type in a place that attributes don't work well, that's not a bad thing.

tmandry: There will be an attribute hiding behind it anyway that could be used for experimentation.

scottmcm: Here's what I mean about where attributes aren't a good fit.

fn foo(x: MaybeDangling<Box<Blah>>)

I don't think we'd allow

fn foo(#[maybe_dangle] x: Box<Blah>)

TC: Right, the attribute proposal isn't to allow that, but that people would use it to define types or wrapper types that would go there.

scottmcm: If it's plausible we'd want a canonical type anyway for those use cases, we might as well have it in core.

TC/tmandry: +1.

*Consensus*: We'll move forward as an experiment.

### Camel case and shouting case - rust#60570 / rust#116389

"type parameters expect camel case, but shouting case is also common" rust#60570

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

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

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

TC: These issues are two sides of the same coin. In the first, a plausible use case has been put forward for when shouting-case in type parameters may be reasonable. In the second, the author hopes to lint on upper-case words without underscores, but that would exacerbate the first issue and would additionally raise concern about some acronyms.

TC: In the 2023-11-08 meeting, we were concerned about churn and uncertain about the motivation of the latter issue. We nearly closed it, but instead decided to ask the author to address that. The answer is:

@sjwang05:

> > Can you say more about the motivation here? How essential is this?
>
> I'd say the main motivation here (as mentioned in the original issue) is just to be more compliant with [RFC430](https://rust-lang.github.io/rfcs/0430-finalizing-naming-conventions.html), though I wouldn't say it's essential, especially for 3-letter screaming words.
>
> > Personally, the note from [#116389 (comment)](https://github.com/rust-lang/rust/pull/116389#issuecomment-1761569919) about maybe moving the threshold for complaining about it seems potentially interesting as a way to have this handle the most egregious cases without being so noisy.
>
> I agree--I think raising the limit to 4 upper-case characters would be a good compromise, though I'll leave the final call on what to do up to you all.

What do we think?

JT: I think part of the distinction here is that, since we're not semantically parsing English, we have no convenient way to tell the difference between an abbreviation, an acronym, an upper case word, etc. So it seems like we're enforcing style in such a way that people would see conceptually inconsistent results.

JT: Rather than making this more aggressive, we should make this less aggressive.

TC: Sounds like we should close second issue and comment on the first issue that we agree with the analysis.

JT: +1.

tmandry: I think agree with the outcome. I'm not in favor of enforcing this in `rustc`.

scottmcm: `rb"foo"` being an `RBString` and not getting linted seems entirely fine.

*Consensus*: Let's FCP close the second issue and leave a comment on the first.

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

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

TC: The change here applies to both RPIT and to TAIT, but the proposed wording for TAIT was a bit wrong. We decided in the 2023-11-08 meeting to not block the RPIT piece and proposed FCP merge (including T-types).

TC: The more general wording has now been fixed and needs review from T-lang. The question is, should this be the rule for Rust?:

> Within the body of an item that defines the hidden type of some opaque type, exhaustiveness checking on a value of that opaque type is performed using the concrete hidden type inferred in this body.

TC: This is important for the new trait solver.

tmandry: That seems reasonable to me.

scottmcm: +1, I'm in favor of that wording.

*Consensus*: We'll leave a comment this wording is part of this FCP.

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

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

TC: The question here is whether to adopt the following rule for Rust:

> Within a single item, when multiple defining uses of an opaque type differ only by lifetime arguments, we must be able to prove that those lifetime arguments are equal, otherwise the code will be rejected, and once the new trait solver is stabilized, it will likely not be possible to lift this restriction in a fully backward compatible way.

TC: We discussed this at the 2023-11-08 design meeting on TAIT ("once modulo regions"), but it applies equally RPIT. E.g.:

> ```rust
> pub trait Trait<'x> {}
> impl<'x, T> Trait<'x> for T {}
>
> pub fn test<'a, 'b>(a: &'a (), b: &'b ()) -> impl Trait<'a> {
> // ~^ ERROR lifetime may not live long enough
> // ~| NOTE argument requires that `'b` must outlive `'a`
> if false {
> let _ = test(b, b);
> }
> a
> }
> ```

(This code is currently accepted.)

TC: This is about compatibility with the new trait solver which relies on invariants about Rust that make the above code impossible to accept.

TC: There was a crater run performed and no breakage was found.

scottmcm: Being able to separate type checking and borrow checking separately is an extremely strong motivation to me. +1.

tmandry: I am a bit worried about code that's not in crater. I'm inclined to accept this either way.

*Consensus*: Let's propose FCP merge.

### "Add warn-by-default lint against unclear fat pointer comparisons" rust#117758

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

TC: To resolve #106447 ("dyn Trait comparison should not include the vtable pointer"), we decided to add a lint. This is that lint. But there may be an open question, and scottmcm nominated with:

> Hmm, I think my personal vision of this was something like `unclear_fat_pointer_comparisons` that would lint on `*const T` for any `T: ?Sized` too, even without knowing what specific kind of DST it was. My thought was that even if you did intend to compare both (say because it's a slice and that's what you meant), it might still be good to use `ptr::eq` to help emphasize that you're not _accidentally_ comparing the length too (like say if you forgot it was a slice pointer and not an item pointer).
>
> But I'm not sure if that's what other people from the triage meeting were thinking. cc @Amanieu @rust-lang/lang @rust-lang/lang-advisors so others can chime in if they were thinking that this would check `dyn` only.
>
> (Do people frequently compare slice pointers as a way of checking the length too? I don't know that I've ever seen code doing that, vs working in https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.len + data pointer separately...)

scottmcm: Please everyone have a look at this, since we asked people to write this lint.

scottmcm: One view of this is that `dyn Trait` ptr comparisons are unreliable and should be linted against. The other is that for fat pointer comparisons you should use the lib functions. I propose the latter. The former feels like a clippy lint.

JT: There is an argument for the second one being a kind of future-incompat lint.

scottmcm: I'm in agreement with that, so I must have been unclear earlier. The version that is "you are comparing vtable pointers using ==" is distinct from "doing vtable pointer comparisons are weird so you shouldn't do it."

scottmcm: One of the specific problems is what to name the lint, and our motivation matters for that.

scottmcm: Proposal: let's call this `unclear_fat_pointer_comparison`, and then we suggest to either compare the slice, cast the pointers to thin pointers (or `addr_eq`), or use the `ptr::eq` that is documented to compare both.

<https://doc.rust-lang.org/nightly/std/ptr/fn.addr_eq.html>

JT: We could stabilize these at the same time.

JT: I'll FCP the issue for `addr_eq` (with my T-libs-api hat on).

JT: Can we just FCP this lint and have it make these recommendations?

scottmcm: I'll write up an FCP proposal.

*Consensus*: We want to do something along the lines of what scottmcm has proposed, and he'll write up a specific proposal for FCP merge.

(The meeting ended here.)

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

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

TC: To the page about [`reference`](https://doc.rust-lang.org/std/primitive.reference.html), the proposal is to add this language:

> #### Safety
>
> For all types, `T: ?Sized`, and for all `t: &T` or `t: &mut T`, unsafe code may assume that the following properties hold. Rust programmers must assume that, unless explicitly stated otherwise, any Rust code they did not author themselves may rely on these properties, and that violating them may cause that code to exhibit undefined behavior.
>
> * `t` is aligned to `align_of_val(t)`
> * `t` is dereferenceable for `size_of_val(t)` many bytes
>
> If `t` points at address `a`, being "dereferenceable" for N bytes means that the memory range `[a, a + N)` is all contained within a single allocated object.

### "TAIT decision on "may 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: However, this basically boils down to whether we want both TAIT and the new trait solver, given the direction the new trait solver has gone. If we do want both, there's probably not a realistic alternative to this rule.

TC: Here's the short version. 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? We can get different answers, so we need to know upfront.

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

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

### "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.)
>
> ```rust
> #![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 = ! ?
> }
> }
> ```

### "Document that <- 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

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

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

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

### "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: What this boils down to is whether we want to block TAIT on stabilizing the new trait solver. If we don't adopt this restriction, then T-types will not approve TAIT until the new trait solver lands.

TC: Here's the short version. 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.

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

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

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

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

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

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

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

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

TC: We discussed this extensively in the [2023-11-01 meeting](https://hackmd.io/ZTUXE9EES9eNDX1GaLpoQw). We did not come to any consensus other than that we were open to frontmatter in some form.

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

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

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

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

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

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

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

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

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

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

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

## Active FCPs

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

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

### "Stabilize C string literals" rust#117472

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

## P-critical issues

None.