T-lang meeting agenda

Meeting date: 2025-03-26

Attendance

People: TC, nikomatsakis, Josh, tmandry, eholk, Santiago, Thibault Martin

Meeting roles

Minutes, driver: TC

Scheduled meetings

2025-03-26: "Design meeting: Pending stabilizations" #318
2025-04-02: "Design meeting: Deep dives" #319
2025-04-09: "Design meeting: Deep dives" #320
2025-04-16: "Design meeting: Deep dives" #321
2025-04-23: "Design meeting: Interop, part 2" #316
2025-04-30: "Design meeting: "Marker effects"" #317

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.

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-03-26 to review the status of RfL project goals.

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

Rust 2025 review

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

Nominated RFCs, PRs, and issues

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

TC: One of the things raised here is allowing the casts within an unsafe block.

NM: It'd be a new precedent to change behavior within an unsafe block.

TC: It's not really changing behavior, though, it's just allowing more things.

NM: That's true.

TC: Part of why I probably hate this less than others in the thread is that I tend to see pointer casts followed by a dereference as being identical to transmute.

NM: In fact, that's what I always do.

TC: Same. So in that light, I kind of want to preserve the parity between the two. So we could see allowing these pointer casts within unsafe as preserving the power of pointer casts that we'd expect.

NM: With that framing, it doesn't seem so bad to me. The inference effects here are just kind of an artifact of our implementation. We could see this as just allowing more things in unsafe.

JT: Is the code that this would break actually sound?

NM: It's not unsound, it sounds like the bigger concern is teachability. Saethlin's comment is worth reading.

cramertj: We have precedent for allowing more within unsafe with the same syntax in that we allow using * for pointer deref in unsafe blocks.

NM: Agreed, it originally felt different to me, but I think that was basically familiarity bias. When I step back from details of the compiler impl, it is basically a subsetting – there are two cases, as casts that respect lifetimes, and as casts that don't, and the latter is only available in unsafe blocks. That said I still think my preference is that we push people to transmute in terms of teachability and simplicity.

tmandry: it still seems to me like a bit of a hazard that you can just change it in unsafe. Pointer casts feel different to me because you usually know what's going on, but the as cast is subtle, you may not realize you are changing something.

cramertj: I find all as casts sort of suspect even in safe code.

NM: I agree that as casts are suspect but I also agree with Tyler's point that you may form intuitions based on the behavior of as in safe code (it will enforce this rule) and then be surprised to find it behaves differently in an unsafe context.

Josh: This would allow not just changing a lifetime that's visible in the type name itself; it allows casting a dyn trait to a dyn trait where the lifetime is embedded in the trait somewhere.

TC: I'd prefer maintaining the invariant that that pointer casts followed by a deref can do everything that a transmute can do (and more). It's awkward if pointer casts are more powerful than transmute (of objects) in some ways but then transmute (of objects) is more powerful in other ways.

NM: I mean, transmutes are strictly more powerful than pointer casts in that you can transmute a pointer. I think we should go forward as planned; I think the question is whether to do unsafe as a transitional step, but the breakage seems not so bad so I think I would rather rip off the bandaid.

TC: Agreed on going forward as planned. If we were to allow this in unsafe, which we could do at any time, I'd rather do it as an intended direction rather than as a transitional step.

JT: Is metrics actively maintained?

NM: Yes, the author has engaged on the thread, and it's interesting to read the thread, it seems like it helped them to understand what's going on.

Josh: The impact is measured by the number of regressions and the noise that each produces. One of the regressions here is a six-year-old version of diesel, and that could be noisy.

tmandry: We have editions. We could just do this in Rust 2025 and beyond.

NM: We are moving to annual editions. We could use that as more of a tool here.

TC: As much as I like editions, there is cost to divergence between editions, and we could just use lints here. We could allow this in unsafe and then add lints to warn on the things we think are dangerous.

NM: Something I didn't appreciate. Almost all of these have the form:

output as *const dyn Write as *mut dyn Write,

The way our rules work, this becomes:

output as *const (dyn Write + 'static) as *mut (dyn Write + 'static)

    pub fn vm_loop(&mut self, input: &mut dyn Read, output: &mut dyn Write) {
        let program = self.program.as_function();

        let mut out_wrapper = WriteWrapper {
-            write: output as *const dyn Write as *mut dyn Write,
+            write: unsafe {
+                std::mem::transmute::<*mut (dyn Write + '_), *mut (dyn Write + 'static)>(output)
+            },
        };

        let mut in_wrapper = ReadWrapper {
-            read: input as *const dyn Read as *mut dyn Read,
+            read: unsafe {
+                std::mem::transmute::<*mut (dyn Read + '_), *mut (dyn Read + 'static)>(input)
+            },
        };

Conceivably we might say, you have to write it as:

output as *const (dyn Write + 'static) as *mut (dyn Write + 'static)

TC: My proposal:

In an unsafe block, lifetime constraints are relaxed.
But we lint if you have elided lifetime bounds of this kind and we request explicit lifetimes. This could be machine-applicable.
We call it a day.

JT: I think I still prefer to fix this so you can't do it, but I think next best is a deny-by-default lint "this is really hazardous". E.g. cast_changing_elided_lifetime.

TC: Using the rule scottmcm always brings up, are we cleaning up the lang definition by making it a hard error? I don't think we are. It's easier to allow it in unsafe code.

tmandry: Don't agree it makes it cleaner per se, we still have to allow it in unsafe code only.

tmandry: My preferred option is to allow it in unsafe code now but disallow it over an edition.

NM: I think going with TC's proposal makes sense, and I think we can always change behavior in future edition.

JT: Right. We can e.g. make the lint a hard error or we can also make it a hard error even WITH explicit lifetimes and require a transmute.

If we have decided we don't want to change this in the current edition, to avoid breakage in metrics and others, then every other proposed path benefits from a lint.

tmandry: I think we should have the lint, allow the cast in unsafe in existing editions, and I still would like to clean it up so we can say "as casts work the same in safe/unsafe over an edition", but I agree we can do it later.

NM: I think I agree, but will we ever talk about this again? It IS a footgun.

TC: Don't we lint against our footguns?

NM: Good point, the footgun argument goes away.

JT: Do we have consensus to add the lint contemporaneously with the change?

JT: Do we have consensus to make the lint deny-by-default?

NM: TC convinced me the footgun argument doesn't apply. I don't feel strongly about the edition thing anymore.

JT: If we force the lifetimes to be explicitly written, do we still need to change the behavior to require unsafe? Is it possible to achieve unsoundness with purely safe code, or do you need an unsafe block to dereference the raw pointer?

TC: The reason we are disallow them is the "library soundness" argument. That's why we wanted a hard error outside of the unsafe blocks.

NM: We seem to have enough consensus around the core of TC's proposal; it's really a question of whether to go further in next edition. I propose we post that to the thread and get feedback.

NM to write down the "jurisprudence" of "break only as a last resort" (second to "sound is not negotiable"), also "lint away your footguns".

soundness is not negotiable
break only as a last resort
lint away your footguns

and what we're still arguing about is where the line between "editions are meant to be adopted" and "limiting overall complexity" falls. Which I think hinges a bit on how much of a wart you see the pointer cast behavior as (TC I think doesn't see it as much of a wart).

tmandry: I'll write it up on the issue.

TC: I'd suggest mentioning in particular the bit of context about seeing pointer casts as a kind of transmute and wanting to preserve that parity. That framing shifted our own views; it may affect the views of those on the thread.

NM: The point that really moved me was seeing this as two kinds of pointer casts (lifetime preserving vs transmuting) and how the first is safe and the second is not, and that is just like any other unsafe. It seems like your point tmandry is that this distinction is subtle and hard for users to understand.

(The first part of the meeting ended here.)

(The second part of the meeting started here.)

People: TC, nikomatsakis, Josh, scottmcm, tmandry, eholk

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

Josh: Minor nit: full support for removing the async_fn_in_trait lint, want to confirm that the manner of this removal will not break any code naming that lint (e.g. forbid(async_fn_in_trait) it).

scottmcm: There's a "removed lints" list, so as long as it gets added to that list then it's not breaking to mention it. [delay here] Aha, found it in the PR:

https://github.com/rust-lang/rust/pull/138424/files#diff-cfb1d20a5949dd50b9769edb62eaf10a0de66734637fe71d35bdcf8fb06d767bR604-R608

Josh:

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

, then it's not worth bringing up, I'm sure that's how it'll be handled.

tmandry: Looking at this part:

RTN cannot be used to bound the output futures from calling AsyncFn* traits yet. This requires some design work

What's missing there?

NM: Just syntax for it.

Josh: Where it says:

RTN is not allowed as a free-standing type. This means that it cannot be used in ADTs (structs/enums/unions), parameters, let statements, or turbofishes.

That's just a limitation for now, not a commitment to not doing it in the future, right?

tmandry: Right. It might require another RFC, but not a big one.

TC: Yes, many of us want to see RTN everywhere.

TC: OK, this is now in FCP.

"Stabilize `cfg_boolean_literals`" rust#138632

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

TC: The stabilization is up for cfg(true) and cfg(false). What do we think?

TC: This RFC set a land speed record for us. We now have the stabilization up. There's one concern I filed, based on our triage discussion, that they're working to resolve – there's a compiler MCP that's part of fixing that. We have three checkboxes, but it's always good to have five, so let's have a look.

TC: We have five checkboxes now. It'll go into FCP when we resolve the concern.

"Stabilize `naked_functions`" rust#134213

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

TC: We have some items to discuss on the stabilization of naked_functions.

tmandry: What's the meaning of noreturn here?

TC: It just means you can't fall through the asm code.

tmandry/Josh: That's pretty confusingly named.

TC: Agreed.

tmandry: The naked_asm! wasn't part of the RFC. What does this do?

TC: It's a cut-down asm! that just allows the things that make sense in a #[naked] function.

TC: OK, those were all concerns resolved. There are two things for us to discuss.

TC: One, do we want to allow the "Rust" ABI? There's no way to use this without leaning on details of our ABI that we don't intend to guarantee.

Josh: Agree with the concern. If we don't have a good use case for this, we shouldn't allow it.

scottmcm: One reason I don't think we need to allow it with deny-by-default is that our ABI is almost like the "C" ABI, so you could use that and it'd be mostly fine.

TC: The other thing we could do is to carve it off into a separate feature gate. Then someone who really needs this could use nightly, which feels fine.

TC: OK, our consensus is to carve this one out and not stabilize the "Rust" ABI for naked functions at this time.

scottmcm: Probably carve out all "rustic" ABIs https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.ExternAbi.html#method.is_rustic_abi, not that the others are stable ever (yet).

TC: Second item. After this RFC was accepted, we later stabilized unsafe attributes. Should #[naked] be an unsafe attribute?

On the one hand, what could be more unsafe than removing the prelude from a function?

On the other, we could say that when you apply this attribute to the function, you're required to put a naked_asm! in the body, and that has to wrapped with unsafe.

There are three options I see:

What's here now. No unsafe attribute, unsafe in the body.
Make the attribute unsafe, still require unsafe in the body.
Make the attribute unsafe, consider it already discharged in the body based on the unsafe attribute.

tmandry: I think each unsafe keyword has a scope associated with it and the one in the attribute doesn't apply to the body. I'm in favor of making the attribute unsafe assuming it means you have to prove something that the compiler doesn't already prove for you. Not sure it does.

scottmcm: I'm torn here. In a sense, the naked attribute is safe because the compiler is enforcing that there must be unsafe within the body.

TC: I'm thinking a bit in the headspace here of unsafe extern. There, we refined more carefully where the unsafe obligation should be discharged. This isn't as compelling as that, but it's part of this same sharpening.

NM: I like putting the unsafe on naked and leaving it there. Putting it in either place could make sense, but putting it in both places doesn't. Avoiding the rightward drift feels better to me.

TC: Agreed about not putting it in both places.

tmandry: In alignment with what scottmcm was saying, I'm leaning in the direction of the attribute being safe.

scottmcm: I'm thinking here about the safety comment that I would write. If I wrote the safety comment on the attribute, and all it ever said was "this is OK because of what I do in the unsafe in the function body", that doesn't feel great.

scottmcm: If the problem is rightward drift here, we could allow unsafe naked_asm! { .. }.

TC: One of the things that raised this for me was just the visual dissonance since these functions tend to have other unsafe attributes such as no_mangle.

#[unsafe(no_mangle)]
#[naked]
fn f() {
    unsafe {
        naked_asm! {
            ..
        }
    }
}

TC: Here's maybe the strongest argument. It's about the scope of unsafety. What we really want to express is this:

unsafe {
    #[naked]
    fn f() {
        naked_asm! {
            ..
        }
    }
}

That is, we're discharging an unsafe obligation covering that entire scope. That's what we'd be getting at with this:

#[unsafe(naked)]
fn f() {
    naked_asm! {
        ..
    }
}

And we'd be setting the precedent that it does cover the entire function body there.

With normal asm!, most of what you have to uphold is its interaction with other things that happen within the function body. But here, there's nothing else in the function body, and most of what you're having to uphold are the obligations related to how the interacts with the rest of the program due to the special nature of naked.

NM: What we're asserting here is that the body of this function corresponds with its signature, which includes that it doesn't do UB. While it is a bit odd that it covers the fn body it seems overall more ergonomic; right-aligns with other attributes; etc.

tmandry: I'm OK either way. We've lost scottmcm, but it seems like we have a consensus here.

TC: Josh, work for you also?

Josh: Works for me.

TC: OK, I'll reply on thread with the two answers. One is that we're going to carve out and not stabilize at this time naked with the "Rust" ABI, and the other is that we'll put the unsafe on the attribute and not in the function body.

"[RFC] `core::marker::Freeze` in bounds" rfcs#3633

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

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

TC: For me, I think of this as an operation and want it to rhyme with Copy.

tmandry: What's the operation here?

TC: It's this:

trait Freeze {
	fn freeze(&self) -> &frozen Self {
		// Compiler implemented.
	}
}

scottmcm: I wish we could flip the polarity on this, but that's probably too far away. From what I've been hearing recently, I like the structural framing. But maybe I'm poisoned by the LLVM framing.

NM: Probably I'm leaning more that direction as well.

tmandry: Probably I'm leaning toward NoCell as well on the basis that it's a property of the struture of the type and I don't like the action framing. I'm not sure it's the same as JS freeze.

scottmcm: We have the StructuralPartialEq trait also, which is shallow in this same way. Dunno if there's a useful parallel with how this is also "structurally no cells (shallowly)".

TC: OK. I'm happy with NoCell also. So we'll do NoCell then. And then we'll do PhantomCell correspondingly.

TC: Credit to Josh for coming up with this great name. As soon as I saw it, I knew it was better than everything that had been proposed before other than Freeze. Now we know it's better than Freeze also.

(The meeting ended here.)

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

"Partially stabilize LoongArch target features" rust#135015

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

TC: The proposal here is that we stabilize some target features for LoongArch. What do we think?

"stabilize ptr::swap_nonoverlapping in const" rust#137280

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

TC: Over in the tracking issue, we gave our good vibes for this and asked for a stabilization PR to FCP. This is that.

What do we think?

"Stabilize the avx512 target features" rust#138940

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

TC: Amanieu nominates for us:

This stabilizes the AVX512 target features which is a per-requisite for stabilizing the AVX-512 intrinsics tracked in #111137.

What do we think?

"Define raw pointer transmute behavior" reference#1661

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

TC: To satisfy a use-case in the zerocopy library, jostif proposes the following should be true:

For any *const T / *mut T to *const U / *mut U cast which is well-defined as described in this section, core::mem::transmute<*const T, *const U> / core::mem::transmute<*mut T, *mut U> has the same behavior as the corresponding cast.

RalfJ has commented that exact thing can't quite be true, but similar things probably could be.

TC: What do we think?

"type privacy: Check constructor types in tuple struct patterns" rust#138458

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

TC: Petrochenkov proposes that m::TupleStruct(..) in pattern position should be an error when the type of one of its fields isn't publicly visible at the use site. We discussed and weren't convinced. There's been more discussion. 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?

"Allow numeric tokens containing 'e' that aren't exponents be passed to proc macros" rust#111615

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

TC: Josh nominates this for us and proposes that it's an easy call. There's some back and forth with dtolnay that's worth reading.

TC: What do we think?

"Implement a lint for implicit autoref of raw pointer dereference - take 2" rust#123239

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

TC: Urgau has a lint for us to catch cases like this:

pub struct Test {
    data: [u8],
}

pub fn test_len(t: *const Test) -> usize {
    unsafe { (*t).data.len() }  // this calls <[T]>::len(&self)
}

This is more limited than a previous attempt and implements an algorithm for it suggested by JakobDegen.

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

"de-stabilize bench attribute" rust#134273

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

TC: RalfJ wants to destabilize the #[bench] attribute. What do we think?

"aarch64-softfloat: forbid enabling the neon target feature" rust#135160

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

TC: RalfJ proposes:

This fixes #134375 in a rather crude way, by making the example not build any more on aarch64-unknown-none-softfloat. That is a breaking change since the "neon" aarch64 target feature is stable, but this is justified as a soundness fix. Note that it's not "neon" which is problematic but "fp-armv8"; however, the two are tied together by rustc.

More work on the LLVM side will be needed before we can let people use neon without impacting the ABI of float values (and, in particular, the ABI used by automatically inserted calls to libm functions, e.g. for int-to-float casts, which rustc has no control over).

Nominating for @rust-lang/lang since it is a breaking change. As-is this PR doesn't have a warning cycle; the hope is that the aarch64-unknown-none-softfloat target is sufficiently niche that there's no huge fallout and we can easily revert if it causes trouble. A warning cycle could be added but would need some dedicated rather hacky check in the target_feature attribute handling logic.

TC: What do we think?

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

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

"Guarantee behavior of transmuting Option::<T>::None subject to NPO" rust#137323

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

TC: joshif writes:

In https://github.com/rust-lang/rust/pull/115333, we added a guarantee that transmuting from [0u8; N] to Option<P> is sound where P is a pointer type subject to the null pointer optimization (NPO). It would be useful to be able to guarantee the inverse - that a None::<P> value can be transmutes to an array and that will yield [0u8; N].

TC: RalfJ seems to be on board. 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?

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

"Stabilize let chains in the 2024 edition" rust#132833

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

TC: We have before us now a proposal, long awaited, to stabilize let chains starting in Rust 2024. E.g.:

fn f(x: Option<String>) {
    if let Some(x) = x
        && x.is_ascii()
    {
        println!("{x}");
    }
}

TC: When we last talked about this, we had questions about the drop order.

I've now put together an extensive set of tests to demonstrate what this is, and what the drop order of other related things are, and how this all changes across editions. It's here:

https://github.com/rust-lang/rust/pull/133605

Have a look. The way to read this is that:

e.mark(1) means to log 1 immediately.
e.ok(1) means to return an Ok(_) value and log 1 when it drops.
e.err(1) means to return an Err(_) value and log 1 when it drops.

The tests then assert that the events happened in ascending order.

There are some thought-provoking things in here.

My takeaway, as it pertains to let chains, is that the behavior is mostly consistent with the comparable nested if let encoding, and so the question is whether that's what we want or, e.g., whether we want it to work more like a comparable chain using let else. I can think of reasons we might want that.

TC: What do we think?

"Specify the behavior of `file!`" rust#134442

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

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

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

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

"[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's a long-outstanding FCP. Josh nominates this for us to collect checkboxes. 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?

"Support for pointers with asm_const" rust#128464

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

TC: Josh nominates for us the question:

Nominating this for lang to discuss the question of whether we should support use of const in asm! for things that can't just be textually substituted, or whether we should give that a different name.

@Amanieu, any input you'd like to provide would be helpful.

To which Amanieu replies:

After thinking about it a bit, I think it's probably fine to add this functionality to const. I'm a bit bothered about the duplication with sym, which is already stable.

TC: What do we think?

"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. Its tracking issue is:

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

TC: What do we think?

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

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

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

"Emit a warning if a `match` is too complex" rust#122685

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

TC: Nadri nominates this for us and describes the situation:

Dear T-lang, this PR adds a warning that cannot be silenced, triggered when a match takes a really long time to analyze (in the order of seconds). This is to help users figure out what's taking so long and fix it.

We could make the limit configurable or the warning allowable. I argue that's not necessary because crater showed zero regressions with the current limit, and it's be pretty easy in general to split up a match into smaller matches to avoid blowup.

We're still figuring out the exact limit, but does the team approve in principle?

(As an aside, awhile back someone showed how to lower SAT to exhaustiveness checking with match. Probably that would hit this limit.)

TC: What do we think?

"Uplift `clippy::invalid_null_ptr_usage` lint as `invalid_null_arguments`" 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 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?

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

On radar RFCs, PRs, and issues

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

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

"[RFC] `core::marker::Freeze` in bounds" rfcs#3633

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

TC: We have up a proposed FCP. 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.

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

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

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

"Decide on name for `Freeze`" rust#131401

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

TC: We still need to pick a name for Freeze (which may still be Freeze) so that we can proceed with:

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

Having heard no options particularly more appealing options than Freeze, I propose we go with that as the author of that RFC has suggested.

TC: What do we think?

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

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

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

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

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?

Action item review

Action items list

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

"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

RFCs waiting to be merged

None.

`S-waiting-on-team`

"Split elided_lifetime_in_paths into tied and untied" rust#120808

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

"type privacy: Check constructor types in tuple struct patterns" rust#138458

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

"Implement a lint for implicit autoref of raw pointer dereference - take 2" rust#123239

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

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

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

"de-stabilize bench attribute" rust#134273

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

"aarch64-softfloat: forbid enabling the neon target feature" rust#135160

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

"Guarantee behavior of transmuting Option::<T>::None subject to NPO" rust#137323

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

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

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

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

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

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

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

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

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

"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

"Emit a warning if a `match` is too complex" rust#122685

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

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

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

"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

"Implement RFC 3349, mixed utf8 literals" rust#120286

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

"Tracking Issue for `bare_link_kind`" rust#132061

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

Proposed FCPs

Check your boxes!

"Split elided_lifetime_in_paths into tied and untied" rust#120808

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

"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

"Stabilize `cfg_boolean_literals`" rust#138632

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

"[RFC] `core::marker::Freeze` in bounds" 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

"Stabilize `naked_functions`" rust#134213

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

"stabilize ptr::swap_nonoverlapping in const" rust#137280

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

"Remove `i128` and `u128` from `improper_ctypes_definitions`" rust#137306

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

"Stabilize `repr128`" rust#138285

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

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

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

"Stabilize let chains in the 2024 edition" rust#132833

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

"Specify the behavior of `file!`" rust#134442

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

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

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

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

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

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

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

"Decide on name for `Freeze`" rust#131401

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

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

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

"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

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

Active FCPs

"Use `BinOp::Cmp` for `iNN::signum`" rust#137835

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

P-critical issues

None.

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`	在筆記中貼入程式碼
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.

T-lang meeting agenda

Attendance

Meeting roles

Scheduled meetings

Announcements or custom items

Guest attendee items

Moving right along

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

Next meeting with RfL

Rust 2025 review

Meta

Nominated RFCs, PRs, and issues

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

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

"Stabilize cfg_boolean_literals" rust#138632

"Stabilize naked_functions" rust#134213

"[RFC] core::marker::Freeze in bounds" rfcs#3633

"Stabilize repr128" rust#138285

"Partially stabilize LoongArch target features" rust#135015

"stabilize ptr::swap_nonoverlapping in const" rust#137280

"Stabilize the avx512 target features" rust#138940

"Define raw pointer transmute behavior" reference#1661

"type privacy: Check constructor types in tuple struct patterns" rust#138458

"Unsafe derives and attributes" rfcs#3715

"Allow numeric tokens containing 'e' that aren't exponents be passed to proc macros" rust#111615

"Implement a lint for implicit autoref of raw pointer dereference - take 2" rust#123239

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

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

"de-stabilize bench attribute" rust#134273

"aarch64-softfloat: forbid enabling the neon target feature" rust#135160

"experiment with relaxing the orphan rule" rust#136979

"Remove i128 and u128 from improper_ctypes_definitions" rust#137306

"Guarantee behavior of transmuting Option::<T>::None subject to NPO" rust#137323

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

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

"Stabilize let chains in the 2024 edition" rust#132833

"Specify the behavior of file!" rust#134442

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

"Decide on behavior of anonymous_lifetime_in_impl_trait" rust#137575

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

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

"Support for pointers with asm_const" rust#128464

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

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

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

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

"Emit a warning if a match is too complex" rust#122685

"Uplift clippy::invalid_null_ptr_usage lint as invalid_null_arguments" rust#119220

invalid_null_ptr_usages

Example

Explanation

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

On radar RFCs, PRs, and issues

"Split elided_lifetime_in_paths into tied and untied" rust#120808

"Arbitrary self types v2: stabilize" rust#135881

"[RFC] core::marker::Freeze in bounds" rfcs#3633

"Stabilize derive(CoercePointee)" rust#133820

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

"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

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

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

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

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

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

"Decide on name for Freeze" rust#131401

"RFC: Improved State Machine Codegen" rfcs#3720

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

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

"Declarative macro_rules! attribute macros" rfcs#3697

"Declarative macro_rules! derive macros" rfcs#3698

"Macro fragment fields" rfcs#3714

"Add homogeneous_try_blocks RFC" rfcs#3721

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

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

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

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

"Unsafe fields" rfcs#3458

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

"Hierarchy of Sized traits" rfcs#3729

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

"Stabilize `cfg_boolean_literals`" rust#138632

"Stabilize `naked_functions`" rust#134213

"[RFC] `core::marker::Freeze` in bounds" rfcs#3633

"Stabilize `repr128`" rust#138285

"Remove `i128` and `u128` from `improper_ctypes_definitions`" rust#137306

"Specify the behavior of `file!`" rust#134442

"Decide on behavior of `anonymous_lifetime_in_impl_trait`" rust#137575

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

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

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

"Emit a warning if a `match` is too complex" rust#122685

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

`invalid_null_ptr_usages`

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

"[RFC] `core::marker::Freeze` in bounds" rfcs#3633

"Stabilize `derive(CoercePointee)`" rust#133820

"Decide on name for `Freeze`" rust#131401

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

"Declarative `macro_rules!` attribute macros" rfcs#3697

"Declarative `macro_rules!` derive macros" rfcs#3698

"Add `homogeneous_try_blocks` RFC" rfcs#3721

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

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

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

"Decide what we want about `macro_metavar_expr`" rust#137581

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

`S-waiting-on-team`

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

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

"Emit a warning if a `match` is too complex" rust#122685

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

"Tracking Issue for `bare_link_kind`" rust#132061

"Stabilize `cfg_boolean_literals`" rust#138632

"[RFC] `core::marker::Freeze` in bounds" rfcs#3633

"Stabilize `derive(CoercePointee)`" rust#133820

"Stabilize `naked_functions`" rust#134213

"Remove `i128` and `u128` from `improper_ctypes_definitions`" rust#137306

"Stabilize `repr128`" rust#138285

"Specify the behavior of `file!`" rust#134442

"Decide on name for `Freeze`" rust#131401

"Declarative `macro_rules!` attribute macros" rfcs#3697

"Declarative `macro_rules!` derive macros" rfcs#3698