Triage meeting 2025-08-06

--- title: Triage meeting 2025-08-06 tags: ["T-lang", "triage-meeting", "minutes"] date: 2025-08-06 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-08-06/ url: https://hackmd.io/5jp-fFeYTHeTIffmmqb6zA --- # T-lang meeting agenda - Meeting date: 2025-08-06 ## Attendance - People: TC, Niko, Scottmcm, Tomas Sedovic, Davidtwco, Josh, Eric Holk, Taylor Cramer ## Meeting roles - Driver: TC - Minutes: Tomas Sedovic ## 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. #### `inline(always)` with `target_feature` davidtwco: Would like to quickly check if something requires an RFC: `inline(always)` doesn't work with `target_feature` at the moment, we prohibit that in the compiler, because LLVM will inline even when target features are incompatible - I'm interested in changing it so that we allow `inline(always)` with `target_feature` and put the `alwaysinline` hint on callsites that are compatible rather than on the function itself for these cases, and lint otherwise - this is what Clang does (but an error instead of a lint). Lint is required for backcompat to existing `inline` functions we might want to upgrade to `inline(always)`. `target_feature` RFC intended `inline(always)` to work, but this was changed in implementation when this issue was discovered, it hasn't changed since. I can write an RFC or an compiler MCP, just want to check if t-lang wanted to make the call or not. Josh: So, instead of having inline(always) complain at the definition site, it would try, look at all the call sites. And if any call site couldn't be inline, it'd give the complaint? David: It would inline it in every call site it could and not inline where it couldn't. Would always need to codegen it for downstream crates that may not be able to inline. Amanieu: target feature is part of the public api so this makes sensee. Josh: Preliminary vibe check: this will need some manner of FCP. It is a language-level change -- whether we want to defer this type of error at call site rather than a definition site. But the concept of solving this somehow is usable. But this particular proposal needs more thought. David: We need an RFC then? TC: I suggest filing an issue on rust-lang/rust that describes this in detail and CC us on it. If we have further thoughts, we can leave them there. If our vibe there is "do it" you can open a PR and nominate it for us, and we'll do our FCP there. Scott: If it can be feature gated, just check it in feature gate and we can talk about it in stabilization. It doesn't feel like a place that needs an RFC. Vibeside: inline(always) is still just a hint everywhere, so this seems plausible to me in that sense of "we don't actually inline it always 100%". Amanieu: I was about to say the same. LLVM does have optimization marks that tell you when it fails to inline something. We could use those to warn. Josh: Agreed to the inline(always) still being technically a hint even though much stronger these days. People do rely on it though so having a mechanism to error is usable. Another thing: the reason we have target_feature considered to be unsafe is: people came up with a couple really obscure cases where you could say that an instruction sequence for one processor could be interepreted in a different way on another processor. For the vast majority of the cases this is not the case. Josh: I'd argue this is not really an unsafe/undefined behaviour. It'd crash the program. We should consider whether target_feature should be a safety concern or threat it as "you've given a hint about this processor and if you run an instruction that the processor doesn't support, that's not a safety issue" Amanieu: I disagree. It's common features are deprecated and the instruction codes are reused. I don't think we can make this safe. Josh: Sounds like it depends on some architectures but not others then. Anyway, this is a proposal for a later time. TC: David, when you file an issue for this, it can serve as a tracking issue for the nightly feature. Scott: Josh, that sounds great if we can actually do it. But if LLVM showed up next week with a flag that says don't use funky instructions, we may not be able to practically do it. Niko: This doesn't feel comparable to stack overflow or abort. It feels like a programmer bug. It's not meeting consensus. Josh: To be explicit I wasn't suggesting we have consensus. I was bringing it up to look at the documentation and see whether it all still holds. TC: There's also inline assembly. Josh: Inline assembly is inherently unsafe. ### 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-08-13 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 ### "Don't warn on never to any `as` casts as unreachable" rust#144804 **Link:** https://github.com/rust-lang/rust/pull/144804 TC: I started an FCP. People are casting `todo!()` to some concrete type which is useful when you're [...] this stops the warning. Niko: What is this doing? Just not warning that it's unreachable? This seems good. I feel we can do more to make this less annoying but this is a starting point. Scott: I'm tempted to say it should be smarter about when it's not warning. But I don't see any need to block this. Niko: I don't thik we should still warn in other cases. I often use todo! in otherwise good code. It's annoying. Scott: I agree with todo and disagree with panic. Niko: I thought this was just todo. TC+Scott: this is for never type Josh: The only thnig this is doing is the as cast. This is still leaving code unreachable. `as` cast doesn't do anything. Niko: Yeah, I think that is reasonable. I'd be in favour of expanding more such lints but then we need to be more selective. Josh: We can have discussions about what code that's unreachable should be warned about in presence of things like todo!. But that's not this issue. ### "Port `#[link]` to the new attribute parsing infrastructure " rust#143193 **Link:** https://github.com/rust-lang/rust/pull/143193 TC: I proposed FCP on this one. We'll take the breaking change for everything except `#[link="dl"]`. That we'll keep ignore it but we'll issue a deny-by-default final compatibility warning (FCW) that reports in dependencies. Scott: yeah. This feels like the continuing saga we've doing for years on "why'd you put repr(C) on your local variable". Let's do it. Niko: +1 Josh: Ship it. TC: Three checkboxes, it'll go into FCP. ### "`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks" rust#143619 **Link:** https://github.com/rust-lang/rust/pull/143619 TC: I proposed FCP merge here too. TC: Outside of an extern bolck you have some function. You use `...` without specifying an argument. Without the pattern part of the parameter. Josh: And you apply macro to it so it doesn't reach rustc's verification. TC: Yes, this just adds the verification pre-expansion as well. Josh: There was only one crate that required doing this and they were very receptive to changing their syntax. This seems fine. Scott: Given that, deal. We did this for all trait methods in 2018 editions? When we started requiring the pattern? Feels good. I don't go "this is obviously something we ought to do" but I don't have any objections to it if people want to do it. Niko: +1 ### "const-eval: full support for pointer fragments" rust#144081 **Link:** https://github.com/rust-lang/rust/pull/144081 TC: We talked about it. Checked a lot of boxes, then asked Ralf to explain it better to us. He did that. What do we thing now? Josh: The answer to the question of "is this a necessary thing implementations would have to implement is: 'yes it is'". Which is fine. TC: I think it's OK. TC: The way we approach it is we disallow everything that's not specifically allowed. Could you write an implementation that allows everything in const and the things not allowed are just UB... maybe, but that's not the headspace Ralf is coming from and he's not explaining it in that context. And I don't think that matters to us today. Niko: The way I read it the answer was somewhere between yes and no. In practice yes, in theory you might change it but it's fine. Josh: You could choose a completely different strategy for const eval that met the same underlying requirement. You could imagine instead of const eval pointers being opaque values, an implementation could use concrete values and force them to be the same at runtime (by using fixed addresses). (That would be a quirky implementation for other reasons, of course.) So there isn't a hard requirement on what you implement. There's a hard requirement on the net effect that allows disassembling and assembling a pointer. TC: Are we good with Scott resolving the concern for us? Scott: I forgot I wrote the concern for this. Yeah. ### "Rewrite the new attribute argument parser" rust#144689 **Link:** https://github.com/rust-lang/rust/pull/144689 TC: This is about attributes on macro calls. You have an attribute like `inline` that you apply to a macro call. Before we weren't validating the attribute fully (unless it was a cfg attribute). We validate the abstract syntax category the macro fell in, but not the particulars for the attribute. This validates it fully. The crater run was clean; I propose we do it. Scott: unfortunate that `-1` is not a literal in macros. TC: Oli tried to fix that. It didn't get merged. Niko: This means I no longer can have a function where the inline attribute if the syntax doesn't match valid Rust syntax? TC: This is on the macro invocation. Niko: Trying to find a good test. Niko: This is being applied in the parser. TC: I asked Jonathan for clarification. Look at the last message in the thread. That's the best explanation of the current behavior compared to this change. https://github.com/rust-lang/rust/pull/144689#issuecomment-3147423610 Niko: He keeps using the example of inline. Is there something special on inline for macro calls? TC: No he's just using that as an example to distinguish what's accepted by the MetaItem vs. the inline attribute. Niko: What happens if you put attributes on the ??. Do they show up in expansion? Niko: The key thing is this is being done at parse time. When I'm parsing a call to a macro, I'll also enforce its attributes need a higher level of validity. That seems fine. You could still make your own inline if you want. I'll mark it with a question to confirm my understanding. TC: My model here for this work overall is that we're making the parsing of attributes more strict. We had been accepting things that we had no reason to accept, and these changes fix that for attributes in various positions. The position that we're fixing it in here is attributes applied to macro calls. That seems OK to me, and I'm generally in favor of parsing things more carefully. TC: With Niko's checkbox, this will move into FCP. ### "Next-Gen transmute" rfcs#3844 **Link:** https://github.com/rust-lang/rfcs/pull/3844 scottmcm: sneaking this in here for awareness and any vibes; not expecting to FCP this week or anything like that. Scott: This was vaguely based on a comment from a lang meeting two years ago. Wanted to move this to people's attention. Removing special type checks from transmute and moving to post-mono error. Josh: I think it's a great area. Having less magic in the compiler is great. The proposed `union_transmute` method should exist, but while many of us would know off the top of our head. But I'm not sure users would. I propose `transmute_unchecked`. Scott: The intrinsic is called transmute_unchecked. I put Libs API on the RFC so they can think about a good name. ### "Tracking Issue for enum access in offset_of" rust#120141 **Link:** https://github.com/rust-lang/rust/issues/120141 TC: We had decided on a plan here: do `try_offset_of` and `offset_of` (a post-mono version of `try_offset_of` where we uwrap the `Option` in a const block). fee1-dead said he would implement that, and then people had things to say. The discussion amounts to the degree that this may end up making a SemVer guarantee about the inhabitedness of various types. Josh: The inmabiteness of an enum being a semver property: yes of course. I can't come up with any scenario where you don't know enough about the enum layout where this wouldn't already be a breaking change regardless. The enum variants would effectively be public to begin with. Josh: I'm having a lot of trouble trying to understand why people think inhabitedness is not a semver guarantee. Scott: My intuition is that it's probably not a semver guarantee now. You can match an enum that's not inhabited now and it will compile. Imagine an error type like ```rust #[non_exhaustive] pub enum MyError { #[non_exhaustive] Case1(), #[non_exhaustive] Case2(), } ``` where in another version you change to: ```rust #[non_exhaustive] pub enum MyError { #[non_exhaustive] Case1(!), #[non_exhaustive] Case2(), #[non_exhaustive] Case3(), } ``` Then all the code that could have been written using `Case1` today is, I think, still something that would *compile* with the updated definition. So it'd be a behaviour change but not a compilation-*breaking* change to change `MyError` this way, even though it changes the inhabitedness of the variant. TC: Consider `pub struct W<T>(T)` vs `pub struct W<T>(Option<T>)`. What happens when you have a `Option<W<T>>`, and then you do `try_offset_of!(Option<W<!>>, Some.0)`? TC: The first struct is inhabited if and only if `T` is inhabited. In the second case it's always inhabited. Now it matters whether you have the first `W<T>` or the second `W<T>` and the argument is that the first and second are otherwise SemVer-compatible. Josh: I agree this can detect the difference between the two `W`s. My argument is what are you doing with the offset, because whatever you're doing will already require knowing what W is. You're either reading it or writing it -- and then you need to know what it is. TC: To be clear, I'm arguing the case for the thread here, though I still think we should do it. To complete the argument, look at Ralf's pseudo-code here: https://github.com/rust-lang/rust/issues/120141#issuecomment-3143110885 TC: You're deserializing the `Option<W<T>`. You're not poking the innards of the `W<T>` -- you're getting an offset for the outer `Option`. But the inhabitedness of the `W<T>` ends up affecting that. Josh: I'm looking at the example and struggling to find why it doesn't already need to know the type in question. Niko: I'm looking at Ralf's example and it makes sense. But: why are we going down this road again? Because it's useful to say that if you have can't have a partially-initialized enum variant. Scott: In struct you can't shrink the size of an uninhabited struct. But for enums it makes sense depending on whether you have space. Josh: And it's important to know that you have space to write to. Niko: That's not the problem of offset_of. It could return a number and it's your problem to not factor it. Scott: I was thinking that everyone would immediately pass this to byte add and it'd be UB. Niko: I don't know why you would want the offset. Ralfs point is mostly that this function is returning None. There's nothing wrong here with the code Ralf wrote here. TC: He's arguing that the `None` that's returned implies that it should be unreachable. Niko: I don't think that follows. I feel like the `None` should simply be unreachable. Full stop. Josh: I think that's the point, yeah. Niko: So what's the problem? Why is this different other than any other variant index that's invalid? Niko: I think what Ralf's writing is not true. You have to assume the input is trusted. I'd expect this: ```rust fn deserialize_into(result_ptr: *mut Result<T, E>, input: &mut &[u8]) -> Result<(), DeserError> { match input.next_byte() { 0 => { // Ok variant ... } 1 => { // Err variant match try_offset_of!(/* Err's field */) { Some(o) => { E::deserialize_into(result_ptr.byte_add(o).cast::<E>(), input)?; /* set discriminant to Err */ Ok(()) } // invalid input: this should never have happened, but no different than... None => Err(...), } _ => Err(...), // <-- ...this case where you have an invalid discriminant } } ``` Niko: What would be the difference here? You can't have this variant just like you can't have a variant that doesn't exist. TC: Another question, what are we expecting `try_offset_of` to return here? E.g., given `W<T>(Option<T>)` vs `W<T>(T)`... what do we expect for `try_offset_of!(Option<W<!>>, Some.0)`? It could conservatively return `None` for both cases, or it could expose the actual inhabitedness. Niko: I was expecting it to leak this information like size_of. Josh: Yeah. If you're relying on size_of you're probably doing something beyond the guarantees of the library to begin with, unless the library has made an explicit guarantee. Niko: That's my thought. You can't rely on that not to change for a minor semver update. You can rely on the type not to change but not the value. (The meeting ended here.) --- ## "`rustc_const_eval`: respect `target.min_global_align`" rust#142198 **Link:** https://github.com/rust-lang/rust/pull/142198 ### "Stabilize the `breakpoint` function" rust#142325 **Link:** https://github.com/rust-lang/rust/pull/142325 ## 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 ### "[WIP] Forbid object lifetime changing pointer casts" rust#136776 **Link:** https://github.com/rust-lang/rust/pull/136776 ### "Tracking issue for `cfg_select` (formerly `cfg_match`)" rust#115585 **Link:** https://github.com/rust-lang/rust/issues/115585 ### "Split elided_lifetime_in_paths into finer-grained lints" 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 ### "`#[target_feature]` mismatch on unsafe trait fn vs its impl causes sneaky UB" rust#139368 **Link:** https://github.com/rust-lang/rust/issues/139368 ### "Spurious irrefutable_let_patterns warning with let-chain" rust#139369 **Link:** https://github.com/rust-lang/rust/issues/139369 ### "Stabilize `fn_align`: `#[align(N)]` on functions" rust#140261 **Link:** https://github.com/rust-lang/rust/pull/140261 ### "`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 ### "[RFC] Allow packed types to transitively contain aligned types" rfcs#3718 **Link:** https://github.com/rust-lang/rfcs/pull/3718 ### "RFC: Add an attribute for raising the alignment of various items" rfcs#3806 **Link:** https://github.com/rust-lang/rfcs/pull/3806 ### "Tracking issue for RFC 2523, `#[cfg(version(..))]`" rust#64796 **Link:** https://github.com/rust-lang/rust/issues/64796 ### "Tracking issue: Support for pointers with `asm_const`" rust#128464 **Link:** https://github.com/rust-lang/rust/issues/128464 ### "lexer: Treat more floats with empty exponent as valid tokens" rust#131656 **Link:** https://github.com/rust-lang/rust/pull/131656 ### "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 ### "Stabilize `derive(CoercePointee)`" rust#133820 **Link:** https://github.com/rust-lang/rust/pull/133820 ### "experiment with relaxing the orphan rule" rust#136979 **Link:** https://github.com/rust-lang/rust/issues/136979 ### "Tracking issue for unsupported_calling_conventions (cdecl, stdcall, fastcall)" rust#137018 **Link:** https://github.com/rust-lang/rust/issues/137018 ### "Oddity with lifetime elision and type aliases" rust#140611 **Link:** https://github.com/rust-lang/rust/issues/140611 ### "Add `core::ptr::assume_moved`" rfcs#3700 **Link:** https://github.com/rust-lang/rfcs/pull/3700 ### "#[deprecated] lint doesn't trigger when overriding deprecated method" rust#98990 **Link:** https://github.com/rust-lang/rust/issues/98990 ### "Tracking Issue for unicode and escape codes in literals" rust#116907 **Link:** https://github.com/rust-lang/rust/issues/116907 ### "Tracking Issue for enum access in offset_of" rust#120141 **Link:** https://github.com/rust-lang/rust/issues/120141 ### "sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets" rust#123617 **Link:** https://github.com/rust-lang/rust/pull/123617 ### "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 ### "Decide on behavior of `anonymous_lifetime_in_impl_trait`" rust#137575 **Link:** https://github.com/rust-lang/rust/issues/137575 ### "`rustc_const_eval`: respect `target.min_global_align`" rust#142198 **Link:** https://github.com/rust-lang/rust/pull/142198 ### "[RFC] Add `#[export_ordinal(n)]` attribute" rfcs#3641 **Link:** https://github.com/rust-lang/rfcs/pull/3641 ### "RFC: No (opsem) Magic Boxes" rfcs#3712 **Link:** https://github.com/rust-lang/rfcs/pull/3712 ### "Tracking Issue: Procedural Macro Diagnostics (RFC 1566)" rust#54140 **Link:** https://github.com/rust-lang/rust/issues/54140 ### "Remove unstable cfg `target(...)` compact feature" rust#130780 **Link:** https://github.com/rust-lang/rust/pull/130780 ### "Strengthen the follow-set rule for macros" rust#131025 **Link:** https://github.com/rust-lang/rust/issues/131025 ### "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 ### "RFC: Improved State Machine Codegen" rfcs#3720 **Link:** https://github.com/rust-lang/rfcs/pull/3720 ### "Add `must-use-output` attribute" rfcs#3773 **Link:** https://github.com/rust-lang/rfcs/pull/3773 ### "Effective breakage to `jiff` due to `ambiguous_negative_literals`" rust#128287 **Link:** https://github.com/rust-lang/rust/issues/128287 ### "Simplify lightweight clones, including into closures and async blocks" rfcs#3680 **Link:** https://github.com/rust-lang/rfcs/pull/3680 ### "Macro fragment fields" rfcs#3714 **Link:** https://github.com/rust-lang/rfcs/pull/3714 ### "Add `homogeneous_try_blocks` RFC" rfcs#3721 **Link:** https://github.com/rust-lang/rfcs/pull/3721 ### "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 ### "Coercing &mut to *const should not create a shared reference" rust#56604 **Link:** https://github.com/rust-lang/rust/issues/56604 ### "#[cold] on match arms" rust#120193 **Link:** https://github.com/rust-lang/rust/pull/120193 ### "`is` operator for pattern-matching and binding" rfcs#3573 **Link:** https://github.com/rust-lang/rfcs/pull/3573 ### "Unsafe fields" rfcs#3458 **Link:** https://github.com/rust-lang/rfcs/pull/3458 ### "RFC: Allow symbol re-export in cdylib crate from linked staticlib" rfcs#3556 **Link:** https://github.com/rust-lang/rfcs/pull/3556 ### "Hierarchy of Sized traits" rfcs#3729 **Link:** https://github.com/rust-lang/rfcs/pull/3729 ### "Language vs. implementation threat models and implications for TypeId collision resistance" rust#129030 **Link:** https://github.com/rust-lang/rust/issues/129030 ### "RFC: inherent trait implementation" rfcs#2375 **Link:** https://github.com/rust-lang/rfcs/pull/2375 ### "Raw Keywords" rfcs#3098 **Link:** https://github.com/rust-lang/rfcs/pull/3098 ### "RFC: Implementable trait aliases" rfcs#3437 **Link:** https://github.com/rust-lang/rfcs/pull/3437 ### "Should Rust still ignore SIGPIPE by default?" rust#62569 **Link:** https://github.com/rust-lang/rust/issues/62569 ### "types team / lang team interaction" rust#116557 **Link:** https://github.com/rust-lang/rust/issues/116557 ### "Trait method impl restrictions" rfcs#3678 **Link:** https://github.com/rust-lang/rfcs/pull/3678 ### "Closing issues relevant to T-lang on this repo" rfcs#3756 **Link:** https://github.com/rust-lang/rfcs/issues/3756 ### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418 **Link:** https://github.com/rust-lang/rust/pull/106418 ### "Fallout from expansion of redundant import checking" rust#121708 **Link:** https://github.com/rust-lang/rust/issues/121708 ### "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 ### "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 ### "`continue` expressions in loop conditions" rust#118673 **Link:** https://github.com/rust-lang/rust/issues/118673 ### "Tracking Issue for `breakpoint` feature (`core::arch::breakpoint`)" rust#133724 **Link:** https://github.com/rust-lang/rust/issues/133724 ### "`fn_cast!` macro" rust#140803 **Link:** https://github.com/rust-lang/rust/issues/140803 ### "Permit duplicate imports" rust#141043 **Link:** https://github.com/rust-lang/rust/pull/141043 ### "Stabilize `if let` guards (`feature(if_let_guard)`)" rust#141295 **Link:** https://github.com/rust-lang/rust/pull/141295 ### "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 ### "de-RFC: Remove unsized_locals" rfcs#3829 **Link:** https://github.com/rust-lang/rfcs/pull/3829 ### "Tracking Issue for `const fn` `type_id`" rust#77125 **Link:** https://github.com/rust-lang/rust/issues/77125 ### "Reject relaxed bounds inside associated type bounds (ATB)" rust#135331 **Link:** https://github.com/rust-lang/rust/pull/135331 ### "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 ### "Add new `function_casts_as_integer` lint" rust#141470 **Link:** https://github.com/rust-lang/rust/pull/141470 ### "Consider folkertdev's `c_variadic` proposal" rust#141524 **Link:** https://github.com/rust-lang/rust/issues/141524 ### "Permit attributes on `use` items" rust#141704 **Link:** https://github.com/rust-lang/rust/issues/141704 ### "Stabilize `#[cfg(version(...))]`, take 2" rust#141766 **Link:** https://github.com/rust-lang/rust/pull/141766 ### "Should a `[..]` slice pattern constitute a discriminant read" rust#141825 **Link:** https://github.com/rust-lang/rust/issues/141825 ### "drop-checking is more permissive when `let` statements have an `else` block" rust#142056 **Link:** https://github.com/rust-lang/rust/issues/142056 ### "Decision: Use the condition name `rust_version` for RFC 2523" rust#142651 **Link:** https://github.com/rust-lang/rust/issues/142651 ### "Stabilize `-Cmin-function-alignment`" rust#142824 **Link:** https://github.com/rust-lang/rust/pull/142824 ### "Warn or error on duplicate attributes" rust#142836 **Link:** https://github.com/rust-lang/rust/issues/142836 ### "A path towards erroring on nonsense attributes" rust#142838 **Link:** https://github.com/rust-lang/rust/issues/142838 ### "emit `StorageLive` and schedule `StorageDead` for `let`-`else`'s bindings after matching" rust#143028 **Link:** https://github.com/rust-lang/rust/pull/143028 ### "const-eval can construct uninhabited values via recursive static initialization" rust#143047 **Link:** https://github.com/rust-lang/rust/issues/143047 ### "add a scope for `if let` guard temporaries and bindings" rust#143376 **Link:** https://github.com/rust-lang/rust/pull/143376 ### "Nested panics and `std::thread::panicking`" rust#143612 **Link:** https://github.com/rust-lang/rust/issues/143612 ### "lower pattern bindings in the order they're written and base drop order on primary bindings' order" rust#143764 **Link:** https://github.com/rust-lang/rust/pull/143764 ### "Should_panic can be applied to non-tests" rust#143799 **Link:** https://github.com/rust-lang/rust/issues/143799 ### "Port `#[should_panic]` to the new attribute parsing infrastructure " rust#143808 **Link:** https://github.com/rust-lang/rust/pull/143808 ### "Port #[macro_export] to the new attribute parsing infrastructure" rust#143857 **Link:** https://github.com/rust-lang/rust/pull/143857 ### "Mark all deprecation lints in name resolution as deny-by-default and report-in-deps" rust#143929 **Link:** https://github.com/rust-lang/rust/pull/143929 ### "stabilize c-style varargs for system, sysv64, win64, efiapi, aapcs" rust#144066 **Link:** https://github.com/rust-lang/rust/pull/144066 ### "Stabilize const TypeId::of" rust#144133 **Link:** https://github.com/rust-lang/rust/pull/144133 ### "Extract TraitImplHeader in AST/HIR" rust#144386 **Link:** https://github.com/rust-lang/rust/pull/144386 ### "Stabilize loongarch32 inline asm" rust#144402 **Link:** https://github.com/rust-lang/rust/pull/144402 ### "Add lint against integer to pointer transmutes" rust#144531 **Link:** https://github.com/rust-lang/rust/pull/144531 ### "Stabilize `sse4a` and `tbm` target features" rust#144542 **Link:** https://github.com/rust-lang/rust/pull/144542 ### "Start reporting future breakage for `ILL_FORMED_ATTRIBUTE_INPUT` in dependencies" rust#144544 **Link:** https://github.com/rust-lang/rust/pull/144544 ## Action item review - [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A) ## 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 ### "Document experimental `P-lang-drag-[0-4]` and `I-lang-easy-decision`" lang-team#330 **Link:** https://github.com/rust-lang/lang-team/pull/330 ## RFCs waiting to be merged ### "[RFC] Add `#[export_ordinal(n)]` attribute" rfcs#3641 **Link:** https://github.com/rust-lang/rfcs/pull/3641 ### "Closing issues relevant to T-lang on this repo" rfcs#3756 **Link:** https://github.com/rust-lang/rfcs/issues/3756 ## `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 ### "Stabilize `fn_align`: `#[align(N)]` on functions" rust#140261 **Link:** https://github.com/rust-lang/rust/pull/140261 ### "lexer: Treat more floats with empty exponent as valid tokens" rust#131656 **Link:** https://github.com/rust-lang/rust/pull/131656 ### "`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 ### "Add lint against (some) interior mutable consts" rust#132146 **Link:** https://github.com/rust-lang/rust/pull/132146 ### "Stabilize the `breakpoint` function" rust#142325 **Link:** https://github.com/rust-lang/rust/pull/142325 ### "#[cold] on match arms" rust#120193 **Link:** https://github.com/rust-lang/rust/pull/120193 ### "Permit duplicate imports" rust#141043 **Link:** https://github.com/rust-lang/rust/pull/141043 ### "Stabilize `if let` guards (`feature(if_let_guard)`)" rust#141295 **Link:** https://github.com/rust-lang/rust/pull/141295 ### "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 ### "Add new `function_casts_as_integer` lint" rust#141470 **Link:** https://github.com/rust-lang/rust/pull/141470 ### "Stabilize `-Cmin-function-alignment`" rust#142824 **Link:** https://github.com/rust-lang/rust/pull/142824 ### "Add debuginfo_transparent attribute for structs" rust#144223 **Link:** https://github.com/rust-lang/rust/pull/144223 ## 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 ### "[WIP] Forbid object lifetime changing pointer casts" rust#136776 **Link:** https://github.com/rust-lang/rust/pull/136776 ### "Don't warn on never to any `as` casts as unreachable" rust#144804 **Link:** https://github.com/rust-lang/rust/pull/144804 ### "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 ### "Port `#[link]` to the new attribute parsing infrastructure " rust#143193 **Link:** https://github.com/rust-lang/rust/pull/143193 ### "`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks" rust#143619 **Link:** https://github.com/rust-lang/rust/pull/143619 ### "const-eval: full support for pointer fragments" rust#144081 **Link:** https://github.com/rust-lang/rust/pull/144081 ### "Rewrite the new attribute argument parser" rust#144689 **Link:** https://github.com/rust-lang/rust/pull/144689 ### "`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 ### "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 ### "RFC: No (opsem) Magic Boxes" rfcs#3712 **Link:** https://github.com/rust-lang/rfcs/pull/3712 ### "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 ### "Stabilize the `breakpoint` function" rust#142325 **Link:** https://github.com/rust-lang/rust/pull/142325 ### "Unsafe fields" rfcs#3458 **Link:** https://github.com/rust-lang/rfcs/pull/3458 ### "[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 ### "Stabilize `if let` guards (`feature(if_let_guard)`)" rust#141295 **Link:** https://github.com/rust-lang/rust/pull/141295 ### "RFC: Allow type inference for const or static" rfcs#3546 **Link:** https://github.com/rust-lang/rfcs/pull/3546 ### "Allow `&&`, `||`, and `!` in `cfg`" rfcs#3796 **Link:** https://github.com/rust-lang/rfcs/pull/3796 ### "de-RFC: Remove unsized_locals" rfcs#3829 **Link:** https://github.com/rust-lang/rfcs/pull/3829 ### "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 ### "Stabilize `#[cfg(version(...))]`, take 2" rust#141766 **Link:** https://github.com/rust-lang/rust/pull/141766 ### "Decision: Use the condition name `rust_version` for RFC 2523" rust#142651 **Link:** https://github.com/rust-lang/rust/issues/142651 ### "new decision process" lang-team#326 **Link:** https://github.com/rust-lang/lang-team/pull/326 ## Active FCPs ### "Reject relaxed bounds inside associated type bounds (ATB)" rust#135331 **Link:** https://github.com/rust-lang/rust/pull/135331 ### "emit `StorageLive` and schedule `StorageDead` for `let`-`else`'s bindings after matching" rust#143028 **Link:** https://github.com/rust-lang/rust/pull/143028 ### "Port `#[should_panic]` to the new attribute parsing infrastructure " rust#143808 **Link:** https://github.com/rust-lang/rust/pull/143808 ### "stabilize c-style varargs for system, sysv64, win64, efiapi, aapcs" rust#144066 **Link:** https://github.com/rust-lang/rust/pull/144066 ### "Extract TraitImplHeader in AST/HIR" rust#144386 **Link:** https://github.com/rust-lang/rust/pull/144386 ### "Stabilize loongarch32 inline asm" rust#144402 **Link:** https://github.com/rust-lang/rust/pull/144402 ### "Add lint against integer to pointer transmutes" rust#144531 **Link:** https://github.com/rust-lang/rust/pull/144531 ### "Stabilize `sse4a` and `tbm` target features" rust#144542 **Link:** https://github.com/rust-lang/rust/pull/144542 ### "Start reporting future breakage for `ILL_FORMED_ATTRIBUTE_INPUT` in dependencies" rust#144544 **Link:** https://github.com/rust-lang/rust/pull/144544 ## 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.