Triage meeting 2025-07-09

--- title: Triage meeting 2025-07-09 tags: ["T-lang", "triage-meeting", "minutes"] date: 2025-07-09 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-07-09/ url: https://hackmd.io/7qrwnRwHSUWQWVAz-X6KjQ --- # T-lang meeting agenda - Meeting date: 2025-07-09 ## Attendance - People: TC, scottmcm, Taylor, Tyler Mandry, Josh, Yosh, Amanieu, Nurzhan Saken ## Meeting roles - Driver: TC - Minutes: Tomas ## Scheduled meetings - 2025-07-23: "Design meeting: Solution for `NoCell` and `no_std`" [#324](https://github.com/rust-lang/lang-team/issues/324) - 2025-07-30: "Design meeting: In-place Initialization" [#332](https://github.com/rust-lang/lang-team/issues/332) 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!) Tomas: Out for most of the next week: 2025-07-14 (Monday) to 2025-07-17 (Thursday) Tomas: Goal submission deadline 2025-07-18 ### 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-07-16 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 ### "Tracking issue for Effective Target Features" rust#143352 **Link:** https://github.com/rust-lang/rust/issues/143352 TC: This is an ask for a lang expemiment. What we're doing currently for traits and `#[target_feature(enable = ..)]` doesn't make a lot of sense. This started as a way of fixing this; we had previously outlined how we wanted this to work in a refinement framework. We also discussed this as part of the design meeting on marker effects. Many of us are excited about this work and willing to support it. It seems an easy "yes"; it's raised here just for our context. Scott: If target features are going to be useful, this will mean separate monomorphising for different effects. And I recall we were not looking at that? Second, curious where did the idea of passing target features on trait objects went? TC: On the second question, this is related but a separate alternative and one without the difficult implementation questions. Josh: Related question: the effect-based mechanism would allow you to statically detect whether functions being called have suficient guarantee that they have given a target feature. But at runtime, you'd still require unsafe operations to call those features, right? There's no safe scheem to call those functions safely? TC: The proposal has a way to unsafely open a dynamic context. Josh: That makes sense to me. What I'd like to raise is, in the absence of something like tagged types that serve as existence proof for having done that as a runtime check you need to do this with unsafe. It would be good for the experiment to show how much unsafe you need and see if we can reduce the amount of unsafe. Scott: I misunderstood and this wouldn't be multiversioning effectfulness proposal. This is "can you call something" and replacing target feature with an effect for each target feature. It would be moving the check that target_feature_1_1 into traits. TC: That's right. Tyler: The design sketch has the syntax we'd use today and the effectful equivalent using our hypothetical `do` syntax with associated effects. And it would be fitting into const trait and const effects and so for. I think this should be an experiment and want the team to be aware. Josh: Full support to seeing this as a lang experiment. A have things I'd like to see answered, but full support for this going ahead. Scott: Be great if all these effects lead to us stopped adding new ad-hoc rules that are essentially effect-like, and just integrated them in the language. TC: +1. (The team agrees for the experiment going forward.) ### "Nested panics and `std::thread::panicking`" rust#143612 **Link:** https://github.com/rust-lang/rust/issues/143612 Amanieu: There's a general need for a `drop` implementation that has to handle things differently based on whether it's called during unwind or normal code. A common issue is with `ScopeGuard`. This is implemented with `std::thread::panicking`. But panic happens (which causes `drop` to execute) if your `drop` calls a separate function, `std::thread::panicking` will still show `true` within that function. This can cause issues (e.g. double-free). TC: What you want here is the special `drop` to be called on the upward path from the panic but the normal `drop` to happen on any downward paths that happen while working upward. I.e., we don't want to treat the entire dynamic extent as panicking. Amanieu: Yes, only the drop that's called as part of the unwinding mechanism. Tyler: Seems hard to define. If you have one drop that's calling a drop of the fields, all the inner-field drops would be called because of panic, but any functions that we call would reset the scope. Taylor: If you have a drop function and you call `Option::take()` it would not be marked as panicking, but if you let the Option go out of scope normally it would. Tyler: I'm not sold that this is obviously the right behaviour. Scott: Interested to heard from some of the experts about what it'd imply if we built that. I wonder if there's going to be any weird cases where we have one drop node and the compile and mir would get much better is because there's no cleanup. Maybe the answer is for the RFC will need to decide how to handle that. Josh: A potential direction for a next step. This sounds like something that warrants a lang experiment. Try something that demonstrates the value of doing a separate unwind drop. Amanieu: There is an alternative propsal to this. Having first-clas ScopeGuards in the language. Think something along the lines of `try {..} finally {..}` in Java. Tyler: Like a `defer`? Amanieu: Yes, basically like a defer but in the language. TC: How would that solve this? Does it just remove the motivation, or there a deeper connection? Amanieu: ScopeGuard is unsound. If we made that the first-class language feature, that would make the crate obsolete. Yosh: I'd see defer in running in both branches. I don't see how this would help with ScopeGuard and the panicking issue. Amanieu: Haven't thought it through, just that this is an alternative of having `unwind_drop`. Tyler: Same question as Yosh. In most cases I want to do the same thing in both paths. The only thing I can see is in the test code where I'd like to accumulate all the asserts and see if we're panicking and then automatically skip the panics in that case. I'm suspicious of production code that needs to do this. Tyler: I would want to know what's the motivation for having it in language be. Scott: The other thing is, how do we feel about the special `on_unwind` version of the macro vs. the other things. Having a bomb that's defused by having a "once you reach this code the bomb will no longer go off" feels better. Because that's a control flow concept that removes the question of the ambient panicness at all. The other thing is we could say `ScopeGuard` is unsound and people can write unsound safe code and we can say "don't do that". Josh: Similar to what Tyler said. I'm a little surprised by the widespread drive for `defer` on unwind. Can we see a few examples of production code that's using `defer` on unwind that *seems like a good idea*? So far the only thing I've seen is mutex poisoning and we've agreed that mutex poisioning is a bad idea. Tyler: We agreed mutex poisoning is a bad idea or the way it's currently implemented? Amanieu: I've linked an example in hashbrow. We clear the table because we can't recover from this. But we still need the table in an empty state rather than being it filled with garbage. https://github.com/rust-lang/hashbrown/blob/e514afefa94cdfc7b6ce90ba5484996bd5bcfcd8/src/raw/mod.rs#L2946 Josh: That seems like the right idea to use defer on unwind. Defer and then disarm on the success case. Josh: I think we can agree that `std::thread::panicking` is broken. We have case studies that show this is not showing the correct information. Someone suggested doing a counter and comparing the counter Scott: Sounds like what people want is not panicking but: "if I do this now is it going to abort?" Josh: That's a different problem from "am I unwinding?" TC: It's not obvious to me that `panicking` is broken because it doesn't solve this use case. It seems useful to know whether panicking is happening within a dynamic extent. TC: Scott, describe if you would again, the case for why we might not need what's proposed here. Scott: You make a guard type, the guard type is a drop which will do the clean up. Once you've finished initializing everything, you `mem::forget` (defuse) the bomb, but now you've reached the point where you said "I've finished doing the work" and now I can panic and if I haven't finished the clean up, the drop on guard will do it for me. Scott: Rather than checking for absence of panic, you check for the "I hit the point where I'm happy with this". TC: Makes sense, yes. So the question, then, is whether there's any use case that isn't solved by that, if we're happy recommending that pattern to people. Josh: I think there's an extension of the pattern that would make it more usable. One of the unwind_drop issues is that you'd have to propagate this into further unwinds. The bomb defusal pattern is better but the downside is that you explicitly defuse the bomb. Can we do a small language improvement where ??. "If I explicitly return, please call 'defuse' for me before droping things." Scott: That reminds me of the scoped-thread methods: https://github.com/yoshuawuyts/mini-scopeguard If you get past the closure, you could ??. That could be implemented as a library. Tyler: That makes sense. The only downside is it adds an extra layer of indentation. Scott: Ideally that may even be safe because `forget`ting something is not unsafe. It mayb e leake but not unsafe. Tyler: We're veering into designing a new API in the lang meeting. Scott: Agreed but does it need to be a language feature or could we do a library feature that does this via a closure. Scott: Something that would be alanguage thing: you have to put whatever you need to drop into the "bomb" class. One version of "forget is awkward" is "this type has a drop implementation so you can't destructure it". If we could do a lang thing that lets you destructure the type without destructing it, that would help. Lets you automatically defuse it by not running the drop. Tyler: There has been an RFC for allowing to destructure types that have a drop implementation. ### "Tracking Issue for `#![feature(const_float_round_methods)]`" rust#141555 **Link:** https://github.com/rust-lang/rust/issues/141555 TC: I don't think we'll do much before we see a PR, but I wanted to check whether we see any immediate problems before we unnominate this. Josh: Ship it. Tyler: Which floating point ops have we accepted? IIRC we've accepted floating point ops that had diverging behaviour around NaNs etc. This wouldn't be anything more weird that we've accepted. Scott: The ones we accepted are as definded bitwise ops in a special section of the IEEE 754 standard. This would be a thing outside of that section so it would be an expansion. Scott: These are not the same as the bitwise ones because they're in a separate area. But nothing here looks like it'd get hairy. I don't see any Table Maker's Dilemma here. Tyler: Scott, are you saying we don't support add today? I guess that'd require const traits. Is there a difference between these functions and basic arithmetic ops in terms of how much we would be accepting? Scott: The basic arithmetic is slightly harder but I don't think there's huge difference. And I think that's already allowed in const because it uses the magic operator not the trait calls. The big thing to me is if we wanted something like a tangent. I think `floor` is always just "clear some number of bits at the back of the number" rather than having to call some non-primitive function. Nurzhan: I already created a stabilization PR for this: https://github.com/rust-lang/rust/pull/143604 TC: Great, thanks Nurzhan for that. Let's review that. Scott: I scanned the PR, this all makes sense to me? TC: I'm firing an FCP-merge. TC: And we're now in FCP. ### "Closing issues relevant to T-lang on this repo" rfcs#3756 **Link:** https://github.com/rust-lang/rfcs/issues/3756 TC: I filed a concern on this one. I agree people shouldn't be filing design proposals, but it seems a bit heavy-handed to totally close out anything lang-related on the RFC repo. Scott: I've been looking at the list again. Ther's a bunch of stuff that there should be closed. I agree the specific instance you pointed out is good and something we want. But I really don't want to have a value judgement in closing. I want to be able to say that any lang feature that's opened here is: this is closed. Scott: I'd like us to find some other way of saying "we have a place where you can write something and we can make a decision". I have a proposal of "lang problem spaces with positive vibes". If you want to write up a vibe-check, maybe with a thread with zulip, that wolud be great. Josh: What you said Scott makes a lot of sense, what if we set the policy going forward for new issues. That doesn't obligate us to do this for the existing issues. Josh: We should have an official home and process for vibe checks. We should have a place for where people want to discuss pre-RFC. We should have a process that people can follow. Github issues have proven a non-effective solution for discussing things that are good ideas. TC: I don't want to make value judgements on the issues either. Three things. TC: One, I see a class of issues that make more sense than others that are identifiable at the procedural or meta (rather than lang) level. If you have a tracking issue for a set of RFCs, or are collecting data for filing an RFC - I think that's a totally reasonable use for an issue. It seems maybe a bit heavy-handed to have a policy against things like that. TC: Two, while we ourselves are on all our platforms, many contributors are only on GitHub. Being too heavy-handed about closing off all avenues for providing feedback there can cause other problems. TC: Three, what's the goal for this? E.g., if it's just to not surprise people, we could have triagebot reply to people with information about our processes. Scott: I don't see a reason to leave it open if no one's going to look at it. If people want to have a conversation, there's plenty of places they could go. Scott: As for collecting data, I don't want to have the tech debt of "why do you have a bajillion issues you're never going to close". If someone wants to have a fork of the RFC repo where they're collecting the data, then that's great. They can have lots of issues there. We've seen that work of RFCs. Someone clones the RFC repo, creates issues, don't get notifications of stuff they don't care. Scott: So if someone wants to suggest a language change, we should just close that. Josh: Seconding everything you've just said Scott. There are many forums where people can discuss. We provide several official places people can do this (zulip, discord) and semi-official spaces like reddit. There's a value of having spaces where they can discuss this. I think posting an auto-thing saying we won't look at this it'll send the wrong idea (i.e. that we *should* be looking at them). Josh: Rust isn't only GitHub. If you can't be bothered to make an account, that's perhaps the lowest bar that we could set for "are you willing to follow any of the other processes we have". scottmcm: Discourse and Zulip both have login-with-GitHub, so don't even need a new account. Tyler: I see the core problem is the ambiguity of where to go and what the purpose of the issues is. We need to resolve that one way or the other. Removing the ambiguity is the higher-order bit. TC: Your concern about the number going up -- isn't that the same problem as with the PRs? Josh: We are looking at those. We should be looking at them at least. Scott: Maybe what we want to do once we're cleared the nominated queue is start looking at the RFC proposals. TC: I agree but at the same time, it's unrealistic to say "the lang team reliably reviews new proposed RFCs". Scott: Aspirationally want to. Like Libs-API took time to figure out how to do the ACPs, they did figure it out. Maybe I can write a PR for the advise of where else people should go. Josh: And we should write a proposal for what the vibe check process should be. (The first part of the meeting ended here.) --- (The second part of the meeting started here.) People: TC, tmandry, Yosh, Josh, Amanieu, Tomas ### "Add new `function_casts_as_integer` lint" rust#141470 **Link:** https://github.com/rust-lang/rust/pull/141470 Josh: This lint, among other things, helps catch `u32::max as usize`. (They meant to write `u32::MAX as usize`.) This happened in production. This silently took the `max` *function*, cast it to `usize` which provided an address to the function. Rarely what you actually want. There are legitimate reasons you want to turn a function's address to a `usize` but it's less common. Josh: 1. Can we agree that we don't want people to write `function_name as usize` without warning? Josh: 2. If so, what do we want them to do instead when they really do want this? TC: I don't really want to disentagle them. Whether we want to lint is often contingent on how appealing the alternative is. Without something else here, the alternative currently isn't great, as it would push people to elaborating the full function signature, and thaht's too much. Josh: The reason for splitting is to see if we agree if we want to agree assuming we can agree on something that we can steer people towards, can we lint on this? TC: It still seems better to me to have the other conversation. Josh: So, that attempt at bikeshed-avoidance is dead now, let's bikeshed... Tyler: This does seem like a well motivated lint. I agree that writing out the entire function signature is going too far. `as _` seems okay and there's also a proposal for Libs-API. Both seem good to me. Josh: I don't want this to cause churn by first linting and steering people to a clunky solution and then steering them to something better. Josh: I want to propose adding `.fn_addr()` -- that's pretty clear. Amanieu: We've already accepted an ACP for this: https://github.com/rust-lang/libs-team/issues/589#issuecomment-2981331798 Josh: That looks great. Amanieu: Probably needs a bit more work. It does involve some magic traits that are implemented for all function types and function pointers. Amanieu: The `addr` method doesn't take `Self` -- like I said, still needs more work. Tyler: I guess it could also be `::addr`. Amanieu: But there's no way to name the function type. Tyler: I've expected we'd have that lang extention one day. TC: We could treat this as a vibe check. All our vibes seem positive. `addr` seems like the right idea. With that, linting seems reasonable. Tyler: +1. TC: I posted some examples of things this lint doesn't catch. Do we want to catch any of these? https://github.com/rust-lang/rust/pull/141470#issuecomment-2950041139 Amanieu: I think those are fine. The thing here is to catch accidental casts. Josh: Agreed. If you are casting a function as a pointer, you know you're dealing with pointers and know what to expect. The original problem which lead to a security issue was: ```rust len < (u16::max as usize) ``` tmandry: We could also special case that as a lint. Josh: We could do that. But I wonder how much value there is given that clippy catches the more general issue. Tyler: Not everyone uses Clippy. Josh will summarize that to the issue: we have an accepted ACP, we'd like to see a lint based on that and we'd like to ship and stabilize that API in a timely fashion. If that takes long, we'd like to add a lint that specifically catches cases like this. TC: To reflect for a moment on the process matter of separating out the questions, I agree that separating them for the purpose of a vibe check is valuable, so maybe, Josh, you and I were closer than we first appeared on this. What I didn't want to do is to make a final decision, e.g. via FCP, on these in that order, but a vibe check is another matter. Seems worth mentioning, as this does come up from time to time. Josh: +1. ### "Rename "unsized" coercion as "unsizing"" reference#1797 **Link:** https://github.com/rust-lang/reference/pull/1797 TC: We have an ask to rename "unsized coercion" to "unsizing coercion". While I think that major matters of language description are lang questions, e.g. what we decided with "dyn compatibility", I think it would be OK too in this case for us to decide to leave it to lang-docs. TC: My personal view is I feel fairly strongly, after carefully analyzing this, that linguistically it's better to keep it as it is and call it an "unsized coercion". I did an extensive survey of similar uses in the English language, and overwhelming when we're converting things, we tend to use the the noun form (including the nounified form of a verb) of the target of that conversion. I think whoever named this originally did the right thing. This would also be a lot of churn to change. If we were changing it to something clearly better, that'd be one thing. But I don't see it in this case. Josh: There is a distinction between some of these cases in English. When I say "integer corversion" it's clear that that I'm modifying an integer. It's clear that there's no such thing as an integer modifier of the coersion. Tyler: If you consider a case like "integer conversion", it's kind of ambiguous -- are you converting *to* an integer or *from* an integer? Give what Josh said about people not having an intuition of what "unsized" means in this context, I think "unsizing" is more clear because it provides directionality. TC: I understand the point on directionality here. But I did a big survey, and overwhelmingly uses like this refer to the target not the source. Example: "prime factorization" (you're talking about ending with a prime number), "red shift" -- the light is shifted red (we don't say "reddening shift"), "metric conversion" -- converting to metric, "markdown conversion" -- converting to markdown. From an editorial angle working on the Reference, I'm sensitive to trying to hyper-correct this (like "reddening shift" would be) in an effort to be overly-precise. This is already linguistically correct. Josh: I just found some possibly relevant precedent. Seems like the distinction you're making TC is a term used as a jargon vs. a term that's used as a description (in which case is subject to the usual modifications that we apply). At this point, changing "red shift" doesn't make sense because it's a set phrase. But we do have different ways of using the word "unsize". There's a marker trait `Unsize` (not `Unsized`). This follows us calling traits by verbs. Josh: That seems like precedent for having ??. Tyler: I was going to make a similar point. No one says "markdowning", but I do think the direction is a bit ambiguous. But in case of "unsize", "unsizing" is a term we use. And in this case it seems like there is a way to disanbiguate. TC: "Unsize" is a verb and "unsized" is the past participle of it that we use as a noun in some contexts ("unsizing" is also a nounification of the verb in some contexts). We're talking about different reformulations of the verb. And when you look across the langugae, you don't find a lot of cases where you use "ing" in this context. Tyler: But linguistically it makes sense to me. It is an unsizing coercion. TC: But I think about it as as coercion that produces an "unsized" thing. This seems more correct to me too as we have to include the trivial coercion of something that's already unsized. Josh: We should say we're now arguing about verb tenses in English and not getting anywhere. TC: Two meta points. Often, in the these scenarios the thing that's actually better and move us forward is a completely different option. Maybe let's think on that. Second, how do we get this out of our nomination? Josh: I guess nobody cares about this enough to schedule a design meeting to figure this out. I'd venture we have opinions on this and no consensus. Either we keep the status quo or leaving it to the folks working on the Reference. Josh: If we went the Reference route, the set of folks working on the reference should chat about it and decide. Tyler: I don't think we have to resolve everything we time out on in this meeting. But I want the conversation to continue -- and I want to give input on the conversation. I don't want a design meeting though. Tyler: Either we return to it in another meeting or another venue where I can contribute. TC: We can kick this over to the lang-docs side and Tyler you can discuss it with us there if you want. Tyler: I'm happy with that. ### "Stabilize the `breakpoint` function" rust#142325 **Link:** https://github.com/rust-lang/rust/pull/142325 TC: This brings us to the very last thing in our nominated queue (I never thought I'd say that). Josh: The remaining open item is what the semantics of `breakpoint` are. Nobody's argued against wanting the breakpoint or what the docs say. The thing that's led to the arguments is what the semantics of what this mean in the Rust Abstract Machine. Josh: Two broad camps: 1. you could treat this as having a semantic of "flipping a coin and abort or continue.". 2. Treat it as `abort` unless there is some vaguely-defined user intervention. If a programmer inserts a breakpoint somewhere in their program: what can reasonably be said about the correctness of the problem? 1. ? 2. Unless the programer intervenes in some manner, then it will have the same effect as aborting the program. If the programmer does intervene, then the safety is the responsibility of the programmer. Josh: You can say that "intervene in a breakpoint" is an unsafe operation and you're taking on the safety obligation in deciding whether that's correct. Scott: I don't know what "intervene" can mean since it's not a defined term. Josh: I'm not proposing we define what "intervening" means. I'm saying the concept of "intervening" is anything from catching it in a debugger, handling a signal etc. It's an external operation that the programmer is doing. Tyler: The purpose is define an operation specified-enough that we can ship something. Josh, sounded like you had additional goals you'd like to accomplish. Josh: It's a little bit odd to talk about something in a hypothetical Rust Spec when there's one implementation and we're always going to abort. TC: Probably I see this as more than an abstract matter and think there are practical arguments for one or the other: - https://github.com/rust-lang/rust/issues/133724#issuecomment-3010257258 - https://github.com/rust-lang/rust/issues/133724#issuecomment-3010607474 My expectation is that continuing beyond a breakpoint without perturbing the program should not change the semantics of the program. My feeling is that, given how I'd want to use `breakpoint`, that's the most useful semantic, and I want Miri and consteval to run through these breakpoints. Josh: I also think `breakpoint` should be const. If you hit it in const evaluation, the compiler should throw an error and abort. Josh: Re semantics: if someone's reasoning about a program, the question is whether they are obligated to treat the breakpoint in a way that it must continue and must write the program that's correct if you continue from a breakpoint. I propose that continuing from a breakpoint is an unsafe operation. One program might say "these breakpoints are for exploration and you can continue". But another program could insert a breakpoint right before it would dump core. I'm suggesting both are perfectly valid things to do and we should define it that way. Scott: I'm highly opposed to "it can be both and it depends how you define/treat this". There should be two functions in that case because it breaks composability. Then I can have both in the same program. Scott: The other problem I have with you as a programmer deciding ??. If there's no proof of correctness on the language level, then someone writing Miri can say "there's a breakpoint here, we're done". Tyler: Seems we're coming at this from different ideas from what the usecase for this is. I have a clear idea for what I want to use this for -- the same idea TC described. I'm debugging something, hit a breakpoint, my program may or may not continue after that point. Josh sounds like you have other ideas in mind and I wouldn't use the "breapoint" name. Maybe in that case you should put abort after that. Or use abort instead of breakpoint. Tyler: It doesn't make sense to me to define what operations are safe or unsafe in the debugger. The debugger lives outside of the language and you can make plenty of operations in the debugger that are unsafe. The idea that you can safely continue after breakpoint makes sense to me. Scott: I'll just say that even in one implementation we still want to be able to prove correctness of MIR transforms and of have Kani prove your unsafe code correct. Josh: It's difficult to define different usecases. What Scott was talking about, from a perspective of MIR transformation, we want to say that the code may continue so don't make optimizations that would assume it won't. From the programmer point of view, the code will not continue unless the programmer directly intervenes. From the point of MIR optimization, it's important MIR treat it as may or may-not continue. Scott: Then "may or may not continue" sounds like the AM semantics, and anything else is QoI. Josh: Suppose we had a function in the standard library, like `Thread::resume_from_breakpoint`, that would resume the thread past a breakpoint . I would argue that function is very obviously unsafe. That you would mark it as unsafe. And it seems that people are arguing that it should be safe. If it had an `unsafe` that would be correct semantics. TC: From my point of view, a program proceeds in a series of steps. It doesn't matter (modulo timing) how long that takes. Just whether it proceeds from one step to the next. I want to say "pause here" and then continue. It's no different from the OS pausing you and resuming from there. My use of `breakpoint` would be just to indicate that we'd pause at that point and then continue as if the breakpoint were not there. Josh: That sounds like one possible behaviour one might want. But it's not obvious to me that everyone using breakpoint treat it as "momentary pause here". Tyler: That's exactly my expectation here. Josh: From the systems programming point of view is "this is an `int 3` instruction". Having some trouble with the distinction between "quality of implementation" and "abstract machine semantics" here. TC: Another thing that surprises me about your proposal here is the idea that the program would make internal safety contracts about continuing from a breakpoint. This pushes against my idea of safety contracts in Rust. We do safety contracts as interfaces. These would be intrusive. That sounds like C to me. Josh: It sounds like *debuggers* to me. It sounds like we're using `/proc/self/mem`. TC: From my point of view that's not what we're talking about here when talking about proceeding an unperturbed program beyond a breakpoint. Josh: I understand the distinction you're trying to draw and I disagree with it. I disagree the distinction exists. Breakpoint is an operation that's not a no-op. You're arguing that it should always be treated as no-op. TC: Let me ask this. You have a program with no breakpoint inside it. Then you open a GDB and set a breakpoint on some function entry. You stop there, and continue without perturbing the program. Are you arguing this has changed the semantics of the program? Josh: I could write a program that attaching a debugger/breakpoint would break it. TC: Are you arguing that within the AM? Josh: A lot of tihs would be target-specific just like breakpoint is target specific. Tyler: Let's say I put a breakpoint in my program. If breakpoint returns I dereference a null or unaligned pointer and immediately crash. My program is unsound if the breakpoint continues. My argument is: that doesn't make the breakpoint unsafe. It's that I do something bad after the breakpoint returns. It sounds to me that breakpoint might be silly. Josh: I'm not saying `breakpoint` should be unsafe. The *resume* from breakpoint (e.g. by the programmer's hand) should be unsafe. Josh: ?? something somethng about assert! Tyler: What's the utility of that definition? If you define it that way ti means it cannot continue. Josh: I'm very wary of allowing the Spec to call something undefined behaviour because the compiler can do anything. So I want to make sure you can't do undefined behaviour. If you have undefined behaviour of program that returns from a breakpoint. I want to define things in such a way that incorrect code following a breakpoint ?? Tyler: You're saying you don't want code that exercises UB after calling a breakpoint operation to make the program have undefined behaviour. Josh: There's a different between the progrem using UB vs. the program invokes UB along one codepath. If we write something like "if index out of range, abort " and then we write an indexing operation that's defined as UB then the compiler isn't allowed to do whatever it wants on an indexing operation. It needs to output the code as written. Tyler: A version of your argument that makes sense to me. I have this situation I don't believe is possible but it's occuring in my progrem anyways. It depends on this never happening. I'll put a breakpoint in that situation. And I don't want the compiler to optimize away the entire code path that exercise the UB. Josh: Yes. And the compiler can do more than just optimizing it away. "if index out of range { breakpoint; } else { do an unchecked indexing }" is not UB. Josh: This could be trivially written using inline assembly. The reason you don't want to do this in inline asm is a huge config block that check the architecture etc. If you do it in the stdlib, you don't have to look it up. That's why I put it in the standard library in the system. If I'm writing an embedded system and I'm trying to implement abort and my definition of `abort` may be `breakpoint`. If the semantics of `breakpoint` isn't abort, then I'll have to write it myself again. Josh: The original proposal was: "this does something target-specific and we don't specifying". And maybe that would have been better. TC: That sounds like you want a separate `trap` intrinsic. Tyler: Yes we can have abort and breakpoint to have the same implementation. And someone atttaching a debugger can always resume from an abort (which would be UB). They don't have to have the same semantics even if they're the same opeeration. Tyler: Basically, you want to constraint what the compiler is allowed to do. And you don't want the compuler to assume whether the function returns and doesn't return. That sounds to me like a volatile read -- where the compiler knows that this is outside of its purview and it needs to do basically nothing. TC: That was considered in the original proposal but, as Ralf said, we want to minimize the number of places where Miri just has to give up. Tyler: But does it satisfy if we just say that we either continue or not but not modify the behaviour? TC: That's what Ralf is proposing, that the `breakpoint` is a non-deterministic `abort`; specifically, that at `breakpoint`, we ask the environment whether or not we should continue, and we do what the environment says. This implies, of course, that adding a `breakpoint` cannot make an unsound program into a sound one. Tyler: I see the distinction Josh is making here. When I hear nondeterministic abort, I hear we could have a RNG that sometimes continues and sometimes it aborts. That's different. Josh: Deterministic and unknown. I take the volatile read point. But who is to decide what the volatile read would return. It is perfectly valid to say that the semantic of this is to say "do a volatile read and continue if it says `continue` and abort if it says `abort`". Who gets to decide what's a valid return? Miri can say "I decide you're continuing" and I have a problem with that. Josh: What we're arguing is about whether it's valid for miri etc. to make the decision or whether it's only the programmer who can decide. Tyler: I think in almost 100% of the cases, someone writing breakpoint is also handling the breakpoint. Josh: Agreed in a lot of cases they don't. But on some cases they check in. TC: This breaks my model of Rust and of a programming language in general. We're trying to figure out how to interpret the program. Adding an intrinsic that says "you can't usefully interpret the program beyond this point" feels wrong. Josh: I think the correct way Miri should say when it hits the breakpoint: "ah, I should stop here". Josh: In the interest of making of next steps here. If we can find a way to write any variation of "this has a semantic that lets us move forward". I just want to make sure that any semantic we write down isn't a weapon that can be used against me later. TC: I don't think we can just stabilize it with the documentation that's there. As with the `black_box` documentation, we need to be clear on what our language guarantees are. I'm not sure how that intersects with what you're saying. Tyler: I think we might have a common ground that we can move forward on that excludes `const`. If we define it as "this is like a volatile read at runtime" and you can't use it in a `const` context. Josh: I have no objection of defining it that way as long as the consequence of not defining it that way are not someone seeing the breakpoint and deciding to complain to you. Josh: I appreciate TC that you'd like it to be defined in a way that let Miri do something about it. If we can't agree on that, we could say "this does something target specific and Miri can't do anything about it". TC: First, what I see as the critical language question here is whether adding `breakpoint` to an unsound program can make the program sound. Second, regarding agreeing to treat this as an FFI call, that's not an outcome I'd be happy with. I don't think we're doing our jobs if we add intrinsics while punting on what they mean as a language matter. Josh: Is it required for someone who doesn't care about the abstract machine, or do we need to defer that to someone who cares about abstract machine. Tyler: I don't think we have to declare that adding a breakpoint to an unsound program that makes it sound. I think we can say this does something target specific that returns a boolean. And whether that's true/false we will abort. I think we can agree on that. We won't be letting the compiler make optimizations. TC: Are you saying you want to treat this as "when you hit a breakpoint, you ask the envirment whether we should abort or not and then do what the environment says"? tmandry: Yes. TC: I agree with that, but it's not my interpretation that Josh does. Josh: Is this what you said Tyler: ```rust if (ffi_pure_opaque_bool()) { abort(); } ``` Josh: A side-effect-free operation that returns a boolean. Tyler: Yes. Josh: ?? TC: Josh, to read back what you said, you're proposing that in adding a breakpoint to an unsound program, you're not asking for it to make the program sound but you want the program to be indeterminate as to whether the program is sound or not. Josh: Ideally, I'd like it to make the program sound, but I'd settle for it making the program indeterminate. Josh: Concrete example: there was an issue with GCC's optimizer, a while ago, where it observed that the program did something that made it potentially unsound, and then said "well, since it isn't allowed to be unsound, I can assume it's not, and optimize accordingly". Then, it threw away a subsequent check, making the program *more* incorrect. (This is an analogy, to be clear, and the program in question was incorrect, but the optimizer made it *worse*.) ## 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 ### "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" 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 ### "Split up the `unknown_or_malformed_diagnostic_attributes` lint" rust#140717 **Link:** https://github.com/rust-lang/rust/pull/140717 ### "Add `core::ptr::assume_moved`" rfcs#3700 **Link:** https://github.com/rust-lang/rfcs/pull/3700 ### "Closing issues relevant to T-lang on this repo" rfcs#3756 **Link:** https://github.com/rust-lang/rfcs/issues/3756 ### "#[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 ### "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 ### "Add checking for unnecessary delims in closure body" rust#136906 **Link:** https://github.com/rust-lang/rust/pull/136906 ### "Decide on behavior of `anonymous_lifetime_in_impl_trait`" rust#137575 **Link:** https://github.com/rust-lang/rust/issues/137575 ### "Add new `function_casts_as_integer` lint" rust#141470 **Link:** https://github.com/rust-lang/rust/pull/141470 ### "[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 ### "Tracking Issue for enum access in offset_of" rust#120141 **Link:** https://github.com/rust-lang/rust/issues/120141 ### "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 ### "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 ### "RFC: enable `derive(From)` for single-field structs" rfcs#3809 **Link:** https://github.com/rust-lang/rfcs/pull/3809 ### "de-RFC: Remove unsized_locals" rfcs#3829 **Link:** https://github.com/rust-lang/rfcs/pull/3829 ### "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 ### "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 ### "`rustc_const_eval`: respect `target.min_global_align`" rust#142198 **Link:** https://github.com/rust-lang/rust/pull/142198 ### "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 ### "const-eval can construct uninhabited values via recursive static initialization" rust#143047 **Link:** https://github.com/rust-lang/rust/issues/143047 ## 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 ## `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 ### "Add new `function_casts_as_integer` lint" rust#141470 **Link:** https://github.com/rust-lang/rust/pull/141470 ### "`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 ### "#[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 ### "Stabilize `-Cmin-function-alignment`" rust#142824 **Link:** https://github.com/rust-lang/rust/pull/142824 ## 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 ### "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 ### "`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 ### "Closing issues relevant to T-lang on this repo" rfcs#3756 **Link:** https://github.com/rust-lang/rfcs/issues/3756 ### "sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets" rust#123617 **Link:** https://github.com/rust-lang/rust/pull/123617 ### "Add checking for unnecessary delims in closure body" rust#136906 **Link:** https://github.com/rust-lang/rust/pull/136906 ### "Tracking Issue for `#![feature(const_float_round_methods)]`" rust#141555 **Link:** https://github.com/rust-lang/rust/issues/141555 ### "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 ### "RFC: enable `derive(From)` for single-field structs" rfcs#3809 **Link:** https://github.com/rust-lang/rfcs/pull/3809 ### "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 ### "&str and &[u8] have the same layout" reference#1848 **Link:** https://github.com/rust-lang/reference/pull/1848 ## P-critical issues None.