T-lang meeting agenda

• Meeting date: 2025-05-28

Attendance

• People: TC, Josh, tmandry, scottmcm, eholk, Mara, Jubilee, Yosh, Boxy, martinomburajr

Meeting roles

• Minutes, driver: TC

Scheduled meetings

None.

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

Guest attendee items

TC: For any guests who are present, please note in this section if you're attending for the purposes of any items on (or off) the agenda in particular.

• jubilee: I'm going to show up in a couple minutes I showed up for "Remove unstable cfg target(...) compact feature" rust#130780 and "Add (back) unsupported_calling_conventions lint to reject more invalid calling conventions" rust#141435

Moving right along

TC: As we've been doing recently, due to the impressive backlog, I'm going to push the pace a bit. If it's ever too fast or you need a moment before we move on, please raise a hand and we'll pause.

Design meeting at 12:30 EST / 09:30 PST / 17:30 CET

TC: Remember that we have a design/planning meeting that starts half an hour after this call ends.

Next meeting with RfL

We're next meeting with RfL on 2025-06-05
to review the status of RfL project goals.

https://github.com/rust-lang/rfcs/pull/3614

Rust 2025 review

Meta

TC: We should start thinking about Rust 2025.

Our motivating priorities are:

• Make every edition a success.
• Do so without requiring heroics from anyone.
  • …or stressing anyone or everyone out.

The tentative timeline will be:

Date	Version	Edition stage
2025-04-03	Release v1.86	Checking off items…
2025-05-15	Release v1.87	Checking off items…
2025-06-26	Release v1.88	Checking off items…
2025-08-07	Release v1.89	Checking off items…
2025-09-12	Branch v1.91	Go / no go on all items
2025-09-18	Release v1.90
2025-10-24	Branch v1.92	Stabilize Rust 2025 on nightly
2025-10-30	Release v1.91	Rust 2025 nightly beta
2025-12-05	Branch v1.93	Cut Rust 2025 to beta
2025-12-11	Release v1.92	Announce Rust 2025 is pending
2026-01-22	Release v1.93	Release Rust 2025

None.

Nominated RFCs, PRs, and issues

"Document representation of Option<unsafe fn()>" rust#141447

Link: https://github.com/rust-lang/rust/pull/141447

TC: This easy call is now in FCP.

"const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns" rust#140942

Link: https://github.com/rust-lang/rust/pull/140942

TC: RalfJ proposes that we accept code like this:

static FOO: AtomicU32 = AtomicU32::new(0);
const C: &'static AtomicU32 = &FOO;

As he says:

This can be written entirely in safe code, so there can't really be anything wrong with it.

Josh and I had previously discussed and thought it seemed right. I've proposed FCP merge. What do we think?

Josh: This one seems perfectly reasonable to me.

TC: So this one is now just waiting for Niko.

"Stabilize if let guards (feature(if_let_guard))" rust#141295

Link: https://github.com/rust-lang/rust/pull/141295

TC: This is a stabilization of if let in match arm guard position. Notably this is able to be stabilized in all editions.

TC: I've proposed FCP.

Josh: This is one of those things that seems like it always should have been there, which is the sign of a really good lang addition.

tmandry: I'm happy to land this if it's ready. I spent some time digging around for a test that compares the eval and drop order of arms and expressions and finally found one, but haven't compared in detail yet.

https://github.com/rust-lang/rust/blob/d423c815a69bbcfb4abcd23a828b9a513c397632/tests/ui/drop/drop-order-comparisons.rs#L349

TC: Yes, they had updated the drop order comparison test that I wrote and that we'd reviewed for the let chains stabilization to include this also.

TC: Here's also a shorter ad-hoc test I put together in review:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=c3cb03999c00d48017edf02548060370

---

(Aside not discussed in meeting…)

yosh: I think this could close the door on changing if in guards to && as per my post. Not entirely sure whether that's important. But that's the only downside I see.

Josh: While I wouldn't want to go full perl TIMTOWTDI, I don't think we'd be closing that door just because there's another way to do it. I'd be interested in seeing that proposal. Also, you might appreciate this: https://rust-lang.zulipchat.com/#narrow/channel/481660-t-lang.2Fpattern-types/topic/Pattern.20types.20-.20negative.20patterns/with/518221704 . Seems like a logical extension to supporting logical operators.

yosh: Ohh, yeah that is interesting. ty! Also: if you think it's worthwhile, I'd be happy to write up an RFC for this to more formally put it up for consideration.

Josh: I'd want to see && separated from ||, since it seems much much simpler. But for my part, I'd love to see it RFCed…after being vibe-checked with others, though.

Yosh: makes sense to me! What's the way to poll for a vibe check?

Josh: That's a great question that we've been trying to answer better lately.

Yosh: I'll open a Zulip issue to get a vibe check. See if that works out.

---

tmandry: The stabilization report looks good and I'm ready to check a box.

TC: Then this one will go into FCP.

"Stabilize feature(generic_arg_infer)" rust#141610

Link: https://github.com/rust-lang/rust/pull/141610

TC: I've proposed FCP merge. I noted in a couple of comments that we're leaning on 1) some inference breakage that will land in 1.89, and 2) a choice about how this is ordered with respect to integer fallback.

Boxy: The other choice here is about whether to support paretheses around the underscore.

We allow parenthesised inferred const arguments as well as bare underscores. For example: let arr: [u8; (((_)))] = [10; 2];. It's not clear to me if this is desirable, it's consistent with type arguments where we support [(((_))); 2], but inconsistent with const generics not yet supporting Foo<((((N))))>.

scottmcm: Are there any parsing considerations here?

scottmcm: I don't think we need to support foo::<(((_)))>() as a const parameter; the parens make it not the "single path const" case, so I think it would be sufficiently-consistent to require just _ or to require braces to use more parens.

Boxy: There was a lot of work here.

tmandry: As long as there's a path to making this consistent, I'm OK with it.

Josh: I'm curious about the handling of Copy. Is that putting more smarts into the type system to handle if N > 1 then T: Copy?

Boxy: No new type system feature. Currently if a repeat count comes from a const generic, we assume conservatively that it might be greater than 1, and always require Copy.

tmandry: I'm ready to check a box here.

TC: Are we happy with the parentheses handling?

jubilee: It's worth noting that the common case, without parentheses, is already ambiguous about whether it's a type or a const.

Boxy: It's sort of more work to forbid it, since we need to accept the parentheses anyway in case it turns out to be a type.

TC: Good enough for me; I like that syntactic argument.

tmandry: And it's now in FCP.

TC: With four checkboxes.

"Decide whether to separate cfg(version("..")) and cfg_has_version" rust#141401

Link: https://github.com/rust-lang/rust/issues/141401

TC: Do we think we can move this, or do we just want to wait for Niko and give him the (supermajority) casting vote?

Josh: I think we can move it.

tmandry: I'd similarly like to talk about it.

Josh: I want to note that I'm in full support of the goal of allowing this to help in some way people with older MSRVs. My primary concern would be usability and complexity. Five years from now, nobody will care about cfg_has_version.

scottmcm: The version-aware resolver makes this situation better also.

Josh: My feeling is that cfg_has_version needs a nontrivial amount of design and usage documentation, but if it showed up with an RFC I would probably check a box. I feel like it shouldn't be tied in with shipping cfg(version(..)); some people will adopt cfg(version(..)) sooner, and once we have cfg_has_version that'll let more crates adopt it.

TC: For me, there's a straightforward process case here. We have an accepted RFC for cfg(version(..)). It's implemented and ready to ship. Someone has put up a stabilization report. We still agree it's worthwhile; nothing has changed there. The cfg_has_version feature is a new proposal, and there are design concerns around it. There don't seem to be backward compatibility concerns with adding that or something similar later. So, under our normal practices, we should make incremental progress and stabilize what we can, then work through the design concerns on the other and see if we can stabilize more later.

TC: Further, we were confusing people on the stabilization by adding this new feature during the stabilization. So it does feel to me that our choices are between stabilizing this as-is or, backing up and blocking this pending more design work, a new RFC, etc.

Josh: We can document things here too.

tmandry: Maybe with the documentation, this would indeed be OK.

TC: OK, so tmandry is going to comment on this issue and check a box so we signal to est31 to put up the cfg(version(..)) stabilization report, and tmandry is planning to put together an RFC for cfg_has_version.

"Add (back) unsupported_calling_conventions lint to reject more invalid calling conventions" rust#141435

Link: https://github.com/rust-lang/rust/pull/141435

TC: The main question here is whether we want to go directly to doing the FCW in deps. It seems OK to me given that many libraries probably aren't going to know they have a problem until downstreams report anyway, so I don't know we gain much by walking it more slowly.

Josh: It seems OK to go full speed on this. Though it'd be good for us to have clear documentation about what people should do instead.

scottmcm: We had talked about how people could use proc macros for this. It's not an easy thing to write, but it's possible.

Josh: It does look like system solves the really common case. Maybe we should add a lint suggestion about that. That would leave the fastcall case; if we told people there to use a macro or whatever, then that would give people sufficient advice.

Jubilee: Using a macro would be reasonable if people had the option of decl macros in that position. But people aren't going to write a full proc macro for this.

TC: It seems none of us want to walk this more slowly, so I'll propose FCP merge.

TC: It's now in FCP.

(The first part of the meeting ended here.)

---

(The second part of the meeting started here.)

People: TC, Josh, tmandry, scottmcm, Jubilee, eholk, Yosh

"Make the dangerous_implicit_autorefs lint deny-by-default" rust#141661

Link: https://github.com/rust-lang/rust/pull/141661

TC: We had FCPed this as deny-by-default, arguably, but the PR didn't do that.

tmandry: I think of deny-by-default as saying that we wished we'd never done this in the language. Is that how we think of it?

TC: Probably I don't think of it that way. There are things that make sense – from a consistency perspective – to be in the language, but where we can tell that you don't want to do this, ever.

TC: Here, we're making a normative statement as the lang team about how Rust should be written, and saying that these references should always be fully elaborated, e.g. because reviewers should not have to run typeck in their heads to see these, as they're important.

(TC: This went into FCP.)

"Remove unstable cfg target(...) compact feature" rust#130780

Link: https://github.com/rust-lang/rust/pull/130780

TC: Urgau suggests that we remove the cfg_target_compact unstable feature. This allows writing, e.g., cfg(target(os = "linux", arch = "arm"). This only costs 28 lines of code in the compiler to support. I proposed, via FCP, that we don't remove this and instead invite a stabilization. What do we think?

Josh: I think that https://github.com/rust-lang/rfcs/pull/3796 is a better alternative here. But also, no objection to either stabilization or removal. Mild preference for removal.

Jubilee: std doesn't use cfg_target_compact, which is a warning sign. We're the ones who don't give a single damn about stability concerns and have a mountain of cfg, but it doesn't address our needs enough to be worth bothering, despite having had several passes recently through cleaning up a bunch of cfg-heavy code (esp. around thread-local stuff).

Jubilee: also, obviously Trevor's cfg_alias comes from someone who is working on precisely that stuff.

Jubilee: note that it currently doesn't cover every target_ thing you can cfg on, just a somewhat-arbitrary subset

TC: We're pulling the eject handle on this. Doesn't look like we can move forward either way at the moment, and it's just not that important. We're talking about whether to remove 28 lines of code.

"Lint on fn pointers comparisons in external macros" rust#134536

Link: https://github.com/rust-lang/rust/pull/134536

TC: This is a question of whether we want to extend a lint. We had talked about this extension when considering the original lint, but we didn't answer that question. See:

https://github.com/rust-lang/rust/pull/134536#issuecomment-2557487035

TC: What do we think?

TC: I had proposed FCP merge here. tmandry, you had filed a concern, but it looks like we can resolve that.

tmandry: I'll resolve it, and it's now in FCP.

"Split up the unknown_or_malformed_diagnostic_attributes lint" rust#140717

Link: https://github.com/rust-lang/rust/pull/140717

TC: mejrs wants to break up a lint. The motivation is related to holding a lower MSRV.

What do we think?

TC: Actually, it looks like three of us meant to check a box, but the bot didn't pick it up.

tmandry: I've rechecked.

TC: And it's now in FCP.

"fn_cast! macro" rust#140803

Link: https://github.com/rust-lang/rust/issues/140803

TC: People, including the standard library, use a trick like this for type erasure:

/// Invariant: there exists some type `T` such that `data` is actually
/// a `&'a T` and `op` is actually a `fn(&T)`.
struct ErasedTypeAndOp<'a> {
    data: *const (),
    op: unsafe fn(*const ()),
    _phantom: PhantomData<&'a ()>,
}

impl<'a> ErasedTypeAndOp<'a> {
    pub fn new<T>(data: &'a T, op: fn(&'a T)) -> Self {
        Self {
            data: data as *const _ as *const (),
            op: unsafe { core::mem::transmute(op) },
            _phantom: PhantomData,
        }
    }

    pub fn call_op(&self) {
        unsafe { (self.op)(self.data) }
    }
}

Unfortunately, even though this is allowed by our ABI compatibility rules, it creates problems for CFI (control-flow integrity) and KCFI since the caller and callee don't agree about the callee's signature.

There are ways to write this in a CFI-friendly way by using a trampoline function, and what's proposed here is that we add a way to generate this trampoline automatically and only when necessary.

With that, it becomes maybe feasible for us to say that while such mismatched calls are still defined behavior, they're "erroneous" (mostly in that they're second-class since they won't work with CFI).

What do we think?

Josh: Deeply amused by your anthropomorphization of the standard library. "People, including the standard library, …"

Josh:

for the concept.

Josh: Also, broadly speaking I'd love to see better ways to do this with a closure, safely. But that's separate.

Josh: We could add a lint on the cast, maybe.

Jubilee: one thing I've never really understood is why we can't just do this implicitly as part of the compiler generating code for CFI… I've tried to ask but I've never gotten a really satisfactory explanation, I feel. obviously adding a macro makes it easier for the compiler, but it seems like we could?

scottmcm: RalfJ and company just went through and documented all of these ABI compatibilities. It'd seem a shame to undo this work.

Josh: The transmute here could be through an arbitrarily nested struct, etc, so we can't reliably catch this and do it implicitly.

scottmcm: We generally use "transmute" to means lots of things that aren't just the transmute intrinsic – for example reading through unions or pointer casts or whatever – and those cases the compiler fundamentally can't add the conversion code. Imagine pointer casting a slice, for example. (See also how transmuting pointers to integers doesn't expose addresses, even though as casts do.)

tmandry: As I recall, CFI is weird, in that it privileges C types. Does anyone have context on this?

TC: Yes, this is covered in some detail in rcvalle's design document:

https://rcvalle.com/docs/rust-cfi-design-doc/

Jubilee: CFI has a number of compiler options that allow code to be shipped with additional metadata that allow you to normalize away certain differences when compiling the final binary of CFI-enabled code. AIUI this metadata is already shipped for all pointers-to-structs (C type puns aggressively in this case) so you can always compile artifacts with "pointer normalization" without recompiling anything. There is also an "integer normalization" option, added at our behest, that handles this compatibility issue with Rust's view on integer types, but the metadata to do this is not shipped implicitly AIUI unlike the metadata sufficient to do "pointer normalization".

scottmcm: If I'm understanding you correctly, does that imply that we wouldn't need this macro, because we'd always normalize to our ABI compatibility?

Jubilee: I'd need to do more research to give a precise answer on every case, but there's a number of cases like repr(transparent) that we directly encode as the "underlying" type when generating our own CFI metadata. I also believe this applies to Option<T> encoding identically to U when T is a niched variant of U.

scottmcm: I'd like to make sure that at least all the cases in https://doc.rust-lang.org/std/primitive.fn.html#abi-compatibility work without needing this workaround.

TC: OK, the plan is that we'll leave our various comments here on the thread.

"Permit duplicate macro imports" rust#141043

Link: https://github.com/rust-lang/rust/pull/141043

TC: There's a pattern like this that comes up with serde and other popular crates. Consider:

mod serde {
    pub(crate) trait Serialize {}
    #[cfg(feature = "derive")]
    pub(crate) use crate::serde_derive::Serialize;
}

mod serde_derive {
    macro_rules! Serialize { () => {} }
    pub(crate) use Serialize;
}

mod caller {
    pub(crate) use crate::serde::Serialize;
    pub(crate) use crate::serde_derive::Serialize;
    //~^ ERROR the name `Serialize` is defined multiple times
}

That is, a caller like the one above can be broken by the derive feature being enable anywhere in the crate graph.

It seems OK to me to allow duplicate imports of the same item. The unused_imports lint will still fire. I've proposed FCP merge.

scottmcm: Does this add any new SemVer breaks? E.g., if today instead of reexporting a function, you make a wrapper function that calls the other function, I don't know if changing from the reexport to the wrapper is SemVer breaking. Maybe there are some weird corner cases around the function pointer type. It'd have to be something that wasn't a type. For a trait it's already a breaking change. For a sealed trait maybe?

Jubilee: I'd suggest poking predrag on this. (Maintainer of cargo-semver-checks.)

scottmcm: For example, suppose something like this:

Upstream crate v1:

pub mod foo { pub fn qux() {} }
pub mod bar { pub use super::foo::qux; }

Downstream crate:

// This change would make this allowed
use othercrate::bar::qux;
use othercrate::foo::qux;

Upstream crate v2:

pub mod foo { pub fn qux() {} }
pub mod bar { pub fn qux() { super::foo::qux() } }

Now the downstream crate is broken because they're different imports now.

Josh: Is this a blocker for you?

scottmcm: No, I think I'm generally fine going forward with it unless this new breakage was big in some way.

tmandry: I'd like to understand this example and think about it a bit.

(We lost scottmcm at this point.)

TC: OK, we'll check in with predrag and think about these cases.

"Consider folkertdev's c_variadic proposal" rust#141524

Link: https://github.com/rust-lang/rust/issues/141524

TC: Probably the ask here is to give vibes and feedback.

Josh: This stalled out earlier due to people not having time to push it forward. Folkertdev has offered to pick this up and now has a simpler proposal. It seems to me like the right path forward here.

Jubilee: I've been trying to help coach this along a bit with my existing knowledge of the horrors of C's weirdness and ABI weirdness.

Jubilee: There's a bunch of edge-cases with C variable arguments which is why I have tried to recommend simplifying things more.

(Folkert de Vries joined us at this point.)

folkertdev: I'd really like to see this stabilized, though it seems more like a libs concern? Though there are lang concerns regarding certain edge-cases.

Jubilee: one of the actual lang concerns here is in https://github.com/rust-lang/rust/issues/141618 which causes problems if we want to support defining C-style variable arguments for multiple ABIs in a single program.

tmandry: I'd like to see this move forward in some way. It probably does need an RFC to be stabilized. We could do a lang experiment as well, if that'd help. It is lang, in that we're desugaring this in the language. Maybe Josh would be happy to champion it.

Josh: I would. The other lang aspect is the use of super let.

tmandry: I'd like to see the implications of va_start being written out somewhere. Positive vibes overall.

Josh: Is there a one-way door on multiple ABIs?

Jubilee: We could handle it in the future backward-compatibly if we added a defaulted generic to it.

Josh: Or multiple types?

Jubilee: Yeah that's probably doable, as long as we're happy to commit to that being potentially vaguely more annoying.

"Unsafe fields" rfcs#3458

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

TC: Nearly ten years ago, on 2014-10-09, pnkfelix proposed unsafe fields in RFC 381.

TC: What do we think? It looks like tmandry, you nominated it last.

https://github.com/rust-lang/rfcs/pull/3458#issuecomment-2825837922

tmandry: It seems like the RFC has converged a bit.

Josh: It seems like making it simpler by saying everything is unsafe is the way to go.

TC: Probably we'll need to all read the new draft and design.

Josh: Any reason we shouldn't start an FCP?

tmandry: The only reason I haven't done it is that I'd like to do more review.

Josh: I'm ready, so I'll fire it off.

"[RFC] Add #[export_ordinal(n)] attribute" rfcs#3641

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

TC: This RFC would allow writing:

#[no_mangle]
#[export_ordinal(1)]
pub extern "C" fn hello() {
    println!("Hello, World!");
}

TC: There was a long-outstanding FCP, which I canceled due to membership changes. Josh nominates this for us to collect checkboxes. What do we think?

Josh: (Explains context.)

TC: If you're still happy with it, let's refire that FCP proposal.

Josh: Done.

(TC: This went into FCP.)

"Add must-use-output attribute" rfcs#3773

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

TC: We have #[must_use] that applies to function return types. This RFC proposes a similar attribute that can be applied to output arguments on functions and have the same effect. E.g.:

impl<T> Vec<T> {
    pub fn push(#[must_use_output] &mut self, item: T) { /* ... */ }
}

TC: What do we think?

TC: I want to spell this #[must_use]. Otherwise I'm happy with this proposal.

Josh: That makes sense from the perspective of the caller, but from the perspective of the callee, it's maybe ambiguous. That's not a strong objection.

Josh: Arguably, everything in the signature is automatically must-use because it doesn't have an underscore. If you want to have the author change it to #[must_use], we could do that.

tmandry: This seems useful in the abstract and I support calling this #[must_use]. I wonder about why we couldn't do this implicitly.

Josh: …

tmandry: I'd prefer if the RFC could write this out.

Josh: I can write up a summary about why this can't be done implicitly and that we want to call it #[must_use].

"continue expressions in loop conditions" rust#118673

Link: https://github.com/rust-lang/rust/issues/118673

TC: This is an odd one. We accept:

'a: while continue 'a {}

The documentation in the Reference specifically disallows this, creating an opportunity for us to decide whether the Reference or the compiler is correct.

Personally, I wouldn't expect us to accept 'a: while continue 'a {} unless we were to also accept 'a: { continue 'a }.

What do we think?

TC: I'd suggest someone doing a crater run to see if we can disallow this.

TC: On the other hand, I'd actually prefer to go the other direction and allow 'a: { continue 'a }.

(tmandry dropped at this point: "gotta go but would check a box".)

"Add lint against (some) interior mutable consts" rust#132146

Link: https://github.com/rust-lang/rust/pull/132146

TC: Urgau nominates a new lint for us. What do we think?

TC: I kind of don't want to do this because there's an equivalence that I want to hold:

https://github.com/rust-lang/rust/pull/132146#issuecomment-2707783407

TC: At the same time, I agree that people get confused sometimes, and I'd like to find a way to help people there, but not in this way.

Jubilee: I feel like there is something to lint against here but not this way because the lint, afaict, is on the item itself, as opposed to on some behavior that seems to misuse the const. Declaring an item and making it a const could simply be because you want to declare the same initializer once and then copy that around.

(Jubilee: A back-and-forth discussion that was hard to capture in minutes followed. Jubilee would editorialize as mostly reprising taiki-e and Urgau's discussion over what clippy lint to uplift, with TC playing taiki-e and Josh Triplett playing Urgau. After a bit Jubilee mentions that they are doing this reprise.)

Jubilee: taiki-e suggests doing clippy::borrow_interior_mutable_const instead.

TC: Interesting, will look more closely at that.

Josh: I'll summarize the discussion on the issue.

"Specify the behavior of file!" rust#134442

Link: https://github.com/rust-lang/rust/pull/134442

TC: kornelski made a good point about the tension between two uses of this feature. I've nominated it for us to consider.

Josh: We could try to do some tracking of using a tainted, remappable file!() name when running Rust code via cargo miri.

TC: The use case that's motivating this seems like something that shouldn't use a macro that's intended for producting diagnostic output. I don't want us to hesistate to change it in the ways that are appropriate for that use case because it'll break people using it for this other thing. I.e., Hyrum's law.

Jubilee: I think in Rust we've been pretty successful in convincing people they are in fact going to keep the pieces if they rely on behavior we ominously suggest might break. Partly by making sure that we actually do specify guarantees when we mean to.

TC: I'm OK with us documenting this as long as we capture what korneski said, i.e. we document that this might return any arbitrary thing. That is, it's OK to document the current behavior, but I want to weaken the guarantee to match the fact that we're likely to arbitrarily change the output depending on compiler flags that your code doesn't necessarily control.

Josh: I can add a GH suggestion that adds text to that regard.

"Fallback {float} to f32 when f32: From<{float}> and add impl From<f16> for f32" rust#139087

Link: https://github.com/rust-lang/rust/pull/139087

(Pulled up from our radar.)

Josh: We should have a look at this, as it's maybe blocking the stabilization of f16.

TC: Probably someone needs to make a proposal for another way to do it, as a number of us don't want to do it in exactly the way proposed here.

Josh: At the all hands, we talked about maybe adding an integer type that cannot appear at runtime.

TC: Interesting. Probably I'd prefer to model that as a trait, then make integer literals into an opaque, and add the necessarily coercions.

(The meeting ended here.)

---

"Decide on behavior of anonymous_lifetime_in_impl_trait" rust#137575

Link: https://github.com/rust-lang/rust/issues/137575

TC: We unnominated the original PR back in October 2023 as more analysis seemed to be needed. Since then, nikomatsakis and tmandry have posted substantive analysis that it seems we should discuss.

Unfortunately, the author seems to have lost interest in this stabilization. Still, we'd be well-advised to finish our discussion so as to unblock anyone else from pursuing this.

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

"Closing issues relevant to T-lang on this repo" rfcs#3756

Link: https://github.com/rust-lang/rfcs/issues/3756

TC: We're being asked what we want to do, if anything, about issues (rather than PRs) in the RFCs repo. Thoughts?

"Rename "unsized" coercion as "unsizing"" reference#1797

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

TC: We've called thing "unsized coercions" for a long time. Do we want to keep this name or change it?

On radar RFCs, PRs, and issues

"Fallback {float} to f32 when f32: From<{float}> and add impl From<f16> for f32" rust#139087

Link: https://github.com/rust-lang/rust/pull/139087

TC: Start here:

https://github.com/rust-lang/rust/pull/139087#issue-2957255130

What do we think?

"[WIP] Forbid object lifetime changing pointer casts" rust#136776

Link: https://github.com/rust-lang/rust/pull/136776

TC: This PR acts to try to resolve a different concern around the stabilization of arbitrary self types and derive(CoercePointee). It produces distinctly non-zero regressions. Let's review this situation.

What do we think?

"Tracking issue for cfg_match" rust#115585

Link: https://github.com/rust-lang/rust/issues/115585

TC: There's been a cfg_match! macro in the works for awhile. There's now a stabilization up. tmandry suggests that we have a look, and we should probably go on the FCP.

Josh: Note that this was renamed to cfg_select!.

"Split elided_lifetime_in_paths into tied and untied" rust#120808

Link: https://github.com/rust-lang/rust/pull/120808

TC: There's a new proposal here for us to work through.

"Make missing_fragment_specifier an unconditional error" rust#128425

Link: https://github.com/rust-lang/rust/pull/128425

TC: tgross35 wants us to make missing_fragment_specifier a hard error in all editions. We started linting on deps in Rust 1.82. The lint is set to deny. What do we think?

"Arbitrary self types v2: stabilize" rust#135881

Link: https://github.com/rust-lang/rust/pull/135881

TC: Adrian Taylor has put up a stabilization PR for arbitrary self types. I've reviewed the tests and talked through some nits with Adrian. It seems right to me. What do we think?

"Stabilize return type notation (RFC 3654)" rust#138424

Link: https://github.com/rust-lang/rust/pull/138424

TC: CE put up the long-awaited stabilization PR for RTN. It looks right to me. I've proposed FCP merge. What do we think?

"Add #[loop_match] for improved DFA codegen" rust#138780

Link: https://github.com/rust-lang/rust/pull/138780

TC: We accepted a project goal for having a better way to express state machines. There's a PR for the experiment for this. It adds two attributes that work with a restricted syntax pattern. I.e., it doesn't add new syntax. Are we OK with this experiment. I'm the "champion".

"#[target_feature] mismatch on unsafe trait fn vs its impl causes sneaky UB" rust#139368

Link: https://github.com/rust-lang/rust/issues/139368

TC: Someone found a sneaky unsoundness with target_feature. What do we think?

"Spurious irrefutable_let_patterns warning with let-chain" rust#139369

Link: https://github.com/rust-lang/rust/issues/139369

TC: Ralf wants us to not lint against:

fn max() -> usize {
    42
}

fn main() {
    if let mx = max() && mx < usize::MAX {
        // ...
    }
}

In the last meeting, we had a long discussion and decided to remove this lint entirely. After the meeting, tmandry raised a concern about this. I've suggested the concern actually generalizes to any trivial condition.

The original consensus:

https://github.com/rust-lang/rust/issues/139369#issuecomment-2842997955

The concern:

https://github.com/rust-lang/rust/issues/139369#issuecomment-2843953637

My proposed generalization:

https://github.com/rust-lang/rust/issues/139369#issuecomment-2844147025

Anyway, what do we think?

"Stabilize fn_align: #[repr(align(N))] on functions and -Zmin-function-alignment" rust#140261

Link: https://github.com/rust-lang/rust/pull/140261

TC: This is a stabilization for a way to align functions.

We should have a look at the point that Jules makess in favor of #[align(..)] rather than #[align(repr(..))] here:

https://internals.rust-lang.org/t/pre-rfc-align-attribute/21004/27

Essentially, do we think of functions as more likely structs or more like statics, and if we were to have a way to align statics, would we say #[align(repr(..))] or #[align(..)]?

"core::marker::NoCell in bounds (previously known an Freeze)" rfcs#3633

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

TC: We have up a proposed FCP. What do we think?

"Unsafe derives and attributes" rfcs#3715

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

TC: Josh proposed FCP for this RFC back in November 2024. He's now nominated it. What do we think?

"[RFC] Allow packed types to transitively contain aligned types" rfcs#3718

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

TC: This came up in a lang/RfL call. We might want to have a look for what we think here.

"Tracking issue for RFC 2523, #[cfg(version(..))]" rust#64796

Link: https://github.com/rust-lang/rust/issues/64796

TC: Wesley Wiser, the compiler team lead, nominates this for us:

This was marked as blocked on #64797 two years ago but #64797 still has open design questions and does not appear ready for stabilization anytime soon whereas this feature has no open design questions and is fully implemented. Since #64797 does not address some important use cases such as conditionally using compiler or language features and use of version_check continues to grow (now at >229M all-time downloads and upward-trending daily downloads), I think it makes sense to revisit stabilization of this feature.

The issue we had marked it blocked on is RFC 2523, #[cfg(accessible(::path::to::thing))].

• https://github.com/rust-lang/rust/issues/64797
• https://github.com/rust-lang/rfcs/pull/2523

This was last proposed for stabilization 2021-03-16:

• https://github.com/rust-lang/rust/issues/64796#issuecomment-799847092

Josh said at that time:

Based on that report, this feature seems ready in isolation.

However, when last we discussed this feature, we also had the concern that stabilizing a compiler version check before stabilizing accessible would have a negative effect on the ecosystem, by pushing people towards version checks rather than feature checks. I feel that that concern still holds.

I'm furthermore concerned that once we have version, there will be even less motivation to work on accessible.

cramertj proposed it for FCP merge anyway:

@joshtriplett I agree that it would be better if we could stabilize accessible first. However, I do think this is a very useful feature, and there is real harm done to the ecosystem by not providing it. I also believe that, once accessible is made available, we will be able to successfully encourage the ecosystem best practices to adapt (over time). accessible is currently at the pre-implementation phase, whereas this feature has been implemented and had time to bake on nightly for months. With that in mind, I personally would be in favor of moving forwards with stabilization.

Niko was +1:

I look forward to having this feature available. It may also help with some questions around the async libraries, as it enables one to have methods that move to libstd and "disappear" from the futures crate at the same time.

I agree that it would be nice to make progress on accessible as well– my impression when last we spoke was that accessible is largely implemented? I may be misremembering.

However, in general, I don't like holding up things that are ready because of other things that are not yet ready.

Josh then registered a concern:

I'm going to go ahead and register this as a concern, precisely because accessible is harder than version. Other ecosystems (e.g. C) had version-detection much earlier than they had feature-detection, and the effects of that are quite visible in the ecosystem. I'm quite concerned that version will become the "good enough" mechanism for detection, and accessible won't end up happening.

@est31 To be clear, I do think we need both, precisely because accessible only works for library changes, not for language changes. I'd love to have a variant of accessible that works for language changes as well, but there are multiple ways we could do that.

Note: this concern is predicated on the understanding that accessible is feasible to implement, and "just" needs further implementation work. If that turns out to not be the case, and there's some critical blocking issue that prevents implementing accessible as specified, then I'd like to see it re-specified in a fashion that'd be more feasible to implement, but I'd be willing to drop this concern because I don't think stabilizing version should wait on further design work.

Niko later canceled FCP. Josh later commented:

It looks like cfg(accessible(...)) may be at a state where we could stabilize enough of it to be generally useful, and what's available is enough that I'd consider it to unblock this.

TC: Where are we on this?

"Support for pointers with asm_const" rust#128464

Link: https://github.com/rust-lang/rust/issues/128464

TC: Niko nominates to ask whether extending const for asm needs an RFC. What do we think?

"lexer: Treat more floats with empty exponent as valid tokens" rust#131656

Link: https://github.com/rust-lang/rust/pull/131656

TC: There's a lexing change proposed here. There's more context at:

https://github.com/rust-lang/rust/pull/131656#issuecomment-2698831039

What do we think?

"An unsafe const fn being used to compute an array length or const generic is incorrectly described as being an "item"." rust#133441

Link: https://github.com/rust-lang/rust/issues/133441

TC: We're being asked for our take on what contexts should inherit an unsafe { .. }. E.g., should this?:

const unsafe fn f() -> usize { 1 }

fn main() {
    unsafe {
        let _x = [0; f()];
    }
}

What about?:

const unsafe fn f() -> usize { 1 }

fn main() {
    _ = unsafe {
        const {
            f();
        }
    };
}

const unsafe fn f() -> usize { 1 }

fn main() {
    _ = unsafe {
        || {
            f();
        }
    };
}

const unsafe fn f() -> usize { 1 }

fn main() {
    unsafe {
        <[i32; f()]>::default();
    }
}

const unsafe fn f() -> usize { 1 }

fn g<const N: usize>() {}

fn main() {
    unsafe {
        g::<{f()}>();
    }
}

const unsafe fn f() -> usize { 1 }

struct S<const N: usize>;

fn main() {
    unsafe {
        let _x: S<{f()}>;
    }
}

TC: What do we think?

"Stabilize derive(CoercePointee)" rust#133820

Link: https://github.com/rust-lang/rust/pull/133820

TC: Are we ready to stabilize derive(CoercePointee)? Ding proposes that for us.

"experiment with relaxing the orphan rule" rust#136979

Link: https://github.com/rust-lang/rust/issues/136979

TC: In the RfL/lang call on 2025-02-12, there was (again) a request for some way to relax the orphan rule, and they described their use case a bit. We asked them to file an issue about this for a nomination, and there's been some discussion.

TC: What do we think?

"Handling of stdcall (and other x86-32-specific ABIs) on non-x86-32 Windows targets is inconsistent" rust#137018

Link: https://github.com/rust-lang/rust/issues/137018

TC: Ralf and company want to move to only accepting ABIs on targets where they make sense. We need to give a signal here about our happiness with the direction and the plan, and then we can do our FCP on the stabilization as usual.

Start with the comment here:

https://github.com/rust-lang/rust/issues/137018#issuecomment-2851043788

What do we think?

"Remove i128 and u128 from improper_ctypes_definitions" rust#137306

Link: https://github.com/rust-lang/rust/pull/137306

TC: Trevor Gross proposes:

Rust's 128-bit integers have historically been incompatible with C…

At rust-lang/lang-team#255 (comment), the lang team considered it acceptable to remove i128 from improper_ctypes_definitions if the LLVM version is known to be compatible. Time has elapsed since then and we have dropped support for LLVM versions that do not have the x86 fixes, meaning a per-llvm-version lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes only came in LLVM 20 but since Rust's datalayouts have also been updated to match, we will be using the correct alignment regardless of LLVM version.

What do we think?

"Stabilize repr128" rust#138285

Link: https://github.com/rust-lang/rust/pull/138285

TC: This is about allowing:

#[repr(u128)]
enum Foo {
    One = 1,
    Two,
    Big = u128::MAX,
}

I've proposed FCP merge. What do we think?

"Oddity with lifetime elision and type aliases" rust#140611

Link: https://github.com/rust-lang/rust/issues/140611

This behavior isn't documented correctly the Reference, and it's unclear whether it should be or whether we might want to fix it as a language matter:

pub struct W<'a>(&'a ());
pub type Alias<'a> = W<'a>;

impl<'a> Alias<'a> {
    fn f1<'x>(self: &W<'a>, x: &'x ()) -> &() { x } //~ `'_ == 'x`, what?
    fn f2<'x>(self: &Alias<'a>, x: &'x ()) -> &() { x } //~ `'_ == 'x`, what?
    fn f3<'x>(&self, _: &'x ()) -> &() { self.0 } //~ OK.
}

impl<'a> W<'a> {
    fn f4<'x>(self: &W<'a>, _: &'x ()) -> &() { self.0 } //~ OK.
    fn f5<'x>(self: &Alias<'a>, x: &'x ()) -> &() { x } //~ `'_ == 'x`, what?
    fn f6<'x>(&self, _: &'x ()) -> &() { self.0 } //~ OK.
}

Anyone know about this?

"UnsafePinned: also include the effects of UnsafeCell" rust#140638

Link: https://github.com/rust-lang/rust/pull/140638

TC: We don't seem to have much option, given

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

but to allow aliasing an &UnsafePinned<T>, and it follows that &UnsafePinned<T> should probably be a kind of superset of the capabilities of &UnsafeCell<T>.

Sound right? We just need to signal happiness with this direction.

"Confusing error when a const contains a shared ref to interior mutable data" rust#140653

Link: https://github.com/rust-lang/rust/issues/140653

TC: RalfJ raises that we give a bogus error about this code:

use std::sync::atomic::*;
static FOO: AtomicU32 = AtomicU32::new(0);
const C: &'static AtomicU32 = &FOO;

One option is that we could choose to accept this code. If we do, then we must error if this constant is used in a pattern (the error is still pre-mono). The other option is to forbid it, but say more correctly why we are.

What do we think?

"Add core::ptr::assume_moved" rfcs#3700

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

TC: We're being asked for a vibe check on this one. Vibes?

"RFC: Add an attribute for raising the alignment of various items" rfcs#3806

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

TC: Based on our request, and to help us on,

• https://github.com/rust-lang/rust/pull/140261

Jules Bertholet has filed this RFC proposing #[align(..)]. What do we think?

"#[deprecated] lint doesn't trigger when overriding deprecated method" rust#98990

Link: https://github.com/rust-lang/rust/issues/98990

TC: Mara asks about this:

This doesn't give any warnings, even though std::error::Error::description is deprecated:

impl std::error::Error for E {
fn description(&self) -> &str {
":)"
}
}

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?

"sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets" rust#123617

Link: https://github.com/rust-lang/rust/pull/123617

TC: There's a proposed stabilization for sanitizers. It includes a new attribute, currently called #[no_sanitize]. I couldn't immediately find if we had previously discussed this. In discussion, Eric Huss proposed we might want to consider #[sanitize(off)] or similar for parity with what we're doing for #[coverage(off)]. We'd also need to think about whether there might be extensions to allow for e.g. turning off only one of many sanitizers.

TC: What do we think?

"Built-in attributes are treated differently vs prelude attributes, unstable built-in attributes can name-collide with stable macro, and built-in attributes can break back-compat" rust#134963

Link: https://github.com/rust-lang/rust/issues/134963

TC: jieyouxu makes an interesting observation of current behavior at which we should have a look. What do we think?

"Add checking for unnecessary delims in closure body" rust#136906

Link: https://github.com/rust-lang/rust/pull/136906

TC: This is about linting against:

pub fn main() {
    let _ = || (0 == 0);
}

What do we think?

"Unsafe fields" rfcs#3458

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

TC: Nearly ten years ago, on 2014-10-09, pnkfelix proposed unsafe fields in RFC 381:

https://github.com/rust-lang/rfcs/issues/381

On 2017-05-04, Niko commented:

I am pretty strongly in favor of unsafe fields at this point. The only thing that holds me back is some desire to think a bit more about the "unsafe" model more generally.

Then, in 2023, Jacob Pratt refreshed this proposal with RFC 3458. It proposes that:

Fields may be declared unsafe. Unsafe fields may only be mutated (excluding interior mutability) or initialized in an unsafe context. Reading the value of an unsafe field may occur in either safe or unsafe contexts. An unsafe field may be relied upon as a safety invariant in other unsafe code.

E.g.:

struct Foo {
    safe_field: u32,
    /// Safety: Value must be an odd number.
    unsafe unsafe_field: u32,
}

// Unsafe field initialization requires an `unsafe` block.
// Safety: `unsafe_field` is odd.
let mut foo = unsafe {
    Foo {
        safe_field: 0,
        unsafe_field: 1,
    }
};

On 2024-05-21, Niko nominated this for us:

I'd like to nominate this RFC for discussion. I've not read the details of the thread but I think the concept of unsafe fields is something that comes up continuously and some version of it is worth doing.

TC: What do we think?

"RFC: No (opsem) Magic Boxes" rfcs#3712

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

TC: The idea here is to remove the language invariant that a Box must not alias other things (the library invariant would of course remain).

TC: What do we think?

"Tracking Issue: Procedural Macro Diagnostics (RFC 1566)" rust#54140

Link: https://github.com/rust-lang/rust/issues/54140

TC: Spawned off from the original RFC 1566 for proc macros is the question of how to allow proc macros to emit diagnostics.

TC: The feeling on the 2025-01-07 libs-api call, particularly from dtolnay, is that it would be mistake to do this without some way to allow users to suppress these warnings with some specificity. This then seems to call for some kind of namespacing solution, e.g. allow(my_macro::*). As I wrote:

But more broadly, we've been thinking about a number of seemingly-related namespacing concerns, e.g. how to namespace attributes applied to fields for derive macros, the tooling namespace, etc. We may want to think holistically about this, or to encourage designs that fall within whatever direction we take here.

TC: This is nominated just to build context and see if we have any immediate thoughts. Thoughts?

"Tracking Issue for enum access in offset_of" rust#120141

Link: https://github.com/rust-lang/rust/issues/120141

TC: There's a proposed FCP merge for us:

https://github.com/rust-lang/rust/issues/120141#issuecomment-2161507356

TC: What do we think?

"Strengthen the follow-set rule for macros" rust#131025

Link: https://github.com/rust-lang/rust/issues/131025

TC: Over in:

• https://github.com/rust-lang/rust/pull/130635

@compiler-errors describes this general problem:

The breakage specifically represents an inherent limitation to the "macro follow-set" formulation which is supposed to make us more resilient against breakages due to extensions to the grammar like this.

Given two macro matcher arms:

• ($ty:ty) => ...
• (($tt:tt)*) => ...

And given tokens like:

• & pin mut […more tokens may follow…]

On nightly today, &pin gets parsed as a type. However, we run out of matchers but still have tokens left (the mut token is next), so we fall through to the next arm. Since it's written like ($tt:tt)*, everything is allowed, and we match the second arm successfully…

I think that's weird, because if this second arm were written like $ty:ty mut, that would be illegal, since mut is not in the follow-set of the :ty matcher. Thus, we can use :tt matchers to observe whether the compiler actually parses things not in our grammar that should otherwise be protected against, which seems pretty gross.

And @Noratrieb proposes a general solution:

I believe a solution to this would be the following new logic:

• after the end of a macro matcher arm has been reached
• and there are still input tokens remaining
• and if the last part of the matcher is a metavar
• ensure that the first remaining token is in the follow set of this metavar
• if it is, move on to the next arm
• if it is not, emit an error

What this semantically does is strengthen the "commit to fully matching metavars or error" behavior such that it extends past the end. I don't know how many macros rely on this, but it seems like emitting an FCW (instead of error) on such macro invocations would find all these cases and ensure that the follow-set logic is actually robust past the end. But imo this shouldn't block this PR (which should probably just ship as-is) and can be done separately.

About this, NM noted:

I don't think this proposal is sufficient but I am interested in pursuing a real fix to this for a future edition.

Example:

macro_rules! test {
    (if $x:ty { }) => {};
    (if $x:expr { }) => {};
}

This basically says to pick one arm if something is a type, another if it's an expression. Extending the type grammar to cover new cases could change which arm you go down to.

I think the most general fix is to say: when you would start parsing a fragment, first skip ahead to find the extent of it (i.e., until you see an entry from the follow-set). Then parse it as the fragment. If the parsing fails or there are unconsumed tokens, report a hard error.

I suspect it would break a lot in practice and we would need an opt-in.

TC: What do we think?

"Warn about C-style octal literals" rust#131309

Link: https://github.com/rust-lang/rust/pull/131309

TC: The question is about code like:

fn is_executable(unix_mode: u32) -> bool {
    unix_mode & 0111 != 0

TC: Do we want to lint against that?

"RFC: Improved State Machine Codegen" rfcs#3720

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

TC: After a long discussion on Zulip leading to this, folkertdev proposes a way to express intraprocedural finite state machine transitions building on match syntax. There's an draft implementation by bjorn3, and this results in some impressive speedups in zlib-rs.

TC: What's our vibe, and are there any objections to accepting this work from bjorn3 as a lang experiment?

"Effective breakage to jiff due to ambiguous_negative_literals" rust#128287

Link: https://github.com/rust-lang/rust/issues/128287

TC: We have an allow-by-default lint against ambiguous_negative_literals like:

assert_eq!(-1.abs(), -1);

It's allow-by-default because we found use cases such as jiff (by BurntSushi) that have, in their API, operations whose result is invariant to the order of the negation and that rely on this syntax for the intended ergonomics.

Urgau has a proposal for us. He'd like to lint by default, and have an…

#[diagnostic::irrelevant_negative_literal_precedence]

…attribute (of some name), using the diagnostic namespace, that could be applied to function definitions and that would suppress this lint on their callers. Urgau would prefer this be opt-in rather than opt-out so as to bring awareness to this, even though many functions don't affect the sign bit and so will have this invariance.

I've asked BurntSushi for his views on this proposal with respect to jiff, to confirm this would address his use case.

TC: What do we think?

"Simplify lightweight clones, including into closures and async blocks" rfcs#3680

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

TC: Josh nominates a new RFC for us. What do we think?

"Declarative macro_rules! attribute macros" rfcs#3697

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

TC: Josh proposes an RFC for us:

Many crates provide attribute macros. Today, this requires defining proc macros, in a separate crate, typically with several additional dependencies adding substantial compilation time, and typically guarded by a feature that users need to remember to enable.

However, many common cases of attribute macros don't require any more power than an ordinary macro_rules! macro. Supporting these common cases would allow many crates to avoid defining proc macros, reduce dependencies and compilation time, and provide these macros unconditionally without requiring the user to enable a feature.

E.g.:

macro_rules! main {
    attr() ($func:item) => { make_async_main!($func) };
    attr(threads = $threads:literal) ($func:item) => { make_async_main!($threads, $func) };
}

#[main]
async fn main() { ... }

#[main(threads = 42)]
async fn main() { ... }

TC: What do we think?

"Declarative macro_rules! derive macros" rfcs#3698

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

TC: Josh proposes an RFC for us:

Many crates support deriving their traits with derive(Trait). Today, this requires defining proc macros, in a separate crate, typically with several additional dependencies adding substantial compilation time, and typically guarded by a feature that users need to remember to enable.

However, many common cases of derives don't require any more power than an ordinary macro_rules! macro. Supporting these common cases would allow many crates to avoid defining proc macros, reduce dependencies and compilation time, and provide these macros unconditionally without requiring the user to enable a feature.

E.g.:

trait Answer { fn answer(&self) -> u32; }

#[macro_derive]
macro_rules! Answer {
    // Simplified for this example
    (struct $n:ident $_:tt) => {
        impl Answer for $n {
            fn answer(&self) -> u32 { 42 }
        }
    };
}

#[derive(Answer)]
struct Struct;

fn main() {
    let s = Struct;
    assert_eq!(42, s.answer());
}

TC: What do we think?

"Macro fragment fields" rfcs#3714

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

TC: This RFC proposes to allow:

macro_rules! get_name {
    ($t:adt) => { println!("{}", stringify!(${t.name})); }
}

fn main() {
    let n1 = get_name!(struct S { field: u32 });
    let n2 = get_name!(enum E { V1, V2 = 42, V3(u8) });
    let n3 = get_name!(union U { u: u32, f: f32 });
    println!("{n3}{n1}{n2}"); // prints "USE"
}

That is, it lets MBE authors use the Rust parser to pull out certain elements.

TC: What do we think?

"Add homogeneous_try_blocks RFC" rfcs#3721

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

TC: scottmcm proposes for us a tweak to the way that ? works within try { .. } blocks.

TC: What's our vibe?

"Elided lifetime changes in rust_2018_idioms lint is very noisy and results in dramatically degraded APIs for Bevy" rust#131725

Link: https://github.com/rust-lang/rust/issues/131725

TC: Long ago, we set a direction of wanting to move away from eliding lifetimes in paths, e.g.:

#![deny(elided_lifetimes_in_paths)]

struct S<'a>(&'a ());

fn f(x: &()) -> S {
    //          ~
    //~^ ERROR expected lifetime parameter
    S(x)
}

However, that lint is currently allow-by-default. It was part of the rust_2018_idioms lint group (which is also allow-by-default).

We talked about changing this in Rust 2024, but it seems we didn't get around to it.

One of the maintainers of Bevy has now written in to ask us to never change this.

I'd probably highlight:

• The representativeness of the example being challenged.
  • https://github.com/rust-lang/rust/issues/131725#issuecomment-2413272045
• Details about the lint and what would actually be flagged.
  • https://github.com/rust-lang/rust/issues/91639#issuecomment-2413823502

TC: What do we think?

"Coercing &mut to *const should not create a shared reference" rust#56604

Link: https://github.com/rust-lang/rust/issues/56604

TC: It's currently UB to write:

fn main() {
    let x = &mut 0;
    let y: *const i32 = x;
    unsafe { *(y as *mut i32) = 1; }
    assert_eq!(*x, 1);
}

This is due to the fact that we implicitly first create a shared reference when coercing a &mut to a *const. See:

TC: What do we think about this?

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

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

TC: Apparently our unstable likely and unlikely 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.

"is operator for pattern-matching and binding" rfcs#3573

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

TC: Josh proposes for us that we should accept:

if an_option is Some(x) && x > 3 {
    println!("{x}");
}

And:

func(x is Some(y) && y > 3);

TC: The main topic discussed in the issue thread so far has been the degree to which Rust should have "two ways to do things". Probably the more interesting issue is how the binding and drop scopes for this should work.

TC: In the 2024-02-21 meeting (with limited attendance), we discussed how we should prioritize stabilizing let chains, and tmandry suggested we may want to allow those to settle first.

TC: What do we think, as a gut check?

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

"Hierarchy of Sized traits" rfcs#3729

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

TC: We discussed this in our design meeting on 2024-11-13. There's still a steady stream of good revisions and new ideas on the thread happening, so we should probably let this play out awhile longer.

"Language vs. implementation threat models and implications for TypeId collision resistance" rust#129030

Link: https://github.com/rust-lang/rust/issues/129030

TC: We use SipHash-1-3-128 in Rust for hashing types to form TypeIds. If these TypeIds collide in a single program, UB may result.

If SipHash-1-3-128 is a secure PRF, then the probability of such collisions happening accidentally in a program that contains an enormous 1M types is one in 2^-89.

But, if someone wanted to brute-force a collision – that is, find two entirely random types that would have the same TypeId – the work factor for that is no more than about 2^64 on average.

The question being nominated for lang is whether we consider that good enough for soundness, for now.

TC: What do we think?

"RFC: inherent trait implementation" rfcs#2375

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

TC: We had a design meeting on 2023-09-12 about inherent trait impls. In that meeting, I proposed a use syntax for this:

In the discussion above, we had left two major items unresolved.

• How do we make blanket trait impls inherent?
• How can we allow only some items from the trait impl to be made inherent?
  • This is especially tricky for associated functions and methods with a default implementation.

(Part of the motivation for wanting to allow only some items to be made inherent is to prevent or to fix breakage caused when a trait later adds a new method with a default implementation whose name conflicts with the name of an existing inherent method.)

Coming up with a syntax for these that combines well with the #[inherent] attribute could be challenging.

One alternative that would make solving these problems straightforward is to add some syntax to the inherent impl block for the type. Given the desugaring in the RFC, there is some conceptual appeal here. (quaternic proposed this arrangement; TC is proposing the concrete syntax.)

We can use use syntax to make this concise and intuitive.

Here's an example:

trait Trait1<Tag, T> {
    fn method0(&self) -> u8 { 0 }
    fn method1(&self) -> u8 { 1 }
}
trait Trait2<Tag, T> {
    fn method2(&self) -> u8 { 2 }
    fn method3(&self) -> u8 { 3 }
    fn method4(&self) -> u8 { 4 }
}

struct Tag;

struct Foo<T>(T);
impl<T> Foo<T> {
    // All methods and associated items of Trait1 become inherent,
    // except for `method0`.  The inherent items are only visible
    // within this crate.
    pub(crate) use Trait1<Tag, T>::*;
    // Only `method2` and `method3` on Trait2 become inherent.
    pub use Trait2<Tag, T>::{method2, method3};

    fn method0(&self) -> u64 { u64::MAX }
}

impl<T> Trait1<Tag, T> for Foo<T> {}
impl<U: Trait1<Tag, T>, T> Trait2<Tag, T> for U {}

This solves another problem that we discussed above. How do we prevent breakage in downstream crates when a trait later adds a new method with a default implementation? Since a downstream crate might have made an impl of this trait for some local type inherent and might have an inherent method with a conflicting name, this could be breaking.

We already handle this correctly for use declarations with wildcards. Any locally-defined items override an item that would otherwise be brought into scope with a wildcard import. We can reuse that same behavior and intuition here. When a wildcard is used to make all items in the trait inherent, any locally-defined inherent items in the impl prevent those items from the trait with the same name from being made inherent.

Advantages:

• It provides a syntax for adopting as inherent a blanket implementation of a trait for the type.
• It provides a syntax for specifying which methods should become inherent, including methods with default implementations.
• The wildcard import (use Trait::*) makes it very intuitive what exactly is happening and what exactly your API is promising.
• The use syntax makes it natural for a locally-defined item to override an item from the wildcard import because that's exactly how other use declarations work.
• rust-analyzer would probably support expanding a wildcard use Trait::* to an explicit use Trait::{ .. } just as it does for other use declarations, which would help people to avoid breakage.
• We can support any visibility (e.g. use, pub use, pub(crate) use, etc.) for the items made inherent.

Disadvantages:

• There's some redundancy, especially when the items to make inherent are specifically named.

During the meeting, this emerged as the presumptive favorite, and we took on a TODO item to updated the RFC.

After follow-on discussion in Zulip, Niko agreed, and also raised a good question:

Per the discussion on zulip, I have become convinced that it would be better to make this feature use the syntax use, like:

impl SomeType {
    pub use SomeTrait::*;  // re-export the methods for the trait implementation
}

This syntax has a few advantages:

• We can give preference to explicit method declared in the impl blocks over glob re-exports, eliminating one source of breakage (i.e., trait adds a method with a name that overlaps one of the inherent methods defined on SomeType)
• Can make just specific methods (not all of them) inherent.
• Easier to see the inherent method when scanning source.
• You can re-export with different visibility levels (e.g., pub(crate))
• It would work best if we planned to permit use SomeTrait::some_method; as a way to import methods as standalone fns, but I wish we did that.

However, in writing this, I realize an obvious disadvantage – if the trait has more generics and things, it's not obvious how those should map. i.e., consider

struct MyType<T> {
}

impl<T> MyType<T> {
    pub use MyTrait::foo;
}

impl<T: Debug> MyTrait for MyType<T> {
    fn foo(&self) { }
}

This would be weird – is this an error, because the impl block says it's for all T? And what if it were trait MyTRait<X>?

TC: My sense is that we've just been awaiting someone digging in and updating the RFC here.

"Raw Keywords" rfcs#3098

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

TC: We've at various times discussed that we had earlier decided that if we wanted to use a new keyword within an edition, we would write it as k#keyword, and for that reason, we prefer to not speculatively reserve keywords ahead of an edition (except, perhaps, when it's clear we plan to use it in the near future).

TC: Somewhat amusingly, however, we never in fact accepted that RFC. Back in 2021, we accepted scottmcm's proposal to cancel:

We discussed this RFC again in the lang team triage meeting today.

For the short-term goal of the reservation for the edition, we'll be moving forward on #3101 instead. As such, we wanted to leave more time for conversations about this one, and maybe use crater results from 3101 to make design changes,

@rfcbot cancel

Instead we accepted RFC 3101 that reserved ident#foo, ident"foo", ident'f', and ident#123 starting in the 2023 edition.

Reading through the history, here's what I see:

• What do we want to do about Rust 2015 and Rust 2018? It's a breaking change to add this there. Is this OK? Do we want to do a crater run on this?
• Would we have the stomach to actually do this? It's one thing to say that if we wanted to use a new keyword within an edition, we'd write k#keyword, but it's another to actually do it in the face of certain criticism about that being e.g. unergonomic. Would we follow through?

TC: What do we think?

"RFC: Implementable trait aliases" rfcs#3437

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

TC: We discussed this in the lang planning meeting in June, and it looks like there have been updates since we last looked at this, so it's time for us to have another look since we seemed interested in this happening.

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.

Making a celebrity appearance, Rich Felker, the author of MUSL libc, notes:

As long as Rust is changing signal dispositions inside init code in a way that the application cannot suppress or undo, it is fundamentally unusable to implement standard unix utilities that run child processes or anything that needs to preserve the signal dispositions it was invoked with and pass them on to children. Changing inheritable process state behind the application's back is just unbelievably bad behavior and does not belong in a language runtime for a serious language…

As an example, if you implement find in Rust, the -exec option will invoke its commands with SIGPIPE set to SIG_IGN, so that they will not properly terminate on broken pipe. But if you just made it set SIGPIPE to SIG_DFL before invoking the commands, now it would be broken in the case where the invoking user intentionally set SIGPIPE to SIG_IGN so that the commands would not die on broken pipe.

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

Are we interested in fixing it over this one?

Strawman (horrible) proposal: We could stop making this pre-main syscall in Rust 2024 and have cargo fix insert this syscall at the start of every main function.

(In partial defense of the strawman, it gets us directly to the arguably best end result while having an automatic semantics-preserving edition migration and it avoids the concerns about lang/libs coupling that Mara raised. The edition migration could add a comment above this inserted code telling people under what circumstances they should either keep or delete the added line.)

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

"Trait method impl restrictions" rfcs#3678

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

TC: This RFC is pending further work that's probably on me at this point.

"Implement PartialOrd and Ord for Discriminant" rust#106418

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

TC: We discussed this last in the meeting on 2024-03-13. scottmcm has now raised on concern on the issue and is planning to make a counter-proposal:

I remain concerned about exposing this with no opt-out on an unrestricted generic type @rfcbot concern overly-broad

I'm committing to making an alternative proposal because I shouldn't block without one. Please hold my feet to the fire if that's no up in a week.

Basically, I have an idea for how we might be able to do this, from #106418 (comment)

2. Expose the variant ordering privately, only accessible by the type owner/module.

Solution 2. is obviously more desirable, but AFAIK Rust can't do that and there is no proposal to add a feature like that.

https://github.com/rust-lang/rust/pull/106418#issuecomment-1994833151

"Fallout from expansion of redundant import checking" rust#121708

Link: https://github.com/rust-lang/rust/issues/121708

TC: We discussed this in the meeting on 2024-03-13. The feelings expressed included:

• We don't want to create a perverse incentive for people to expand existing lints rather than to create new ones where appropriate just because there's less process for expanding the meaning of an existing lint.
• It would be good if potentially-disruptive expansions of an existing lint either:
  • Had a machine-applicable fix.
  • Or had a new name.
• We don't want to require a new lint name for each expansion.
• We don't want to require a crater run for each change to a lint.
• There are two ways to prevent disruption worth exploring:
  • Prevent potentially-disruptive changes from hitting master.
  • Respond quickly to early indications of disruption once the changes hit master.
• Compiler maintainers have a sense of what might be disruptive and are cautious to avoid it. It may be OK to have a policy that is not perfectly measurable.

TC: tmandry volunteered to draft a policy proposal.

"What are the guarantees around which constants (and callees) in a function get monomorphized?" rust#122301

Link: https://github.com/rust-lang/rust/issues/122301

TC: The8472 asks whether this code, which compiles today, can be relied upon:

const fn panic<T>() {
    struct W<T>(T);
    impl<T> W<T> {
        const C: () = panic!();
    }
    W::<T>::C
}

struct Invoke<T, const N: usize>(T);

impl<T, const N: usize> Invoke<T, N> {
    const C: () = match N {
        0 => (),
        // Not called for `N == 0`, so not monomorphized.
        _ => panic::<T>(),
    };
}

fn main() {
    let _x = Invoke::<(), 0>::C;
}

The8472 notes that this is a useful property and that there are use cases for this in the compiler and the standard library, at least unless or until we adopt something like const if:

https://github.com/rust-lang/rfcs/issues/3582

RalfJ has pointed out to The8472 that the current behavior might not be intentional and notes:

It's not opt-dependent, but it's also unclear how we want to resolve the opt-dependent issue. Some proposals involve also walking all items "mentioned" in a const. That would be in direct conflict with your goal here I think. To be clear I think that's a weakness of those proposals. But if that turns out to be the only viable strategy then we'll have to decide what we want more: using const tricks to control what gets monomorphized, or not having optimization-dependent errors.

One crucial part of this construction is that everything involved is generic. If somewhere in the two "branches" you end up calling a monomorphic function, then that may have its constants evaluated even if it is in the "dead" branch – or it may not, it depends on which functions are deemed cross-crate-inlinable. That's basically what #122814 is about.

TC: The question to us is whether we want to guarantee this behavior. What do we think?

"Policy for lint expansions" rust#122759

Link: https://github.com/rust-lang/rust/issues/122759

TC: In the call on 2024-03-13, we discussed this issue raised by tmandry:

"Fallout from expansion of redundant import checking"

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

During the call, the thoughts expressed included:

• We don't want to create a perverse incentive for people to expand existing lints rather than to create new ones where appropriate just because there's less process for expanding the meaning of an existing lint.
• It would be good if potentially-disruptive expansions of an existing lint either:
  • Had a machine-applicable fix.
  • Or had a new name.
• We don't want to require a new lint name for each expansion.
• We don't want to require a crater run for each change to a lint.
• There are two ways to prevent disruption worth exploring:
  • Prevent potentially-disruptive changes from hitting master.
  • Respond quickly to early indications of disruption once the changes hit master.
• Compiler maintainers have a sense of what might be disruptive and are cautious to avoid it. It may be OK to have a policy that is not perfectly measurable.

TC: tmandry volunteered to draft a policy proposal. He's now written up this proposal in this issue.

TC: What do we think?

"Decide on path forward for attributes on expressions" rust#127436

Link: https://github.com/rust-lang/rust/issues/127436

TC: We decided recently to unblock progress on attributes on expressions (RFC 16) by allowing attributes on blocks. We have a proposed FCP to this effect.

After we did this, the question came up what we want to do about attributes in list contexts, e.g.:

call(#[foo] { block1 }, #[bar] { block2 })

…in particular, macro attributes.

Petrochenkov says:

It needs to be decided how proc macros see the commas, or other separators in similar cases.

Ideally proc macros should be able to turn 1 expression into multiple (including 0) expressions in this position, similarly to cfgs or macros in list contexts without separators. So it would be reasonable if the separators were included into both input and output tokens streams (there are probably other alternatives, but they do not fit into the token-based model as well). The "reparse context" bit from #61733 (comment) is likely relevant to this case as well.

We filed a concern to figure this all out.

We discussed this on 2024-07-24 and came up with these options:

Options ordered from least to most conservative (and then from most to least expressive):

• Option A: Punt this case and don't support attributes in this position without parens (e.g. call((#[attr] arg), (#[attr] arg2)))
• Option B (exactly one): Specify that, for now, if you use a macro attribute on an expression, that macro can only expand to a single expresion (not zero tokens, and no tokens following in the output).
• Option C (zero or one): Specify that, for now, if you use a macro attribute on an expression, that macro can only expand to zero tokens or an expression with nothing following (extra tokens, including ,, are an error for now)
• Option D (zero or more): Specify that an attribute in this position can expand to tokens that may include a ,, and that if they expand to zero tokens then we elide the comma.
• Option E (flexible): include comma, let macro decide, etc
  • We find it surprising that comma would be included.

In discussion, we seemed generally interested in allowing at least zero and 1. We weren't sure about N, and we weren't sure about the handling of the comma in the input.

TC: What do we think?

"Tracking Issue for breakpoint feature (core::arch::breakpoint)" rust#133724

Link: https://github.com/rust-lang/rust/issues/133724

TC: Generally we lang FCP the first stable use of an intrinsic. This is an intrinsic, and this is the first stable use. At the same time, as we discussed in the libs-api meeting, perhaps what we're meaning to lang FCP are new capabilities of the language, and this one could be seen as equivalent to some inline assembly. So I don't know. It's worth us having a look in any case. What do we think?

"Stabilize keylocker" rust#140766

Link: https://github.com/rust-lang/rust/pull/140766

TC: This stabilizes two target features related to Intel's "keylocker" feature that helps to minimize the time that cryptographic key are in memory. The target feature names match those used by LLVM and GCC. There don't seem to be nontrivial ABI considerations. RalfJ has seen the issue. This all seems OK to me, and I've proposed FCP merge. What do we think?

"RFC: Allow type inference for const or static" rfcs#3546

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

"RFC: Unsafe Set Enum Discriminants" rfcs#3727

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

"RFC: naming groups of configuration with cfg_alias" rfcs#3804

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

"Decide what we want about macro_metavar_expr" rust#137581

Link: https://github.com/rust-lang/rust/issues/137581

"Original pin!() macro behavior cannot be expressed in Rust 2024" rust#138718

Link: https://github.com/rust-lang/rust/issues/138718

"Allow while let chains on all editions" rust#140204

Link: https://github.com/rust-lang/rust/pull/140204

"Lang proposal: Allow #[cfg(...)] within asm!" rust#140279

Link: https://github.com/rust-lang/rust/issues/140279

Action item review

• Action items list

Pending lang team project proposals

None.

PRs on the lang-team repo

"Frequently requested changes: add bypassing visibility" lang-team#323

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

"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

"Update hackmd link to a public link" lang-team#258

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

"Adding a link to "how to add a feature gate" in the experimenting how-to" lang-team#267

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

"text describing how other teams are enabled to make decisions." lang-team#290

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

"Fix link to agenda template" lang-team#315

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

"new decision process" lang-team#326

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

"Clarify that taking input in coroutines currently uses 'yield expressions'" lang-team#328

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

RFCs waiting to be merged

None.

S-waiting-on-team

"Fallback {float} to f32 when f32: From<{float}> and add impl From<f16> for f32" rust#139087

Link: https://github.com/rust-lang/rust/pull/139087

"Split elided_lifetime_in_paths into tied and untied" rust#120808

Link: https://github.com/rust-lang/rust/pull/120808

"const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns" rust#140942

Link: https://github.com/rust-lang/rust/pull/140942

"lexer: Treat more floats with empty exponent as valid tokens" rust#131656

Link: https://github.com/rust-lang/rust/pull/131656

"Remove unstable cfg target(...) compact feature" rust#130780

Link: https://github.com/rust-lang/rust/pull/130780

"Lint on fn pointers comparisons in external macros" rust#134536

Link: https://github.com/rust-lang/rust/pull/134536

"Permit duplicate macro imports" rust#141043

Link: https://github.com/rust-lang/rust/pull/141043

"repr(tag = ...) for type aliases" rfcs#3659

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

"Add lint against (some) interior mutable consts" rust#132146

Link: https://github.com/rust-lang/rust/pull/132146

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

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

"Permissions" rfcs#3380

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

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

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

"Tracking Issue for bare_link_kind" rust#132061

Link: https://github.com/rust-lang/rust/issues/132061

"Add compiler support for namespaced crates" rust#140271

Link: https://github.com/rust-lang/rust/pull/140271

Proposed FCPs

Check your boxes!

"Fallback {float} to f32 when f32: From<{float}> and add impl From<f16> for f32" rust#139087

Link: https://github.com/rust-lang/rust/pull/139087

"Document representation of Option<unsafe fn()>" rust#141447

Link: https://github.com/rust-lang/rust/pull/141447

"Arbitrary self types v2: stabilize" rust#135881

Link: https://github.com/rust-lang/rust/pull/135881

"Stabilize return type notation (RFC 3654)" rust#138424

Link: https://github.com/rust-lang/rust/pull/138424

"const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns" rust#140942

Link: https://github.com/rust-lang/rust/pull/140942

"Stabilize if let guards (feature(if_let_guard))" rust#141295

Link: https://github.com/rust-lang/rust/pull/141295

"Stabilize feature(generic_arg_infer)" rust#141610

Link: https://github.com/rust-lang/rust/pull/141610

"Make the dangerous_implicit_autorefs lint deny-by-default" rust#141661

Link: https://github.com/rust-lang/rust/pull/141661

"core::marker::NoCell in bounds (previously known an Freeze)" rfcs#3633

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

"Unsafe derives and attributes" rfcs#3715

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

"Stabilize derive(CoercePointee)" rust#133820

Link: https://github.com/rust-lang/rust/pull/133820

"RFC: Add an attribute for raising the alignment of various items" rfcs#3806

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

"sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets" rust#123617

Link: https://github.com/rust-lang/rust/pull/123617

"Remove unstable cfg target(...) compact feature" rust#130780

Link: https://github.com/rust-lang/rust/pull/130780

"Lint on fn pointers comparisons in external macros" rust#134536

Link: https://github.com/rust-lang/rust/pull/134536

"Add checking for unnecessary delims in closure body" rust#136906

Link: https://github.com/rust-lang/rust/pull/136906

"Permit duplicate macro imports" rust#141043

Link: https://github.com/rust-lang/rust/pull/141043

"RFC: No (opsem) Magic Boxes" rfcs#3712

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

"Warn about C-style octal literals" rust#131309

Link: https://github.com/rust-lang/rust/pull/131309

"Specify the behavior of file!" rust#134442

Link: https://github.com/rust-lang/rust/pull/134442

"Declarative macro_rules! attribute macros" rfcs#3697

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

"Declarative macro_rules! derive macros" rfcs#3698

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

"Closing issues relevant to T-lang on this repo" rfcs#3756

Link: https://github.com/rust-lang/rfcs/issues/3756

"[RFC] externally implementable functions" rfcs#3632

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

"Implement PartialOrd and Ord for Discriminant" rust#106418

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

"Policy for lint expansions" rust#122759

Link: https://github.com/rust-lang/rust/issues/122759

"Decide on path forward for attributes on expressions" rust#127436

Link: https://github.com/rust-lang/rust/issues/127436

"RFC: Allow type inference for const or static" rfcs#3546

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

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

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

"Allow while let chains on all editions" rust#140204

Link: https://github.com/rust-lang/rust/pull/140204

"Allow volatile access to non-Rust memory, including address 0" rust#141260

Link: https://github.com/rust-lang/rust/pull/141260

"new decision process" lang-team#326

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

Active FCPs

"Tracking Issue for breakpoint feature (core::arch::breakpoint)" rust#133724

Link: https://github.com/rust-lang/rust/issues/133724

"Stabilize keylocker" rust#140766

Link: https://github.com/rust-lang/rust/pull/140766

"Stabilize sha512. sm3 and sm4 for x86" rust#140767

Link: https://github.com/rust-lang/rust/pull/140767

"terminology: allocated object → allocation" rust#141224

Link: https://github.com/rust-lang/rust/pull/141224

P-critical issues

None.