---
title: "Triage meeting 2024-02-14"
tags: ["T-lang", "triage-meeting", "minutes"]
date: 2024-02-14
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings
url: https://hackmd.io/o4aq3mkoT0GfvjEAmXszxQ
---

# T-lang meeting agenda

- Meeting date: 2024-02-14

## Attendance

- People: TC, nikomatsakis, Santiago, tmandry, Josh, Lukas Wirth, Aidan, scottmcm, Xiangfei Ding

## Meeting roles

- Minutes, driver: TC

## Scheduled meetings

- 2024-02-14: "Discuss temporary lifetimes 2024 RFC" [#253](https://github.com/rust-lang/lang-team/issues/253)
- 2024-02-21: "Discuss feedback for T-spec sample chapters" [#250](https://github.com/rust-lang/lang-team/issues/250)
- 2024-02-28: "Discuss arbitrary self types v2 RFC" [#254](https://github.com/rust-lang/lang-team/issues/254)

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

### Rust/C++ interop initiative

TC: Apparently Google gave the Rust Foundation $1M to do work on improving Rust interoperability with C++.

In the #council discussion, our rep requested that this be raised to the awareness of the lang team. This is that awareness.

There's discussion of setting up a new working group (and there's some opposition to that). This also seems like a good case for the "project goals" that Niko proposed.

Blog post:

https://foundation.rust-lang.org/news/google-contributes-1m-to-rust-foundation-to-support-c-rust-interop-initiative/

Discussion in #council:

https://rust-lang.zulipchat.com/#narrow/stream/392734-council/topic/Creating.20a.20WG.20or.20project.20group.20for.20Interop.20Initiative

Discussion in #foundation:

https://rust-lang.zulipchat.com/#narrow/stream/335408-foundation/topic/Rust.2FC.2B.2B.20interop.20initiative

NM: I've been working on a document that outlines two things that I want to start socializing. It's a combination of vision docs and also team goals, i.e. milestones. It may be a perfect fit for this project. I'm excited about Google's investment and think that C++ interop will be great for Rust.

Meta vision doc working draft: https://hackmd.io/msPDdmfRRyOGHvwytKdbwA

NM: Who are the right people to talk with?

JT: Probably Lars.

TC: And Joel Marcey.

JT: I also had plans for a Rust/C++ interop working group. So I'm happy to help here.

NM: The words WG give me a nervous feeling these days. I'm starting to prefer one or two people owning some project but with a public space to talk and get input. I want clear ownership here and in general.

tmandry: I've been in touch with Lars about this and have offered to be a liaison. I'm enthusiastic about this. I'd like to see us channel this investment in a worthwhile way for the project.

NM: Sounds perfect, tmandry, if you can be the liaison.

## Rust 2024 review

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

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

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

TC: We accepted the RFC but it has a dependency on some means of expressing precise capturing. That probably means stabilizing TAIT. We're starting with stabilizing ATPIT, and we've now posted the stabilization report and PR for that which is now in proposed FCP.

NM: Please josh/felix/scottmcm get on your checkboxes [#120700](https://github.com/rust-lang/rust/pull/120700). Given the work and push forward on this, I don't want us to be blocking it.

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

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

TC: Oli is back, and we're all working on this. The minimum we need to do for 2024 is to reserve the keyword.

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

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

TC: The never type is still living up to its name. There's been a long discussion on Zulip. This is what we had been hoping to lint against:

fn never_type_fallback() { unsafe {
    if false { panic!() } else { transmute::<_, _ /* ?0 */>(()) }
    // later in fallback:     ?0 := ()
    // after ! stabilization: ?0 := !
}}

TC: My read of the situation is that this would be a good topic for a design document and a design meeting.

NM: Who's driving this, Waffle?

TC: Waffle and "Nadri", Mark-Simulacrum.

## Nominated RFCs, PRs, and issues

### "Tracking Issue for cfg-target-abi" rust#80970

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

TC: Chris Denton proposes to stabilize `#[cfg(target_abi = "..")]`:

> I propose to stabilize `#[cfg(target_abi = "...")]`, This implements [RFC-2992](https://rust-lang.github.io/rfcs/2992-cfg-target-abi.html) (cfg-target-abi). The implementation was completed in #86922 and this tracking issue was subsequently marked as ready for stabilization by @joshtriplett.
>
> ### Summary
>
> This stabilizes the `cfg` option called `target_abi`:
>
> ```rust
> #[cfg(target_abi = "macabi")]
> ```
>
> And `target_abi` is also shown when using `--print=cfg` (output snipped for length):
>
> ```
> > rustc --print=cfg --target aarch64-apple-ios-sim
>
> target_abi="sim"
> target_arch="aarch64"
> target_env=""
> target_os="ios"
> target_vendor="apple"
> ```
>
> Without `target_abi`, cfgs are limited to `target_arch`, `target_vendor`, `target_os`, and `target_env`. However, some targets are only differentiated by their abi and thus it's necessary to resort to parsing the full target string in a build script when there's a need to disambiguate. For example, the following targets are the same if only using stable `target_*` `cfg`s:
>
> * `aarch64-apple-ios` and `aarch64-apple-ios-sim` (arch: "aarch64", vendor: "apple", os: "ios", env: "")
> * `x86_64-pc-windows-gnullvm` and `x86_64-pc-windows-gnu` (arch: "`x86_64", vendor: "pc", os: "windows", env: "gnu")
>
> ### Notes
>
> The `target_abi` defaults to `""` (the empty string) and most targets don't set it. This is similar to `target_env` where if it's not needed for disambiguation then it's often not set.
>
> In the future `target_abi` could be an array of zero or more properties that affect the ABI (e.g. `softfloat` may be combined with other ABI properties), However, this feature can be added later without breaking compatibility.

TC: Given the recent discussions over ABI issues, I made sure RalfJ was aware of this, and he had no particular concerns.

TC: Josh has proposed FCP merge. What do we think?

NM/pnkfelix: I've checked my box.

TC: This is going into FCP.

*Consensus*: Let's do this.

### "Stabilize the `#[diagnostic]` namespace and `#[diagnostic::on_unimplemented]` attribute" rust#119888

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

TC: weiznich proposes `#[diagnostic::on_unimplemented]` for stabilization:

> This PR stabilizes the `#[diagnostic]` attribute namespace and a minimal option of the `#[diagnostic::on_unimplemented]` attribute.
>
> The `#[diagnostic]` attribute namespace is meant to provide a home for attributes that allow users to influence error messages emitted by the compiler. The compiler is not guaranteed to use any of this hints, however it should accept any (non-)existing attribute in this namespace and potentially emit lint-warnings for unused attributes and options. This is meant to allow discarding certain attributes/options in the future to allow fundamental changes to the compiler without the need to keep then non-meaningful options working.
>
> The `#[diagnostic::on_unimplemented]` attribute is allowed to appear on a trait definition. This allows crate authors to hint the compiler to emit a specific error message if a certain trait is not implemented. For the `#[diagnostic::on_unimplemented]` attribute the following options are implemented:
>
> * `message` which provides the text for the top level error message
> * `label` which provides the text for the label shown inline in the broken code in the error message
> * `note` which provides additional notes.
>
> The `note` option can appear several times, which results in several note messages being emitted. If any of the other options appears several times the first occurrence of the relevant option specifies the actually used value. Any other occurrence generates an lint warning. For any other non-existing option a lint-warning is generated.
>
> All three options accept a text as argument. This text is allowed to contain format parameters referring to generic argument or `Self` by name via the `{Self}` or `{NameOfGenericArgument}` syntax. For any non-existing argument a lint warning is generated.
>
> This allows to have a trait definition like:
>

#[diagnostic::on_unimplemented(
    message = "My Message for `ImportantTrait<{A}>` implemented for `{Self}`",
    label = "My Label",
    note = "Note 1",
    note = "Note 2"
)]
trait ImportantTrait<A> {}

>
> which then generates for the following code
>

fn use_my_trait(_: impl ImportantTrait<i32>) {}

fn main() {
    use_my_trait(String::new());
}

>
> this error message:
>

error[E0277]: My Message for `ImportantTrait<i32>` implemented for `String`
  --> src/main.rs:14:18
   |
14 |     use_my_trait(String::new());
   |     ------------ ^^^^^^^^^^^^^ My Label
   |     |
   |     required by a bound introduced by this call
   |
   = help: the trait `ImportantTrait<i32>` is not implemented for `String`
   = note: Note 1
   = note: Note 2

>
> [Playground with the unstable feature](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7ffa5c88627251ab242fadadd3b6f65f)

TC: What do we think?

JT: The `on_unimplemented` part is probably uncontroversial. We should look closely at the semantics of the diagnostic namespace in general. Specifically the idea that you only get warnings when attributes are not recognized or have other errors, which makes it easier for you to add these without impact MSRV.

NM: Presumably this is less dangerous than other attributes. The diagnostic attributes never affect program semantics or whether an error occurs, only the contents of the message when it does.

scottmcm: There was a complicated question about oversight of this namespace and I'm not sure where we landed on that.

tmandry: We decided that we did want to FCP new additions to the diagnostic namespace. The compiler team did ask about that. This would be the first addition to the diagnostic namespace. In any case, I'm in favor.

JT: Part of the rationale for ignoring and just warning about things we don't understand is because these do not have to have a flawless stability guarantee. We can delete these. We can similarly alter them. But I agree that we should FCP additions.

tmandry: Some of the hesitance of the authors in involving the lang team was the long turnaround time. So we should try to get to these.

NM: +1. The are two other teams tagged. How should we FCP this?

TC: Let's T-lang FCP this.

NM: Agreed, this feels the same as any other language feature.

JT: +1.

scottmcm: Are we happy with the names in this proposal? There is some precedence on these names.

NM: I'm fine with the names and not inclined to second guess the authors "as a team". We could individually leave feedback.

JT: +1.

tmandry: Should we be fully replacing the compiler's message? We can work this out over time.

NM: +1 to feedback. Fine-tuning the dev-ex feels more like a compiler team issue, I expect we'll evolve the way we present them over time.

scottmcm: The description allows putting `note` twice. Are multiple names normal?

JT: Haven't seen it before, but it doesn't seem unreasonable.

tmandry: If you were writing an attribute proc macro, you could already do this.

pnkkfelix: It's in the tests.

tmandry: Here's a comment I left on the RFC about the lang team adopting an expedited process for approving these:

https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1505729088

By default, we'll just FCP everything.

NM: I'll start the FCP.

scottmcm: And the expectation is they can change this diagnostic in the future if needed.

NM: That would be my expectation. We should make that clear though. The experts will be the people refining the diagnostics.

JT: We'll get a better idea as we see more of these.

*Consensus*: Let's do this.

### "Implement RFC 3373: Avoid non-local definitions in functions" rust#120393

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

TC: We agreed to accept RFC 3373 (regarding "sneaky inner impls") after changing it to make it a warn-by-default lint. That lint has now been implemented, and a crater run has been performed. This is the analysis:

> Affected projects: 7057 / 851203 (0.82%) Total errors: 116165
>
> Errors from derive macros: 107531 (across 259 different derive macros) Errors from `macro_rules!`: 2150 (across 117 different `macro_rules!`) Errors (manual, not above): 6484
>
> In conclusion, this crater run revealed that making the lint deny-by-default (which is NOT the default that would would be used, it would be warn-by-default) could break 7057 crates / 851203 crates tested (0.82%), there was a total of 116165 errors, of which 107531 (92.6%) errors were coming from derive macros, 2150 were coming from `macro_rules!` and 6484 errors are not coming from either of them.
>
> Analysing the root of those derives and macros revealed many outdated versions of `serde_derive` and `diesel_derives`, representing nearly 74% of the total errors alone, as well ~6~ 4 different derive crates that represent 11.4% that would need to be updated.
>
> To put it simply:
>
> * 91711 (82.8%) errors would be fixed by `cargo update` (representing 6104 different crates)
> * 5472 (4.9%) errors that could fixed by upstream change (at least ~6~ 4 different derive crates)
> * 6484 (5.9%) errors requires manual intervention (788 different crates)
> * 7309 (6.6%) uncategorised errors (probably manual intervention and deps change):
>
> I think those are more than acceptable numbers, in more that 4/5 of cases a `cargo update` would fix the warnings and by fixing ~6~ 4 different derives we could get closer to 90%, the rest of cases would need manual interventions, but some interventions are to be expected.

TC: What do we think?

scottmcm: I'd like to see a case analysis here. What kinds of things are being matched?

TC: I asked Urgau about that. It's largely people having used non-anonymous constants for the hygiene pattern. People have been moving to anonymous consts for that, and that's why updating dependencies solves so many cases.

JT: It's worth pointing out that people do deny warnings, so this can break builds.

NM: Are these impls being added to public types or to things internal the function?

JT: We lint against impls for non-local types + traits.

pnkfelix: Does the lint suggest that people should `cargo update`? Should we do that?

JT: That seems a good idea. For the specific case of linting on a named constant. Perhaps we should suggest that people switch to an anonymous constant.

TC: +1. That's a good idea.

tmandry: It should be possible to match the span of the crate and make a suggestion accordingly.

Josh: I'll write up these suggestions.

*Consensus*: Let's do this.

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

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

TC: We're proposing to stabilize ATPIT. This is edition relevant because it's a step toward making possible the Lifetime Capture Rules 2024.

use core::future::{Future, IntoFuture};

struct AlwaysAsync42;
impl IntoFuture for AlwaysAsync42 {
    type Output = impl Iterator<Item = impl Fn() -> u8>;
    type IntoFuture = impl Future<Output = Self::Output>;
    fn into_future(self) -> Self::IntoFuture { async {
        core::iter::repeat(|| 42)
    }}
}

The design principles it follows are:

- Convenience and minimal overhead for the common cases
- Local reasoning
- Crisp behavior

We proposed FCP merge on 2024-02-07. Please let me know if you have any questions.

scottmcm: Jack suggests that this FCP should include T-types.

NM: +1, I'll adjust it.

*Consensus*: We'll include T-types.

### RTN document

JT: We previously discussed having a document for RTN concerns. I've written that document:

https://hackmd.io/nbMtmAA2SsS5EbP3Omhwsg

JT: When should we discuss?

NM: Friday 1p EST / 10am PST?

JT: +1.

*Consensus*: Let's meet and discuss.

### "privacy: Stabilize lint `unnameable_types`" rust#120144

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

TC: petrochenkov nominates this for us and describes the change:

> This is the last piece of ["RFC #2145: Type privacy and private-in-public lints"](https://github.com/rust-lang/rust/issues/48054).
>
> Having unstable lints is not very useful because you cannot even dogfood them in the compiler/stdlib in this case (#113284). The worst thing that may happen when a lint is removed are some `removed_lints` warnings, but I haven't heard anyone suggesting removing this specific lint.
>
> This lint is allow-by-default and is supposed to be enabled explicitly. Some false positives are expected, because sometimes unnameable types are a legitimate pattern. This lint also have some unnecessary false positives, that can be fixed - see #120146 and #120149.

TC: What do we think?

NM: We should probably do it. We originally had strict rules and hard errors. These were annoying and not as good as they could be. We decided to move away from that and toward a different system that gives errors at the use rather than definition site which is more convenient here.

scottmcm: This appears to be things marked `pub` inside a module that's not `pub`.

NM: So it catches using `pub` rather than `pub(crate)`. It's allow-by-default.

JT: Did we discuss that, and was I there?

NM: Yes, and yes. But there were a lot of pieces.

scottmcm: I interpret this lint as "have you considered making this `pub(crate)`". But I agree you could do this intentionally.

NM: Agreed I've done this intentionally. But this is allow-by-default. We should note that before moving to warn-by-default we would want to see a further write-up.

JT: Given the idea that we don't necessarily want to do this by default, if we had the lint fire at the point you're doing the restriction, then that would be the obvious place to do the allow.

tmandry: What happened to the `crate` visibility modifier?

JT: There was a parser ambiguity on tuple field types. E.g.

Tuple(crate ::T)

That could be the type `crate::T`, or the type `::T` with `crate` visibility.

That stopped progress.

NM: +1 to the suggestion to lint on the private module with the private things rather than blaming the public things.

scottmcm: If you do allow the lint at the module level, it will allow everything under it. I'd be happy to accept this as allow-by-default. Let's let people try it and file feedback about how it should be improved before being warn-by-default.

tmandry: The ambiguity seems to come from the fact that we allow whitespace in the middle of paths.

NM: I like scottmcm's proposal. One could have a mix of items. So maybe it would be too coarse to do this at the module.

JT: Another scenario here is generated code.

SM: I'll propose FCP merge.

*Consensus*: Let's do it.

### "make non-PartialEq-typed consts as patterns a hard error" rust#120805

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

TC: RalfJ nominates this for us:

> This is the next step for the const pattern RFC. It makes constants of non-`PartialEq` type in patterns a hard error. It is actually quite hard to construct examples that need this due to all the other checks that are applied to constant in patterns -- see the tests that this PR changes: it boils down to `derive(PartialEq)` adding unnecessary bounds to the `PartialEq` impl so the imp can fail to apply even when the value is recursively structurally-match. This has been shown in future-breakage reports since Rust 1.74. Crater found no regressions.

TC: Are we ready to do this?

tmandry: +1, let's do it. I'll propose FCP merge.

*Consensus*: Let's do this.

### "Consider linting against 00B7 aka interpunct aka middle dot" rust#120797

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

TC: The question, nominated by pnkfelix, is what to do about this:

#![allow(dead_code)]
#![deny(uncommon_codepoints)]
const COL·LECCIÓ: () = ();// This is Catalan

// The below is not allowed by the lexer today...
// const ·START: () = ();

// ... but this is allowed today ...
const MID·DLE: () = ();

// ... and this is also allowed today
const END·: () = ();


fn main() {
println!("{}", r#"
COL·LECCIÓ
·START
MID·DLE
END·
"#)
}

TC: pnkfelix gives these options:

> 1. Leave things as they are (00B7 is hard-rejected as an initial character, and silently accepted in all other contexts)
> 2. Adopt something like what was proposed in PR [`uncommon_codepoints`: lint against 00B7 MIDDLE DOT in final position #120695](https://github.com/rust-lang/rust/pull/120695): continue hard-rejecting 00B7 as an initial character; lint against its occurrence as a final character, and silently accept it as a "medial" character
> 3. Something more aggressive than PR [`uncommon_codepoints`: lint against 00B7 MIDDLE DOT in final position #120695](https://github.com/rust-lang/rust/pull/120695), like linting against 00B7 in all contexts (except perhaps when it occurs in between two L's, to accommodate Catalan, as suggested by Manish [here](https://github.com/rust-lang/rust/pull/120695#issuecomment-1932984685))
> 4. Other options? (We probably don't get any benefit from deviating far from Unicode committee recommendations, so we probably do not want to start _accepting_ 00B7 as an initial character)

TC: What's the difference between this and a symbol such as underscore, that we would allow in every location, conceptually?

JT: There's a weird Catalan rendering and some special expectations about this symbol and its use between two Ls.

JT: I don't want us to adopt language-specific rules, though.

pnkfelix: On the one hand, I want to forbid this everywhere, but on the other, that seems to unfairly bias against this language.

TC: We can table this for next week.

*Consensus*: Let's table this.

(The meeting ended here.)

---

### "Tracking issue for function attribute `#[no_coverage]`" rust#84605

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

TC: This is about stabilizing a `#[coverage(off)]` attribute to exclude items from `-Z instrument-coverage`.

Josh proposed FCP merge and nominated this for us.

There are two open questions about applying this automatically to nested functions and to inlined functions.

TC: What do we think?

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

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

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

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

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

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

TC: Are we interested in fixing it over this one?

### "Stabilize `#[unix_sigpipe = "sig_dfl"]` on `fn main()`" rust#120832

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

TC: This is related to the above, and is a proposal to stabilize an option to have the startup code set `SIGPIPE` to the *other* handler. However, this does not address the problem that the Rust startup code is making this syscall at all, which means that e.g. `seccomp` filters must be correctly adjusted and it's still impossible to recover the original inherited setting of this handler.

There are also the following options to this attribute that are not proposed for stabilization here:

- `sig_ign`: This is the current default behavior.
- `inherent`: This would prevent the startup code from making this syscall at all.

TC: What do we think?

### "Let's `#[expect]` some lints: Stabilize `lint_reasons` (RFC 2383) " rust#120924

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

TC: Since the last time this was proposed for stabilization, various unresolved questions have now been resolved, so this is being proposed again.

> Hey everyone, with the `#[expect]` implementation done, I'd like to propose stabilizing this feature. I've crated two stabilization PRs, one updating the documentation and one removing the feature from rustc:
>
> * [Let's `#[expect]` some lints: Stabilize `lint_reasons` (RFC 2383)  #120924](https://github.com/rust-lang/rust/pull/120924)
> * [Document new `#[expect]` attribute and `reasons` parameter (RFC 2383) reference#1237](https://github.com/rust-lang/reference/pull/1237)
>
> The RFC 2383 adds a `reason` parameter to lint attributes and a new `#[expect()]` attribute to expect lint emissions.
>
> * Here is an example how the reason can be added and how it'll be displayed as
> part of the emitted lint message:
>

#![feature(lint_reasons)]
fn main() {
    #[deny(unused_variables, reason = "unused variables, should be removed")]
    let unused = "How much wood would a woodchuck chuck?";
}
error: unused variable: `unused`
 --> src/main.rs:5:9
  |
5 |     let unused = "How much wood would a woodchuck chuck?";
  |         ^^^^^^ help: if this is intentional, prefix it with an underscore: `_unused`
  |
  = note: unused variables, should be removed
note: the lint level is defined here
 --> src/main.rs:4:12
  |
4 |     #[deny(unused_variables, reason = "unused variables, should be removed")]
  |            ^^^^^^^^^^^^^^^^

>
> * Here is an example, that fulfills the expectation and compiles successfully:
>

#![feature(lint_reasons)]
fn main() {
    #[expect(unused_variables, reason = "WIP, I'll use this value later")]
    let message = "How much wood would a woodchuck chuck?";

    #[expect(unused_variables, reason = "is this unused?")]
    let answer = "about 700 pounds";
    println!("A: {answer}")
}
warning: this lint expectation is unfulfilled
 --> src/main.rs:4:14
  |
6 |     #[expect(unused_variables, reason = "is this unused?")]
  |              ^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unfulfilled_lint_expectations)]` on by default
  = note: is this unused?

> ## Changes from the RFC
>
> As part of my implementation, I renamed the `#[expect]` lint from `expectation_missing` to `unfulfilled_lint_expectations`. I think the name works better with other lint attributes and is more descriptive.
>
> ## Resolutions of unresolved questions
>
> 1. Where should the `reason` parameter be allowed?
>
> * The current implementation only allows it as the last parameter in all lint attributes
> 2. How should `#[expect(unfulfilled_lint_expectations)]` be handled?
>
> * In the RFC, it was suggested that the `unfulfilled_lint_expectations` can be expected by outer attributes. However, it was also questioned how useful this would actually be. The current implementation doesn't allow users to expect this lint. For `#[expect(unfulfilled_lint_expectations)]` the lint will be emitted as usual, with a note saying that `unfulfilled_lint_expectations` can't be expected.
>
> 3. How should `#[expect(XYZ)]` and `--force-warn XYZ` work?
>
> * This implementation, will emit the lint XYZ, as the lint level has been defined by `--force-warn` and also track the expectation as it usually would with only the `#[expect]` attribute.
>
> ## Updates
>
> Since the initial report, a few questions have been discussed by the lang team, here is a quick overview of the questions and resolutions:
>
> 1. Should the attribute really be called `#[expect]` or is the name too generic?
>
> * `#[expect]` is good ([Decision](https://hackmd.io/@xFrednet/rust-lang-team191#Q1-Name))
> 2. What are the semantics of the `#[expect]` attribute?
>
> * Decision: An expectation should count as fulfilled, if a `#[warn]` attribute at the same location would result in a lint emission ([Decision](https://github.com/rust-lang/rust/issues/115980))
>
> ## Open issues
>
> * `#[expect(lint)]` currently doesn't work on macros. This is in line with other lint attributes. This bug is tracked in [Specifying lint levels does not work on macros #87391](https://github.com/rust-lang/rust/issues/87391) and tested in [`expect_lint_from_macro.rs`](https://github.com/rust-lang/rust/blob/a9bf9eaef5165067414b33777a2c924e42aab5aa/src/test/ui/lint/rfc-2383-lint-reason/expect_lint_from_macro.rs#L26)

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

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

TC: BatmanAoD proposes for stabilization:

> This is a request for _full_ stabilization of the `c_unwind` feature, [RFC-2945](https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md). The behavior of non-`"Rust"`, non-`unwind` ABIs (such as `extern "C"`) will be modified to close soundness holes caused by permitting stack-unwinding to cross FFI boundaries that do not support unwinding.
>
> When using `panic=unwind`, if a Rust function marked `extern "C"` panics (and that panic is not caught), the runtime will now abort.
>
> Previously, the runtime would simply attempt to unwind the caller's stack, but the behavior when doing so was undefined, because `extern "C"` functions are optimized with the assumption that they cannot unwind (i.e. in `rustc`, they are given the LLVM `nounwind` annotation).
>
> This affects existing programs. If a program relies on a Rust panic "escaping" from `extern "C"`:
>
> * It is currently unsound.
> * Once this feature is stabilized, the program will crash when this occurs, whereas previously it may have appeared to work as expected.
> * Replacing `extern "x"` with `extern "x-unwind"` will produce the intended behavior without the unsoundness.
>
> The behavior of function calls using `extern "C"` is unchanged; thus, it is still undefined behavior to call a C++ function that throws an exception using the `extern "C"` ABI, even when compiling with `panic=unwind`.

TC: We had been waiting for a crater run and analysis on this, and that has now been completed:

https://github.com/rust-lang/rust/pull/116088#issuecomment-1870577466

There were no regressions of substance.

From an implementation perspective, this does seem currently blocked on [#113923](https://github.com/rust-lang/rust/pull/113923), which was [reverted](https://github.com/rust-lang/rust/pull/119885), but that probably doesn't need to block our FCP on the language questions.

TC: What do we think?

TC: Niko expressed +1 but did not check his box. With that box, this would move into FCP.

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

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

TC: This has been changed to use `---` syntax with an optional infostring (that is arbitrary except for forbidding whitespace and commas).

TC: tmandry, Josh, and I are +1. What do we think?

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

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

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

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

CAD97 noted:

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

TC: What do we think?

### "Make `ConstPropLint` lint run on promoteds" rust#119432

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

TC: Oli nominates this for us:

> Nominating for T-lang for awareness.... TLDR: existing lints will trigger in more situations where we were missing them before. In our test suite this causes duplicate lint emissions, but they are deduplicated for users.

gurry:

> Fixes #117949 wherein the lint didn't fire for the following promoteds:
>
> * SHL or SHR operators in a non-optimized build
> * any arithmetic operator in an optimized build
>
> What I have done here is simply enabled `ConstPropLint` to run on promoted bodies by removing the relevant `if` check.
>
> After this change _all_ promoted arithmetic operators will lint _in both non-optimized and optimized builds_. On the flip side programs containing the above mentioned overflowing promoteds that were accepted earlier will now be rejected. Hope that is okay from a backward compatibility standpoint.
>
> I have added tests covering all overflowing promoted & non-promoted ops for both compile-time and runtime operations and for optimized as well as non-optimized builds.
>
> I had to amend some existing tests to make them pass and had to delete a couple that were set to pass despite overflows.
>
> This PR increases the number of duplicate diagnostics emitted (because the same operator might get linted in both the promoted MIR and the main MIR). I hope that is an acceptable trade-off given that we now lint overflows much more comprehensively than earlier.

TC: What do we think?

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

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

TC: In addition to documenting the current behavior carefully, this RFC (per RalfJ)...

> says we should allow float operations in `const fn`, which is currently not stable. This is a somewhat profound decision since it is the first non-deterministic operation we stably allow in `const fn`. (We already allow those operations in `const`/`static` initializers.)

TC: What do we think? tmandry proposed this for FCP merge back in October 2023.

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

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

TC: CE handed this one to us, since it changes the contract of macro matchers:

> Right now, the heuristic we use to check if a token may begin a pattern nonterminal falls back to `may_be_ident`.
>
> This has the unfortunate side effect that a `stmt` nonterminal eagerly matches against a `pat` nonterminal, leading to a parse error:
>

macro_rules! m {
    ($pat:pat) => {};
    ($stmt:stmt) => {};
}

macro_rules! m2 {
    ($stmt:stmt) => {
        m! { $stmt }
    };
}

m2! { let x = 1 }

>
> This PR fixes it by more accurately reflecting the set of nonterminals that may begin a pattern nonterminal.
>
> As a side-effect, I modified `Token::can_begin_pattern` to work correctly and used that in `Parser::nonterminal_may_begin_with`.

TC: What do we think?

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

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

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

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

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

There are apparently use cases for this.

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

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

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

TC: What do we think?

### "Lint singleton gaps after exclusive ranges" rust#118879

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

TC: Nadri describes the change:

> In the discussion to stabilize exclusive range patterns (#37854), it has often come up that they're likely to cause off-by-one mistakes. We already have the `overlapping_range_endpoints` lint, so I [proposed](https://github.com/rust-lang/rust/issues/37854#issuecomment-1845580712) a lint to catch the complementary mistake.
>
> This PR adds a new `non_contiguous_range_endpoints` lint that catches likely off-by-one errors with exclusive range patterns. Here's the idea (see the test file for more examples):
>
> ```rust
> match x {
> 0..10 => ..., // WARN: this range doesn't match `10_u8` because `..` is an exclusive range
> 11..20 => ..., // this could appear to continue range `0_u8..10_u8`, but `10_u8` isn't matched by either of them
> _ => ...,
> }
> // help: use an inclusive range instead: `0_u8..=10_u8`
> ```
>
> More precisely: for any exclusive range `lo..hi`, if `hi+1` is matched by another range but `hi` isn't, we suggest writing an inclusive range `lo..=hi` instead. We also catch `lo..T::MAX`.

TC: What do we think?

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

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

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

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

TC: What do we think?

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

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

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

### "unsafe attributes" rfcs#3325

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

TC: tmandry nominated this one for us so that we could finish the bikeshed that we started in time for Rust 2024.

Lokathor laid out these options:

> The three basic proposals are:
>
> * `#[unsafe attr]` ("unsafe space")
> * `#[unsafe(attr)]` ("unsafe parens")
> * `#[unsafe { attr }]` ("unsafe braces")
>
> During the lang meeting on 2023-06-06, it was requested that a summary of how each option actually _looks_ in practice be made,so that hopefully one of the proposals can be selected based on readability.
>
> When using an attribute, the attribute itself can be one of three basic forms:
>
> * lone token: `#[no_mangle]`
>
> * `#[unsafe no_mangle]`
> * `#[unsafe(no_mangle)]`
> * `#[unsafe { no_mangle }]`
>
> * key-val expression: `#[link_section = ".foo"]`
>
> * `#[unsafe link_section = ".foo"]`
> * `#[unsafe(link_section = ".foo")]`
> * `#[unsafe { link_section = ".foo" }]`
>
> * an attribute "call": `#[link_ordinal(15)]`
>
> * `#[unsafe link_ordinal(15)]`
> * `#[unsafe(link_ordinal(15))]`
> * `#[unsafe { link_ordinal(15) }]`
>
> There is also the issue of readability when mixed with `cfg_attr`.
>
> * Interior, around only the attribute:
>
> * `#[cfg_attr(cond, unsafe no_mangle)]`
> * `#[cfg_attr(cond, unsafe(no_mangle)]`
> * `#[cfg_attr(cond, unsafe { no_mangle } )]`
>
> * Exterior, around the `cfg_attr`:
>
> * `#[unsafe cfg_attr(cond, no_mangle)]`
> * `#[unsafe(cfg_attr(cond, no_mangle))]`
> * `#[unsafe { cfg_attr(cond, no_mangle ) }]`

TC: This is an interesting case because we are not *discharging* unsafety, as with `unsafe { expr }` in a function body. Neither does saying `unsafe` here create and push upward a type-checked *obligation*. Instead, the upward obligation exists regardless and there is no means to signal to the compiler that it has been discharged and no enforcement of that.

TC: Another option I've seen discussed is finding some way to make these annotations safe.

TC: What do we think?

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

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

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

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

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

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

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

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

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

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

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

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

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

TC: Recently CAD97 raised an interesting alternative:

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

TC: What do we think?

---

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

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

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

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

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

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

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

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

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

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

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

TC: Urgau proposes this for us:

> This PR aims at uplifting the `clippy::invalid_null_ptr_usage` lint into rustc, this is similar to the [`clippy::invalid_utf8_in_unchecked` uplift](https://github.com/rust-lang/rust/pull/111543) a few months ago, in the sense that those two lints lint on invalid parameter(s), here a null pointer where it is unexpected and UB to pass one.
>
> ## `invalid_null_ptr_usages`
>
> (deny-by-default)
>
> The `invalid_null_ptr_usages` lint checks for invalid usage of null pointers.
>
> ### Example
>

// Undefined behavior
unsafe { std::slice::from_raw_parts(ptr::null(), 0); }
// Not Undefined behavior
unsafe { std::slice::from_raw_parts(NonNull::dangling().as_ptr(), 0); }

>
> Produces:
>

error: calling this function with a null pointer is undefined behavior, even if the result of the function is unused, consider using a dangling pointer instead
  --> $DIR/invalid_null_ptr_usages.rs:14:23
   |
LL |     let _: &[usize] = std::slice::from_raw_parts(ptr::null(), 0);
   |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^-----------^^^^
   |                                                  |
   |                                                  help: use a dangling pointer instead: `core::ptr::NonNull::dangling().as_ptr()`

>
> ### Explanation
>
> Calling methods who's safety invariants requires non-null pointer with a null pointer is undefined behavior.
>
> The lint use a list of functions to know which functions and arguments to checks, this could be improved in the future with a rustc attribute, or maybe even with a `#[diagnostic]` attribute.

TC: What do we think?

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

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

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

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

### "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 on "must define before use" for opaque types" rust#117866

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

TC: The question is whether to adopt the following "must define before use" rule for opaque types:

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

This is a breaking change to RPIT. Here's an example of code that works today that would break under this rule:

use core::convert::identity;

struct I;
struct IShow;
impl I { fn show(&self) -> IShow { IShow } }

struct OnIShow;
trait OnI { fn show(&self) -> OnIShow { OnIShow } }
impl OnI for I {}

fn test(n: bool) -> impl OnI {
    let true = n else { loop {} };
    let x = test(!n); //~ NOTE this is the opaque type
    let _: OnIShow = x.show(); //~ NOTE this is a non-defining use
    //~^ ERROR if the body registers a hidden type for the opaque, it
    //         must do so *before* using it opaquely
    let _: IShow = identity::<I>(x).show();
    //~^ NOTE this registers a hidden type for the opaque, but does so
    //        too late
    loop {}
}

fn main() {}

This rule has relevance to the new trait solver.

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

### "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 (e.g. `!`, `*`, `&`)?

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

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

TC: nikomatsakis nominated this:

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

TC: What do we think?

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

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

TC: We discussed this on 2023-11-22. The general feeling seemed to be that we wanted to find some way to enable this, including for raw pointers, `NonNull`, etc., but we were feeling unsure about the path to get there. We asked the author to cogitate on this and come back with a revised plan.

TC: The author did that, and we had an extensive discussion on 2024-01-17 without consensus. We have open threads for discussing this asynchronously.

Here's the thread for the proposal:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Arbitrary.20self.20types.20v2.20RFC

And here's the thread for the broader question of whether we want arbitrary self types at all:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Do.20we.20want.20arbitrary.20self.20types.3F

TC: We have a design meeting schedule for 2024-02-28 for this.

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

### "Notes from my RFC experience" lang-team#252

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

## RFCs waiting to be merged

None.

## `S-waiting-on-team`

### "[ptr] Document maximum allocation size" rust#116675

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

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

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

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

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

### "Lint singleton gaps after exclusive ranges" rust#118879

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

### "Make `ConstPropLint` lint run on promoteds" rust#119432

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

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

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

### "Stabilize `cfg_target_abi`" rust#119590

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

### "privacy: Stabilize lint `unnameable_types`" rust#120144

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

### "Implement RFC 3373: Avoid non-local definitions in functions" rust#120393

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

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

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

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

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

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

### "RFC: patchable-function-entry" rfcs#3543

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

### "RFC: New range types for Edition 2024" rfcs#3550

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

### "Tracking issue for Allow a re-export for `main` (RFC 1260)" rust#28937

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

### "Tracking Issue for cfg-target-abi" rust#80970

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

### "Tracking issue for function attribute `#[no_coverage]`" rust#84605

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

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

### "[ptr] Document maximum allocation size" rust#116675

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

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

### "Add `REDUNDANT_LIFETIMES` lint to detect lifetimes which are semantically redundant" rust#118391

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

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

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

## Active FCPs

### "RFC: Rust Has Provenance" rfcs#3559

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

### "Tracking Issue for `min_exhaustive_patterns`" rust#119612

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

### "Make unsafe_op_in_unsafe_fn warn-by-default starting in 2024 edition" rust#120535

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

## P-critical issues

None.