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

# T-lang meeting agenda

- Meeting date: 2023-12-13

## Attendance

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

## Meeting roles

- Minutes, driver: TC

## Scheduled meetings

- 2023-12-13: "Design meeting: Match ergonomics 2024" [#241](https://github.com/rust-lang/lang-team/issues/241)
- 2023-12-20: "Design meeting: resolve ABI issues around target-feature" [#235](https://github.com/rust-lang/lang-team/issues/235)

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

### "Add support for `for await` loops" rust#118847

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

TC: Last week we confirmed that `async gen { .. }` blocks could proceed as an experiment along with `gen { .. }` blocks. This week, CE wants to confirm that asynchronous `for` loops may also proceed.

TC: The design and implementation questions here are very related, and it's possible these would end up in the same RFC. Are we OK with this experiment?

*Consensus*: We'll do this experiment, under a separate feature gate, and tmandry will liaison for this.

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

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

TC: Last week lcnr asked us to review #117003. He meant #117703.

TC: This change allows this code to work:

async fn async_fibonacci(i: u32) -> u32 {
    if i == 0 || i == 1 {
        i
    } else {
        Box::pin(async_fibonacci(i - 1)).await
          + Box::pin(async_fibonacci(i - 2)).await
    }
}

This avoids having to convert the futures into trait objects. According to lcnr:

> This has a potentially significant perf impact (allowing some inlining/tail optimization or whatever, idk haven't tested it).

In more detail, from lcnr:

> The existing code treats coroutines and their witnesses as if they were structural, similar to how we treat tuples. This means we error if the generated state machine for the coroutine references the coroutine itself. We originally did this as they actually were structural until we stabilized #101692.
>
> The new approach treats coroutines and their state machine enum as a nominal type: we allow a coroutine to contain itself at a yield point as long as it is using some indirection. Coroutines without indirection result in an error. This matches the behavior of ADTs, e.g. actual enums, which can also recursively reference themselves as long as there is some indirection.
>
> I believe this to be a _significant_ improvement without any downsides. I also believe that it can safely be stabilized and have trust in our implementation to support this

TC: Do we agree?

pnkfelix: I'll have a look.

CE: The types team is the one that has to be comfortable with the representation of this. T-lang just has to be OK with the semantics.

pnkfelix: We'd be committing to this on a T-lang side. It'd be stable instantly.

scottmcm: It is a one-way door. I'll probably check my box shortly.

*Consensus*: People will have a look and check boxes if appropriate.

---

*Post-meeting note*: This went into FCP.

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

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

TC: We asked for and then approved a lint against ambiguous wide pointer comparisons. Urgau has now observed that the same logic that led us to that lint should also counsel us to lint against comparison of function pointers.

> ## `unpredictable_function_pointer_comparisons`
> _warn-by-default_
>
> The `unpredictable_function_pointer_comparisons` lint checks comparison of function pointer as the operands.
>
> ### Example
> ```rust
> fn foo() {}
> let a = foo as fn();
>
> let _ = a == foo;
> ```
>
> ### Explanation
>
> Function pointers comparisons do not produce meaningful result since they are never guaranteed to be unique and could vary between different code generation units. Furthermore different function could have the same address after being merged together.

TC: What do we think?

waffle: What would be the fix?

CE: The `addr_eq!` solution doesn't apply here. So this is a different issue than the wide pointer comparison issue. It would need a different solution.

waffle: Maybe the fix is just to allow the lint.

CE: You'd risk false negatives. If you need it for correctness, you can't do it.

pnkfelix: What if you have a function pointer in a structure? You wouldn't get a warning?

CE: Correct.

TC: Great point.

CE: Maybe it'd be a better as a clippy lint.

CE: You could hide it behind a generic function or a struct that derives `Eq`.

Waffle: Maybe we should warn on deriving `Eq` on structs that contain these data (wide pointers, function pointers). You can have generics and not be able to detect the potential problem.

pnkfelix: There's an intent that people have, e.g. caching. We don't know what that is when we're linting.

pnkfelix: That said, I'm OK with the lint.

tmandry: I'm not sure what the use cases are for doing this comparison.

TC: Maybe we should ask on the issue what the use cases are for these comparisons.

CE: We could make this deny and run crater.

tmandry: A crater run could be useful in gathering use cases.

pnkfelix: The reason we added the lint on wide pointers was that people wanted to change the semantics because people were hitting that problem. I'm not aware of cases of misuse here. Maybe that argues in favor of doing more analysis.

CE: I'm curious to see in a crater run cases where people are misusing this with respect to monomorphization.

scottmcm: For the wide pointer case, we pointed people toward a solution that better expressed the intention. But we're not later then going to lint against `ptr::addr_eq!` even though that has the same problems. This lint seems like doing the latter.

pnkfelix: Would it tilt you at all if we found bugs in doing the crater run and analysis?

scottmcm: If we found there were no use cases, that could maybe influence my thinking.

tmandry: Why I lean toward this is that the semantics you'd expect of the language here do not hold.

scottmcm: Two function pointers that compare unequal but do the same thing is a fundamental property of functions. So maybe the false negative is OK.

scottmcm: Maybe the lint could be impossibly smart and determine whether the user was using this in the memoization case, where it would be OK, versus ones where it would not.

pnkfelix: You could use fuzzing to maybe find things like this, but that's not a static lint.

*Consensus*: Let's ask for analysis of use cases and perhaps a crater run to find them.

### "Tracking issue for exclusive range patterns" rust#37854

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

TC: The proposal, from Nadrieril, is to stabilize `a..b` and `..b` in pattern position to join the already-stable `a..=b`, `a..`, and `..=b`. In detail:

> # Stabilization Report
>
> ## Summary of changes
>
> This would stabilize the use of `a..b` and `..b` in pattern position. These are currently gated under `exclusive_range_patterns`, tracked in this here issue.
>
> `a..=b`, `a..` and `..=b` have been stable as patterns for a while (except `a..` in slices). `a..=b`, `a..b`, `a..`, `..b`, `..=b` have been stable as expressions for a while. ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=56ec2e5063315ceffc406485c59ab18b))
>
> `a..` patterns in slices are currently gated under [`half_open_range_patterns_in_slices`](https://github.com/rust-lang/rust/issues/67264) and are not touched by this proposal.
>
> ## Motivation for stabilization
> This is a much-requested feature. It would also make the language more consistent given that these ranges are possible as expressions.
>
> The main blocker was the possibility for confusion, mostly insofar as the two kinds of range (`a..b` and `a..=b`) may be mistaken for one another.
>
> I argue that this is acceptable for two reasons: for one we already have this problem with range expressions; for two we mitigate confusion in matches as follows:
>
> * Exhaustiveness checking detects gaps left uncovered between ranges (even with `usize`/`isize` now) ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=147fec90689397ba476bd111385e96bf)):
> ```rust
> match 0u32 { // ERROR: `10_u32`, `100_u32` and `1000_u32` not covered
> 0..10 => 1,
> 11..100 => 2,
> 101..1000 => 3,
> 1001.. => todo!()
> }
> ```
> * The `overlapping_range_endpoints` lint detects the opposite error ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=888414d733ee6ce5fd47fdffe8b75171)):
> ```rust
> match 0u32 {
> 0..=10 => 1, // WARN: this range overlaps on `10_u32`...
> 10..=100 => 2, // ... with this range
> 100..=1000 => 3,
> 1000.. => todo!()
> }
> ```

TC: There's now also a proposed extension of the lint to catch small gaps between range endpoints, e.g.:

match x {
    0..10 => ..., // WARN: this range has a small gap on `10_u8`...
    11..20 => ..., // ... with this range.
    _ => ...,
}
// note: you likely meant to match `10_u8` too

TC: What do we think?

scottmcm: Especially with lints this sounds great. We talked before about whether these were so confusing these should be blocked at the language level. But then we decided that the other ones weren't any more confusing than the ranges in general. So this seems OK also.

scottmcm: With unsigned/signed types, a `..b` pattern is not really different in terms of misuse danger than less than.

tmandry: Do people use this?

CE: People use range constructors quite a lot.

scottmcm: As expressions for slice indexing, these have been stable basically forever.

tmandry: I'm comfortable moving forward.

scottmcm: I'll FCP merge.

pnkfelix: +1.

*Consensus*: Let's do this.

### "More expressions correctly are marked to end with curly braces" rust#118880

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

TC: It seems that the parsing for `let-else` may not be precise enough. E.g.:

#![feature(inline_const)]

fn main() {
    let false = const {
        true
    } else {
        return;
    };
}

TC: That's not stable, but other instances of this are, and dtolnay has raised those for our comment:

> > The only behavior changes in the PR are to `const {}`, `do yeet`, and `become`, all of which are properly feature gated in the parser even inside of #[cfg(any())] code.
>
> But I would like @rust-lang/lang to comment on other cases ending in brace, not touched in this PR, which are stable.
>
> ```rust
> // ExprKind::FormatArgs
> let _ = format_args! {
> "..."
> } else {
> return;
> };
> ```
>
> ```rust
> // ExprKind::MacCall
> let Ok(_) = writeln! {
> io::sink(),
> "...",
> } else {
> return;
> };
> ```
>
> ```rust
> // ExprKind::IncludedBytes
> let b"..." = include_bytes! {
> concat!(env!("OUT_DIR"), "/the_bytes")
> } else {
> return;
> };
> ```
>
> ```rust
> // ExprKind::InlineAsm
> let 0isize = asm! {
> ...
> } else {
> return;
> };
> ```
>
> and finally, unstable `offset_of`.

TC: How do we feel about that?

CE: All expressions where we disallow trailing braces because they'e ambiguous in the parser are hit by this.

waffle: For `if`s and macros it's not actually ambiguous. The `!` tells you that it's a macro, so you know.

CE: You could make the same argument about `const`.

tmandry: What's the question here?

CE: We might ask dtolnay that. This isn't actually ambiguous.

waffle: I'm not sure we need to change anything here.

scottmcm: If we pull up the new tests, that's helpful for understanding the goal here.

scottmcm: The code there makes me sad, but it doesn't necessarily tell me that it needs to be a parser error.

CE: I'm not actually sure what these `let-else` rules are for. Right now you need to parenthesize `unsafe` blocks, but I'm not sure why.

waffle: You can't write a unit pattern that doesn't match unit.

scottmcm: Right, since no-one ever wants that, it's not a problem.

CE: Maybe we want to go the other direction and relax these rules and make it more consistent.

scottmcm: Maybe there should be a clippy lint.

scottmcm: One reason we wouldn't want to relax these rules is if we ever wanted to support `for... else`. But maybe we've ruled that out with `label-break-value`.

Today we emit:

error: `for...else` loops are not supported
 --> src/lib.rs:4:7
  |
2 |       let foo = for i in 1..2 {
  |                 --- `else` is attached to this loop
3 |           break;
4 |       } else {
  |  _______^
5 | |         //~^ ERROR `for...else` loops are not supported
6 | |         return;
7 | |     };
  | |_____^
  |
  = note: consider moving this `else` clause to a separate `if` statement and use a `bool` variable to control if it should run

scottmcm: That's kind of a nice error. I'd assume people could make it work in some other way.

waffle: Even if we decided we don't want to support things like `for..else`, it may still make sense to reserve the space so we can give errors for people who might think it exists.

*Consensus*: We'll comment on why it's not ambiguous and ask dtolnay what he wants here.

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

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

On 2023-12-12, tmandry raised a concern:

> > 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).
>
> It isn't clear to me _why_ the token removal was backed out; the crater run above [rust-lang/rust#60803 (comment)](https://github.com/rust-lang/rust/pull/60803#issuecomment-494661527) didn't find any actual regressions and the comment didn't leave a rationale.
>
> It seems like it would have been possible to remove the token then, but now it might be harder. It seems worth running crater again to check, if only to make `x<-1` parse correctly. Though if someone knows of crates that will definitely break or wants to argue for why it's a bad idea, we can skip it and I'll resolve the concern.
>
> @rfcbot concern can we still remove the token
>
> Otherwise, I'm not opposed to documenting the current behavior.

ehuss answered:

> It sounds like from [rust-lang/rust#60803](https://github.com/rust-lang/rust/pull/60803) that Centril and petrochenkov wanted to keep the `<-` token for "future-proofing" and "keeping options open". Does the lang team want to close that door?
>
> Perhaps it could be removed, and then added again later in an edition (though I don't know how feasible that is)?

TC: What do we think?

scottmcm: Given that on stable it is a token, we should write that in the reference. But I'm not opposed to fixing that and making it not a token.

CE: We can easily determine with a crater run what the breakage would be.

waffle: Even though a lot of macros use the symbol, most will not break because they don't care whether or not they're separate.

scottmcm: If you're matching within a `tt` filter then it would care.

waffle: I'm not sure why these would need to be split.

TC: How unusual is this among our tokens?

waffle: The forward arrows are a single token.

tmandry: My argument for removing it is that people could write `x<-1` and it parses. But I don't feel strongly.

CE: We should do a crater run and remove it if it comes back clean.

scottmcm: Both `->` and `=>` are single-`tt` today, it appears:

macro_rules! foo {
    ($x:tt) => {};
}

fn main() {
    foo!(->);
    foo!(=>);
    foo!(<-);
    foo!(<=);
}

scottmcm: So now I'm feeling like leaving this as-is is fine.

waffle: +1.

tmandry: My feeling is weak on this.

CE: I'm not convinced by the symmetry. This was only added for the placement syntax.

waffle: But of course it is observable by macros.

TC: What is the status of the placement work?

scottmcm: Probably no-one has a design that's close enough to working for us to move forward on it. It's something we want if that were solved.

scottmcm: The work to keep this in the compiler is extremely small. How much normal code is being impacted by this? It is a breaking change to remove it.

tmandry: If there is some chance of us wanting this for placement new in the next few years, then maybe we should just leave it.

CE: We're all on the same page that it should either be documented or removed.

CE: I'll kick off a crater run. We could document it in the reference and then separately remove it.

TC: The proposal is to accept this in the documentation and later and separately consider removing it.

all: +1.

tmandry: I'll remove my concern.

*Consensus*: Let's document this as-in, and we'll later and separately decide whether to remove this.

(The meeting ended here.)

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

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

TC: fmease wants us to remove the deprecation from the `unstable_features` lint to better support rust-analyzer working on stable Rust while depending on parts of the compiler. In detail:

> 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 [#117937 (comment)](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).

TC: It's worth noting that there's also been recent discussion on Zulip about whether rust-analyzer should consider moving to nightly Rust. It will, e.g., presumably want to use the new trait solver eventually.

https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/use.20nightly.20in.20rust-analyzer

TC: What do we think?

### "Delay literal unescaping" rust#118699

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

TC: nnethercote wants to make some string and character literals that today are parsing errors into semantic errors. This would allow macros to assign meaning to these literals, but that might also limit our flexibility to assign new meaning at the language level later. nnethercote:

> It changes some errors related to literals from syntactic to semantic. In the compiler, this is all the errors in the `EscapeError` type. These all relate to char/byte/string literals, and mostly relate to escape sequences, plus a couple of others (e.g. having more or less than one char/byte in a char/byte string literal, or having a NUL char in a C string literal.)
>
> Here is example code showing how things change. This covers some of the relevant errors, but not all; the missing ones would be affected in the same way.
>
> ```rust
> fn main() {
> ''; //~ error: empty character literal
> b'ab'; //~ error: character literal may only contain one codepoint
> "\a"; //~ error: unknown character escape: `a`
> b"\xzz"; //~ error: invalid character in numeric character escape
> "\u20"; //~ error: incorrect unicode escape sequence
> c"\u{999999}"; //~ error: invalid unicode character escape
> }
>
> sink! {
> ''; // was an error, now allowed
> b'ab'; // was an error, now allowed
> "\a"; // was an error, now allowed
> b"\xzz"; // was an error, now allowed
> "\u20"; // was an error, now allowed
> c"\u{999999}"; // was an error, now allowed
> };
>
> #[cfg(FALSE)]
> fn configured_out() {
> ''; // was an error, now allowed
> b'ab'; // was an error, now allowed
> "\a"; // was an error, now allowed
> b"\xzz"; // was an error, now allowed
> "\u20"; // was an error, now allowed
> c"\u{999999}"; // was an error, now allowed
> }
> ```
>
> This means a macro can assign meaning to arbitrary escape sequences, such as `foo!("\a\b\c")`.
>
> This change is consistent with a general trend of delayed literal checking:
>
> * Floating point literals have had this delayed checking behaviour for a long time (forever?)
> * [This PR](https://github.com/rust-lang/rust/pull/102944#issuecomment-1277476773) did a similar thing for numeric literals.
> * The NUL char checking for C string literals is implemented in this semantic (delayed) fashion.

There's been substantial follow-on discussion between scottmcm and nnethercote in the issue that is worth reading.

TC: What do we think?

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

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

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

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

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

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

### "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: We have this scheduled for a design meeting on 2023-12-20.

### "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: We're discussing this in a design meeting today.

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

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

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

### "Stabilize single-field offset_of" rust#118799

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

## 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 text for the CFG OS Version RFC" rfcs#3379

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

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

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

### "Stabilize THIR unsafeck" rust#117673

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

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

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

## P-critical issues

None.