Triage meeting 2026-01-14

--- title: Triage meeting 2026-01-14 tags: ["T-lang", "triage-meeting", "minutes"] date: 2026-01-14 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202026-01-14/ url: https://hackmd.io/w6mZ7wKkRDivuY6WAtkrQA --- # T-lang meeting agenda - Meeting date: 2026-01-14 ## Attendance - People: TC, Niko Matsakis, Nadri, dianne, scottmcm, Eric Holk, Josh Triplett, Tyler Mandry, Yosh Wuyts, Jack, Chris Sena ## 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. ### 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 meeting with RfL *today* on 2026-01-14 to review the status of RfL project goals. https://github.com/rust-lang/rfcs/pull/3614 ## Nominated RFCs, PRs, and issues ### "Diesel stops building with nightly-2025-12-10" rust#149845 **Link:** https://github.com/rust-lang/rust/issues/149845 TC: We didn't break Diesel. Diesel suppressed our lint about ambiguous re-exports and they had those in their macros. We made the behavior across crates stricter. We did a crater run on the breaking change. 1 (non-diesel) was a hard breakage, 74 were soft breakages (deny-by-default lint, they could unbreak by flipping the lint). A version of Diesel was fixed in December. This breakage goes out on March 5th if we do nothing. What do we do? Do nothing, giving users three months to upgrade or remove the breakage? Tyler: We're not breaking Diesel, just deny-by-default lints and it's been fixed upstream? TC: We're not breaking Diesel, but around 36 Diesel dependents with a deny-by-default lint. Tyler: I assume it's generated by a macro in Diesel? TC: Yes Niko: For dependents, is the expectation to upgrade to a newer version of Diesel TC: Yes. Niko: Are they crates or a lot of github projects? TC: I think it was mostly github. Josh: Top comment from a Diesel dev sounded like this can't be fixed? TC: The top comment was wrong, Petrochenkov fixed it. TC: I'm okay doing nothing here. Compiler wanted us to make a decision. Niko: I'm inclined letting it slide. The fix exist, it's a lint. I'm unconvinced anything will be different thee months. TC: Agreed. Scott: We've done this "this is bad, fixed it in newer versions". If people need to upgrade, I agree with Niko. It would be good to be more specific on the projects that broke. I'm sad lint capping didn't fix this. TC: It's because teh error is at the use-site rather than def-site Scott: Something to think about going forward. Josh: In addition to the github items, there seem to be other instances e.g. diesel-cli which wasn't caught by crater. Petrochenkov suggested doing the split out of the cross crate ambigguous cross import to a separate lint and posted a PR for that. If we believe splitting that out is the right thing to do, I'd split that out and make it deny-by-default one release later. Jack: Why can we not split the lint and wait a release? If it was a lot of work to do that it'd make sense. But this is a really easy fix: merge the lint, wait a release. It's easy, let's not break people. Niko: I'm convinced. TC: The likelihood of it going better is low. Niko: But it won't get worse. TC: It's not cost-free. We'll get another lint, we'll want a lint group, there's a whole treadmill that needs to happen now. That will come back to us, we'll need to do another crater run. We can do it but it's not cost-free. Josh: But it does feel like having a separate lint group and having it present for additional release may help this get caught and flagged. People would update to a new version, see a warning, update the dependency. There is some cost but I don't think it's that bad. Jack: I don't think we need to add a lint group etc. Proposal: just add the lint, wait some time. I don't think we even need the crater run. If we were ready to merge this today, let's not add more complication. Nadri: Why not just weaken the existing lint for a while? That's even less friction than a new lint. Niko: +1 to that. For me, the rationale is not the 36 crates but a major dependency wasn't issuing warnings to their dependents. Now they'll get the warning and have some time. In reality we could get away with this, but giving them some amount of warnings would help. Jack: Whenever possible *and easy*. TC: We're not actually breaking these people. We're issuing a deny by default lint. Niko: It still feels like breaking when you do an update. Tyler: I wish we could do something with the token provenance but that's not an option we have now. I'm fine with whichever way to go. We should make an effort to not break people if possible. I agree with Jack: if it's easy, give people a path forward. Given that we weren't warning, we should do that. Josh: In the top post was another mention that it would be good to have a tooling to import a specific workspace. Would that be useful? TC: It would be useful, but the stdlib uses simulating the namespace and doing a glob. There's a way to express it in Rust but it's pretty ugly. Josh: I bring it up to: should we consider adding some syntax medium term for this? It's been asked several times. TC: I think we absolutely should. It's terrible to suggest people they have to use this workaround. Scott: I'm happy either way here. TC: Which one did we want? Josh: I propose we break it out and let it lag by one release. TC: I do want to ask for this to end up in a lint group. Scott: We want the lint group because we want anyone allowing this want to allow both of them? Or why? TC: I think it's more likely you'll want to deny it. Scott: Who's the customer for the lint group? Niko: presumably people will never want to affect the levels because it'll be a hard error soon enough? Tyler: What's the downside of downgrading the existing lint to warn-by-default instead of splitting? Jack: Is it entirely a downgrade or is it downgrade and also upgrade? TC: There's 2 lints: re-export lint that Diesel suppressed. They didn't see the warning they should have seen. We then had a separate use-site lint which is the FCW that's deny-by-default. If we downgrade the lint it's the use-site one we're downgrading. Josh: Part of the value of splitting out is that Diesel etc. used `allow` on the one that affected only them but that let them miss the lint that would tell them they need fixing. Making them separate puts them on separate timelines. TC: They're separate anyway. The lint for when you *use* an ambiguous re-export but it only fired when you used ambiguous re-export from your own crate. We then expanded this lint so it now fires across crates too. Jack: I lean towards not splitting and turning it into warn-by-default. If that happens, we should make sure the warning is clear that it will turn into deny-by-default. TC: I'm happy with that. Let's ask for the FCW to warn-by-default and remove lint-dependencies. And after a release we'll restore it. Jack: Are we not turning it on for lint-dependencies? TC: There was nothing about dependencies that had anything to do with this as far as I know. The Diese-lside lint is not a FCW. It wasn't linting in deps. We didn't realised this lint existed and we asked for a lint for the dev-site and Petrochenkov told us that it existed already. But that one doesn't lint your deps. Jack: Going from deny to warning for a release seems easy. TC: We'll downgrade the existing lint at the use-site for one release. ANd we're planning to bump this back up one release later. Jack: Can we just say this is our decision (turning it back up)? Tyler: This sounds good to me. Josh: I can summarize this to the issues. TC: Somebody, let's please also check that the use-site lint is also set to warn-in-deps by the time we enable it. Josh: I wonder whether we should set it to warn-in-deps already now (if it's not). We were ready for deny-by-default which means we were ready for warn-in-deps in this case. TC: That's fine by me. ### "Don't try to evaluate const blocks during constant promotion" rust#150557 **Link:** https://github.com/rust-lang/rust/pull/150557 Scott: Looks like there's checking going on in divisions and array indexing etc. to see whether it's going to work or not? dianne: I don't think we need to worry too much about the beta nomination. It was discussed in compiler and should probably ride the normal release schedule. 2 things to discuss: dianne: First, in a previous change (https://github.com/rust-lang/rust/pull/138499) that changed the handling of inline constants for the borrow checker so they're borrow-checked together with their parent. If you try to evaluate an inline constant before it and its parent were evaluated, you end up in a query cycle. And fixing it would require significant complexity and rearchitecture. I nominated this for visibility. During constant promotion there are a couple operations that make sure they result in an actual value we can promote we evaluate constants: integer division and array indexing. Most operations we treat them as not able and we don't promote const-evaluating them. Niko: Is it accurate to say that if this should be promoted the right thing is to bring teh const outwards? We'd do less explicit promoting and bring them out of the block?? dianne: Yes. To fix this you wrap the entireconst expression in a block. These don't currently promote because of the query cycle errors. I don't think we should be doing const eval to determine whether things should promote. Niko: That sounds reasonable overall. Has any attention been put into the diagnostics here? We've been tunig down removening implicit promotions. Do we have any infrastructure for e.g. removing a static bound and turning it into a const expression? Scott: One scare version of this is if you've been turning your reference into a pointer for a round promotion and now your pointer is UB because ??. If const blocks doing this had never worked, is this a new thing that worked before on some release? Dianne, did these const blocks for division and array ever work? dianne: The example in teh PR desecription: they all impylicitly promote in 1.87. In 1.88 they started erroring. Scott: So there is a possibility some onee's been depending on these being static. Nadri: This had a clean crater run. And if relying on this in unsafe should be banned. Scott: This would have been hard to notice and Miri would have been fine with that. I don't think people did this intentionally, but they could have done this by accident and everything would have looked fine. I think it would be good to do it and if we have a clear crater run, that's great. I wanted to ask whether just the division and indexing has to be inside. dianne: You can move the const out to make it work. The only problem is having a `&1 / const block`. If you have a const with a division in it, you're not relying on an implicit promotion. You just have a constant that you evaluate as a constent. The issue with dividing by a const block is that we can't implicitly promote it if the const block evalues to zero. So to know whether we can const-promote is we have to look at the value and so we have to evaluate it. After this we say you can never evaluate a const block and never promote it. Jack: I thought the example should work originally. My opinion has changed. If this is part of a bigger plan, that's fine. I'm also convinced by Niko -- I don't want to do this in the future when we don't have a plan that's visible to people. So in this case I'm fine with the PR but we need to be clear about what we plan to do and that wasn't clear in this case for me. TC: Ralf's been asked for that multiple times. He says "we don't know, that's the whole problem. If we had a plan, we'd have already done it". We know the axioms we're trying to hit but the path there is not clear to us until we run into these cases. I think what you want might be difficult to achieve. Jack: Are these axioms documented somewhere? Is this somewhere in the Reference or unsafe coding guidelines? Where is this plan documented outside of github issues / zulip discussions? When people are thinking aobut whether something should const promote to have an official documentation say that this behaviour is unspecified but these are the axioms. TC: Jack, would you please say this in either the meeting thread or add a new thread and ping Ralf. Jack: I can do that. TC: Dianne, what do you want on the PR from us? dianne: The next step is FCP. Jack: Whati s the FCP exactly? Are we FCPing that we want these things to break? Scott: This PR will make things work that din't compile before that so we need a lang FCP for that. We're accepting that the division will no longer const promote where it did before. Jack: Yes. This did work. Is the FCP that we want it to work? I was confused on what's actually being FCPd to me. Nadri: I feel the only ask is that if we had written down rules of const promotion, this promotes less. That's the FCP. TC: What Nadri said is my understanding. Dianne, does this need a crater one? dianne: I'd assume it doesn't It only turns query cycles to not being cycles anymore. It's not a breaking change. TC: Everything we'd be breaking in this change would already have been broken through the query cycles and now we're adding a better messages? dianne: Yes. And in a lot of cases things that were query cycles before would start compiling now. Scott: If I do addition with the const block, will this still work? dianne: I don't think addition is promotable: https://github.com/rust-lang/rust/issues/124328 Scott: Addition can promote: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=d304de2f2e1f090cdfae65bc06decfb3 dianne: It doesn't require const eval. Tyler: Was this the thing where we panic and runtime? someone: Yes Tyler: What's the rationale for doing that for division vs. the other thing? Nadri: In const you compute the wrapping version and then see if you can use that. For division by zero there's no obvious "wrapping version" Scott: We also give you the arithmetic overflow if it's obvious enough. <https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=348d52cc57e8a1c2f6fbbc4fba7528e6> TC: Dianne, could you put in our minutes a case thats' now allowed but wasn't previously? dianne: As long as the referent of `y` isn't required to live past the current block, this works. Instead of being promoted, this results in a lifetime-extended temporary. ```rust let y = &(1 / const { 1 }); ``` TC: I'll kick off a crater run. I fired off an FCP too. Tyler: What are we FCPing? TC: We're converting query cycles into errors. And letting more things compile. We're FCPing the change to the model. Query errors are not something the compiler can fix anymore FCP link: https://github.com/rust-lang/rust/pull/150557#issuecomment-3750540767 ## Nominations, part 2 ### Attendance - People: TC, Josh, Nadri, dianne, James Muruki, Jack, Tomas, Tyler, Yosh, Niko, Eric Holk ### Meeting roles - Driver: TC - Minutes: Tomas Sedovic ### "Regressions in 1.93.0 crater run: rustdoc errors on invalid `#[test]` attribute" rust#150665 **Link:** https://github.com/rust-lang/rust/issues/150665 Josh: I think this is just a failure to un-nominate. TC: I wasn't sure we've fully answered people's questions on this. Did we? Josh: We could post something more explicit. With the updated relnotes change we'll let it to stand in 1.93 TC: That would be the right thing to do. Then this issue can be closed, right? ### "resolve: Split `extern_ambiguous_glob_imports` to a separate lint" rust#151074 **Link:** https://github.com/rust-lang/rust/pull/151074 Josh: This is the follow-up to what we talked about in the first half of the meeting. This is the split out lint. We've decided to not split out and instead downgrade. ### "Tracking Issue for AArch64 FEAT_JSCVT" rust#147555 **Link:** https://github.com/rust-lang/rust/issues/147555 Josh: A new intrinsic for a new architecture featuer for Arm64 for doing JavaScript conversions from f32 to i32. Libs-API is fine with it and we started an FCP on it. Straightforward, self-contained. TC: I started FPC and Folkert opened a PR: https://github.com/rust-lang/stdarch/pull/1993 Jack: It's interesting. It's target feature gated. We don't have the same stability because if the target feature gets removed if we ever remove the target, that's not something that came up before. Tyler: Are you saying we haven't had an intrinsic gate behind a target feature? Jack: I can't think of one. Lang typically FCPs intrinsics when there's stability guarantee. But this one could go away so there's not the same stability guarantee. TC: Why is this not part of our stability promise? Jack: The target can be always removed. Maybe the target feature cannot? Josh: We do lang FCPs on intrinsics not on the basis of API stability but because an intrinsic is a new core surface area of the underlying compiler rather than a new stdlib function. And we want to check it doesn't have new unexpected memory etc. changes. TC: We have >4 checkboxes. I also pinged Ralf. ### "stabilize `__jcvt`" stdarch#1993 **Link:** https://github.com/rust-lang/stdarch/pull/1993 TC: Related to the previous one. We have four checkboxes here as well, I can un-nominated both. ### "Revert "Do not check privacy for RPITIT."" rust#146470 **Link:** https://github.com/rust-lang/rust/pull/146470 Tyler: We did a crater run and the breakage was considerable. Niko's comment last week: https://github.com/rust-lang/rust/pull/146470#issuecomment-3719782045 TC: We asked for carving out as this things. Maybe the're not dangerous and we don't need to exclude some as part of the model. Petrochenkov said someone should try to break them. I pinged themaathas. Niko: I asked for a better understanding of the patterns and Petrochenkov pointed to his original comment. TC: I think we can ask for more if that's enough. Jack: This came up in many meetings. Every time we bring this up we have 20 minutes of discussion. Is there something else we can be do this? Maybe a design meeting? I feel we're wasting time spinning our wheels to pick up. TC: This would be a great option for a champion to pick up and working with petrochenkov on it. Jack: I don't want to this next week and having it being in the same step. TC: Procedurally, Niko should post his question and then un-nominate it. Jack: I really like the idea of nominating a champion. Josh: I'm not sure reiterating the question is what's needed. Petrochenkov said someone needs to do something. Niko: But the thing he says we need to do is not what I think we need to do. Josh: In that case restating it differently is useful. ### "Support importing path-segment keyword with renaming" rust#146972 **Link:** https://github.com/rust-lang/rust/pull/146972 Josh: We talked about this last week. Dealing with path segments with super and self in them. Gave feedback and said what we'd like to see. It sounds like they're working on that. TC: Can I un-nominate this and would it be clear that it should be nominated for us? Josh: If they do what we asked for, I don't think we need to nominate this. TC: We have an open FCP with 2 concerns so this will have to be renominated to review the concerns Josh: I'll summarize that. ### "Inhibit all-absent-variant optimization for all enum reprs that inhibit layout optimization, not just repr(C)." rust#146989 **Link:** https://github.com/rust-lang/rust/pull/146989 Nadri: waiting on crater TC: We have an open FCP. Concern filed for crater. This needs to come back to us once we see the crater run. ### "Stabilize the `supertrait_item_shadowing` feature" rust#148605 **Link:** https://github.com/rust-lang/rust/pull/148605 TC: We're helping Amanieu. Josh: He's on vacation this week Tc: We'll check when he's back. ### "lint(unsafe_code): exclude unsafe declarations from lint coverage" rust#148651 **Link:** https://github.com/rust-lang/rust/pull/148651 TC: Petrochenkov sent this to lang for vibecheck: > Are you willing to reconsider the decision from #108975 (comment) and not report unsafe fn/trait definitions (as opposed to their uses) in unsafe_code lint? Josh: Related to: unsafe_op_in_unsafe_fn Tyler: If you're declaring an unsafe trait, that's not inherently an unsafe operation. Calling it is. Josh: If I said "deny(unsafe_code)" I'd want to say I don't want `unsafe` anywhere in my code. We could split out an `unsafe_api` for allowing declaring unsafe things. Tyler: on the flip side: inside an unsafe function, do we lint if the trait is unsafe? Nadri: Why does the fact that it's inside an unsafe function do anything here? Josh: The only rationale here is unsafe_op_in_unsafe_fn is ??. But prior to unsafe_op_in_unsafe_fn we implicitly made the body of an unsafe function unsafe. This change is saying that would be unsafe and a way of running unsafe code. In the absence of that lint being forbidden is that the body of an unsafe fn is an unsafe block. Tyler: What is the change we're reviewing. We allow declaring unsafe funcitons and traits when `unsafe_code` is denied, correct? Josh: Yes. With this change you could allow writing a function that has unsafe code but in safe body. Nadri: This PR is suggesting to change the lint fom "I don't want to see any `unsafe` keyword" to Josh: And I'm proposing we'd add a new lint to the unsafe code group if we wanted to do this. Nadri: In which case are you scared to accidentally declaring an unsafe function? Josh: When you want to explicitly say your crate has no unsafe code in it. Niko: If we had `trusted` and `unsafe`, would we feel differently? Josh: If we had two keywords, we'd have likely had two lints. Niko: I agree. Niko: I understand someone not wanted to add an unsafe import to safe functions. It's less of a concern but I can see someone doing it. Niko: I think it's not that unusual to have unsafe things where the code inside is safe. Josh: I could see that happening. But broadly, we have a current behavior for what unsafe code does. Often one of the first things I write is `forbid(unsafe_code)`. And that serves as a design sign post "as I'm developing it, this should never happen". I'm all for introducing a different variation of this if people only want a subset of that. But we shouldn't change the behavior of the existing lint. Nadri: The way I've seen people use unsafe_code is to specifically forbut the use of unsafe. TC: Adding `unsafe` to a declaration actually makes the crate more safe. Josh: that's not true when you are *designing* the APIs. It's useful in designing to say "if any APIs in this crate are unsafe to call, they're designed wrong" Yosh: A perspective: from an effects perspective, treating this as they were two separate keywords would be really nice. Making this a lint group seems like the obvious easy path we could take. Niko: Nadri, what is the benefit we're getting for having a crate with an unsafe API with safe code? Nadri: For me it's the teaching. The distinction is tricky enough. If we're saying the trusted version is the tricky one. Niko: As an analogy, we have a rule that we only make someting unsafe if it can cause UB. Josh: I do think the didactic value you're describing Nadri is useful. That's why I'd suggest splitting the lint into two. We could split `unsafe_code` to `unsafe` and `unsafe_api` and then teach what you're talking aobun via `unsafe_api` Jack: This makes sense but we should also add a lint group for people who don't want an unsafe API. But, what is the benefit at all to having an unsafe trait if you don't have an unsafe block anywhere? Is there any way you can utilize the unsafe in a safe way? TC: Last time, we agreed theoretically with it. But we struggled with coming up with concrete cases where you'd want that. Tyler: If we split this what would we actually call it? I want to call doing something unsafe `unsafe_code` and the other I'd call `unsafe_api`. But if we can't think of something useful, why discuss this? Jack: I can expect a singular function having be unsafe but not having an unsafe block. Nadri: The `TrustedLen` trait in the standard library. It's an unsafe trait that says "I'm an iterator and my len function is trustable". it could be on its own in a crate and have both crates that implement it and crates that rely on it being correctly implemented TC: Yes, I buy it. nikomatsakis: vibes... * Between the case of "a crate that wants unsafe fns but not unsafe bodies" or "a crate that wants neither unsafe fns nor unsafe bodies", I find the latter more realistic and more likely to be what users want. * I *can* imagine code that has an unsafe trait and *nothing else unsafe*, so you've pushed all the unsafety "out" of the crate. But it also seems "weird enough" that `#[allow(unsafe_code)]` on the trait would be ok * And I see the didactic benefit of being precise * And I want to spend less time talking about it -- given that all we were asked for is a vibe check, I don't think we have to reach agreement yet TC: Makes sense. Niko: I can summarize it. ### "Make PinCoerceUnsized require Deref" rust#149218 **Link:** https://github.com/rust-lang/rust/pull/149218 Nadri: joint lang-libs FCP is open. I think we had team consensus but not a lot ob box checked. TC: Yes, we need more boxes. I proposed FCP. TC: What we're doing affects an unsafe trait that has effect on the stable language. We're making a breaking change to remove certain impls to make certain coersions inpossible. Those coersions didn't make sense. To construct the Pin you need a Deref. It made sense to us to get rid of these impls. But as part of the FCP it's making Deref as a supertrait of PinCoerceUnsized. I added that as an open item on the tracking issue so we come back to it. Tyler: I agree with all that. I want to point out from the comments: > You can construct a Pin<*const dyn Trait> or a Pin<*mut dyn Trait> by unsize-coercing from a Pin<&mut T> ### "reduce `unreachable-code` churn after `todo!()`" rust#149543 **Link:** https://github.com/rust-lang/rust/pull/149543 Tyler: We talked about adding a new lint to check for any occurrence of the `todo!` macro. The author tried to implement the lint and had some questions for us: 1. Is todo the right name for the lint? 2. Should it warn by default? 3. Should the lint warn on code outside the local crate (i.e. from an external macro?) and furthermore should the todo-check also take locality into account (I think so)? Josh: (1) yes, let's not bikesched. (2) yes, we discussed in the meeeting. (3) you should get the warning it is included in the macro, not in the point you're calling the macro. TC: Was the lint name `todo`? Josh: Yes. TC: Shouldn't it be named `todos`? We're allowing multiple, we have a policy to name lints in plural Nadri: It feels weird to me to block the PR on the lint. The lint will catch a lot more things that the unreachable lint did. And I'm surprised by the suggestion that this PR is the step towards desugaring to a generic function. I don't think that's correct. Tyler: Nadri, can you sketch out an example? Nadri: would that cause an unreachable lint? ```rust! fn todo<T>() -> T { .. } todo(); some_code(); ``` Jack: Fallback happens after all the types were resolved Nadri: Are you confident that desugaring into a generic function would not lint any unreachable code? Jack: The `unreachable` lint is a little different. That happens independently. It happens when you have any code inthe function that happens after diverging expressions. Nadri: That feels important before accepting this PR -- that we know this is the path forward. Tyler: I agree. Regarding not blocking the PR on the lint, I'd agree but we had the discussion last time and I don't wantto rehash it. The author already has the PR. Tyler: Regarding naming, I'd be okay accepting the current name but would someone understand this being about `TODO: ` comments? Josh: It doesn't really matter what it's called. The one question the PR auothor wrote: does anyone know know what they meant about locality? Niko: I've no idea to what that means. I was about to give a +1 to `todo` rather than `todos` Nadri: For the record I'm opposed to having it warn by default, that's a lot of noise I don't want. TC: We should leave a bunch of comments on the thread and get the answers back for people's question. I like calling it `todos`. `allow(todos)` / `deny(todos)` sounds nice. Tyler: I want to challenge the idea it needs to be plural. We have lints like `unused` not `unuseds`. TC: Unused is not referring to a specific construct of the language. We do e.g. say `allow(unsafe_traits)`. We mean this for constructs. Josh: Nadri's ponit made me think about this: the original motivation of warning this by default was taking away warnings that are useful indicators for missing out code. But I want to recognize there would be a lot of code that doesn't a get warnings there. I'd like having the warning on it every time, but I appreciate if most people don't have that it would be a lot of noise. Josh: In an ideal world, I'd like the warning emitted when there would have been an unused code warning created instead. That's probably not viable Nadri: FWIW, I have 7 uses of todo in my project. For me warnings are things that I need to fix in CI. But todo I'm happy to merge. It doesn't trigger warnings for me. Niko: I personally prefer having todo meaning something I will resolve before pushing this PR. But I'd like to also trigger the lint on `// TODO`. So for this point of view I'd like to call this `todo_macro_uses` to leave space for later. But it seems we're inventing a new use pattern based on Nadri's point. Nadri: There's also a clippy lint that does this. TC: Niko, do I read you correctly that you'd want a lint group? Niko: Yes I do. TC: Me to. Josh: Nadri largely changed my mind here. I feel it will probably reduce the noise. Adding the lint and having it be allowed by default and having a lint group that could be expanded in the future for comments seems reasonable even though I hate the idea of having to enable the lint explicitly. Tyler: I'm happy with that idea. My personal inclination is if I have todo in my code I don't expect it to be checked in. Niko: What is the resolution? Josh: We tell the author to ship as a lint that leaves a name for a `todo` lint group. We say to allow this by default. We ship a release note to opt into to keep the warnings on. And we invite people to write new lints to handle `// TODO` etc. Nadri: Counter proposal: we merge the PR and tell people to use the todo lint from clippy. I want the lint separate form the PR. TC: I don't feel the lint needs an RFC or design. It's within our scope: you don't want this checked into your source code. I don't want this to be representing "you should be checking todos into your source code" Niko: I agree that's what people to think. But Nadri's got a different opinion and I don't know which one is more prevalent. Tyler: I agree with splitting it out. Yosh said that `dbg!` macros is another example that I don't want to check into my repo. Maybe we can have one lint to handle those. I want them to considered separate. Nadri: Agreed. I want it to be considered separately though. Jack: The consensus seems to be driving towards "It's okay to land this and not lint by default". That's against Josh's concernt that I share where we're losing the unused code warnings after todo. TC: Good point. That's why I'd like to ship it together. If you have a lot of things unreachable, you'll lose all this. Niko: By adding this lint suppression we are (incompletely) making a distinction between `todo!` and `panic!`. Thats' persuasive to me. Jack: Should we have a separate design meeting / asnyc discussion talking about what are the differences between `todo!`, `panic!`, `unimplemented!`. Do we want people to not check some of them in? Where's the line? And then let that drive the decision. Josh: Sound like folks are not enthoused in doing this in the PR. Since the aouthor has the PR open, we'll probably land them in the same release. It sounds like we'll probably have another round of this discussion, why don't we defer that? TC: Based on what Niko and Jakc said I don't want it to be in the separate PR Jack: We can allow the lint by default now. It seems everyone wants the lint eventually. And later we can decide whether we want to bump that to warn by default. That would let us move forward. TC: I'm not sure i want to do a lint suppression without this being warnv by default. Josh: Alternative: give them a rough sketch of naming. Tell them what we discussed. Tell them to land allow-by-default now and open a separate lang-nominated issue about warn-by-default TC: No. The suppression is insta-stable. Once we merge it, we're on the clock. Jack: I'm saying there's no supperssion. Just implement whether or not you're allwoed todo. And then in the future decide on warn-by-default and lint suppression. TC: I'm fine landing the lint without the lint suppression. Nadri: I'm okay with the shift in the mental model. I want to highlight that this will affect users. But I'm not strongly objecting to warn-by-default. Jack: It is a helpful POV to share :-) Tyler: By encouraging them to land by default, we're slowing things down. Jack: We already said in this meeting there are cases that aren't caugt by unreachable_code here but people may want to have a lint that warns on todo. Landing this lint now lets us make progress in the future and it is helpful for people in cases where people want. nikomatsakis: My take: * The right thing is aligning on "use of todo = warn, suppresses downstream warnings where possible". * It is weird to do it in a PR, as Nadri said. TC: I there were a proposed FCP to name the lint `todo_macro_uses`, make it warn-by-default and to do lint suppression of `unreachable_code`: (1) are there ane questions on how that would work? (2) would anyone have concerns about that? Niko: My vibe this is the right thing to do. But I want a more visible decision, not just in this PR Josh: I would check that box. I would *also* at this point check the box if it were allow-by-default. Tyler: I think `todo_macro_uses` is design-by-comittee. But I'd be fine doing that. It feels weird to do it in one PR. TC: The long-term would be to have a `todo` lint group that encompasses this. Tyler: That sounds like we're designign a slightly larger feature. Jack: To clarify, Josh you want to see a lint and you don't care whether it's wwarn by default Josh: I felt strongly about it being warn by default, but after Nadri's comment I feel less strong Jack: It's weird to do it all in this PR. I want to see some rationale written down. But this is what I want to end-up in (lint suppression, warn by default). But I want us to be explicit about the choice we're expecting people to be taking. TC: This should update the documentation of `todo` in the standard library. We want to make sure that happens. And we're going to mark this `relnotes`. That will create an issue for the release team and it would be good to end up in the blog post. Are you satisfied with the answers around your divergence questions? Jack: The PR as is doesn't change the divergence behavior. Last time we did talk about making it a function and that would have diverginng differences and requires a separate discussion. Nadri: I'm not opposed what you said. But it feels weird to have it all in one PR. I'd like to see this warn-by-default in nightly, make an internals post and see what people do. Niko: We should just do it and do rfc bot merge. Josh: proposed summary: > * Is `todo` the right name for the lint? We talked about this; we ultimately settled on `todo_macro_uses`. We usually pluralize lints, and we wanted to reserve `todos` as a potential future lint group that might also include a lint for `// TODO` comments. (TC: I already covered this in a review comment, so this can probably be excluded.) > * Should it warn by default? We debated this at surprisingly extensive length. :) Originally we had talked about it doing so, to avoid suppressing some lints that would have helped people notice they still had a `todo!()` in their code before merging that code. However, @Nadrieril raised the point that many current uses of `todo!()` *don't* produce warnings today, so this would make a *new* warning. We're not completely certain yet. Right now, we're coming down on landing it as warn-by-default and getting folks to look at it in nightly to evaluate the impact. (TC: I think this undersells the strength of how far we came down on the side of not doing the suppression without a warn-by-default lint; I'll write up something. Maybe you could leave this section out and I'll post that comment, which I'll draft below.) > * Should the lint warn on code outside the local crate (i.e. from an external macro?) I *think* what should happen there, assuming it's trivial, is that we lint at the point where `todo!()` is written in the macro, not at the point where the macro that calls `todo!()` is invoked; that way, you get *one* warning for writing `todo!()` and not a warning on each invocation. That said, we can refine it further in the future; if it requires any non-trivial further work then please split it out of this PR. (TC: Agreed, ideally, it should only lint at the macro def-site.) > and furthermore should the todo-check also take locality into account (I think so)? We weren't clear on what you were asking here. --- Also, two other items: - This should have a relnotes update. - This should update the documentation of `todo!()` to mention both that this suppresses unreachable code warnings *and* the interaction with the lint. --- Finally, several folks were debating whether this should be in this PR or not. ... TC to insert text here ... --- TC draft comment: We talked about this in the lang call today. There are two pieces here: - Suppressing the unreachable warnings. - Adding a lint about invocations of `todo!`. We talked about how related these are and whether these could be broken apart. There certainly are cases where this would add new warnings not previously present (i.e. when no unreachable code is being suppressed). But for many of us the bigger concern is that the unreachable warnings may be important, and it would feel uncomfortable to suppress these without issuing any lint at all -- letting a project compile clean of warnings due to this would feel wrong. We went around the room, and given this lint suppression, all lang members either wanted the lint to be warn-by-default or were OK with it being warn-by-default (but would be OK with allow-by-default). All of us, though, felt a bit uncertain about doing a change of this significance directly in a PR, i.e. without nightly testing as part of a lang experiment or with an RFC. Both with the lint and with the lint suppression, we're taking a concept that was in our heads -- about how `todo!` is distinct from `panic!` -- and encoding that into the behavior of the compiler. We talked about how, at a minimum, we'd need to be careful that it's fully documented and communicated. The stdlib documentation for `todo!` should describe this conceptual model and describe how `todo!` is distinct from `panic!` in terms of the lint suppression and the triggering of the other lint. Each PR flagged for `relnotes` (as this one would be) also generates an issue for filling out a section for the release blog post. This is one where we'd definitely want to see a blog post section describing the change. Here's what I'd suggest, to the author, to move this forward: 1. Rename the lint to `todo_macro_uses`. 2. Add the documentation for `todo!` for our review. 3. Add, as a comment here, what you would propose for the section in the release blog post. 4. Discuss whether you're interested in testing this out in nightly (by creating a tracking issue for the lang experiment and then landing this behavior under a feature flag) and then putting together a short RFC for it. Even if we might be OK doing without that, doing these steps would make everyone on lang more comfortable with it. ### "resolve: Report more visibility-related early resolution ambiguities for imports" rust#149596 **Link:** https://github.com/rust-lang/rust/pull/149596 ### "Mark const SIMD intrinsics as indirectly stable" rust#149648 **Link:** https://github.com/rust-lang/rust/pull/149648 ### "stabilize `cfg_select!`" rust#149783 **Link:** https://github.com/rust-lang/rust/pull/149783 ### "Do not deduplicate captured args while expanding `format_args!`" rust#149926 **Link:** https://github.com/rust-lang/rust/pull/149926 ### "deprecate `Eq::assert_receiver_is_total_eq` and emit FCW on manual impls" rust#149978 **Link:** https://github.com/rust-lang/rust/pull/149978 ### "Implement lint for black_boxing ZSTs" rust#150037 **Link:** https://github.com/rust-lang/rust/pull/150037 ### "Resolving lang concern on `dyn`-compatibility of `final fn` trait methods (RFC 3678)" rust#150101 **Link:** https://github.com/rust-lang/rust/issues/150101 ### "`#[expect(redundant_lifetimes)]` doesn't work when `#[derive(Debug)]` is present" rust#150553 **Link:** https://github.com/rust-lang/rust/issues/150553 ### "Remove the single-variant enum special case in pattern matching" rust#150681 **Link:** https://github.com/rust-lang/rust/pull/150681 ### "UB inconsistency when derefing a place in a closure" reference#2121 **Link:** https://github.com/rust-lang/reference/issues/2121 ### "Guarantee `repr(C)` union field offset" reference#2128 **Link:** https://github.com/rust-lang/reference/pull/2128 ### "Revise decision process: champion vs FCP decisions" lang-team#360 **Link:** https://github.com/rust-lang/lang-team/pull/360 ### "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 ### "`#![register_{attribute,lint}_tool]`" rfcs#3808 **Link:** https://github.com/rust-lang/rfcs/pull/3808 ### "`RUSTC_ALLOW_UNSTABLE_<feature>`: a `RUSTC_BOOTSTRAP` alternative" rfcs#3882 **Link:** https://github.com/rust-lang/rfcs/pull/3882 ### "CMSE calling conventions" rfcs#3884 **Link:** https://github.com/rust-lang/rfcs/pull/3884 ### "RFC: Exhaustive traits. Traits that enable cross trait casting between trait objects." rfcs#3885 **Link:** https://github.com/rust-lang/rfcs/pull/3885 ### "Complex numbers" rfcs#3892 **Link:** https://github.com/rust-lang/rfcs/pull/3892 ### "Add `cargo_cfg_target_family_multivalued` FCW" rust#147545 **Link:** https://github.com/rust-lang/rust/pull/147545 ### "Add a FRC about implicit numeric widening" lang-team#356 **Link:** https://github.com/rust-lang/lang-team/pull/356 ### "RFC: cfg_target_version" rfcs#3750 **Link:** https://github.com/rust-lang/rfcs/pull/3750 ### "repr(ordered_fields)" rfcs#3845 **Link:** https://github.com/rust-lang/rfcs/pull/3845 ### "Match guard can both move and static-promote a single constant" rust#145237 **Link:** https://github.com/rust-lang/rust/issues/145237 ### "`ref` patterns can const-promote a single constant more than once" rust#145555 **Link:** https://github.com/rust-lang/rust/issues/145555 ### "Uplifts and extends `clippy::needless-maybe-sized` into rustc" rust#145924 **Link:** https://github.com/rust-lang/rust/pull/145924 ### "Decide about future of `rustc_legacy_const_generics`" rust#146613 **Link:** https://github.com/rust-lang/rust/issues/146613 ### "Stabilize Frontmatter" rust#148051 **Link:** https://github.com/rust-lang/rust/pull/148051 ### "Tracking Issue for enum access in offset_of" rust#120141 **Link:** https://github.com/rust-lang/rust/issues/120141 ### "Stabilize the `breakpoint` function" rust#142325 **Link:** https://github.com/rust-lang/rust/pull/142325 ## Project goals ### "Const Generics" rust-project-goals#100 **Link:** https://github.com/rust-lang/rust-project-goals/issues/100 ### "Ergonomic ref-counting: RFC decision and preview" rust-project-goals#107 **Link:** https://github.com/rust-lang/rust-project-goals/issues/107 ### "Finish the std::offload module" rust-project-goals#109 **Link:** https://github.com/rust-lang/rust-project-goals/issues/109 ### "Getting Rust for Linux into stable Rust: language features" rust-project-goals#116 **Link:** https://github.com/rust-lang/rust-project-goals/issues/116 ### "Stabilize cargo-script" rust-project-goals#119 **Link:** https://github.com/rust-lang/rust-project-goals/issues/119 ### "SVE and SME on AArch64" rust-project-goals#270 **Link:** https://github.com/rust-lang/rust-project-goals/issues/270 ### "Unsafe Fields" rust-project-goals#273 **Link:** https://github.com/rust-lang/rust-project-goals/issues/273 ### "C++/Rust Interop Problem Space Mapping" rust-project-goals#388 **Link:** https://github.com/rust-lang/rust-project-goals/issues/388 ### "Continue Experimentation with Pin Ergonomics" rust-project-goals#389 **Link:** https://github.com/rust-lang/rust-project-goals/issues/389 ### "Design a language feature to solve Field Projections" rust-project-goals#390 **Link:** https://github.com/rust-lang/rust-project-goals/issues/390 ### "Develop the capabilities to keep the FLS up to date" rust-project-goals#391 **Link:** https://github.com/rust-lang/rust-project-goals/issues/391 ### "Evolving trait hierarchies" rust-project-goals#393 **Link:** https://github.com/rust-lang/rust-project-goals/issues/393 ### "In-place initialization" rust-project-goals#395 **Link:** https://github.com/rust-lang/rust-project-goals/issues/395 ### "MIR move elimination" rust-project-goals#396 **Link:** https://github.com/rust-lang/rust-project-goals/issues/396 ### "Reborrow traits" rust-project-goals#399 **Link:** https://github.com/rust-lang/rust-project-goals/issues/399 ### "reflection and comptime" rust-project-goals#406 **Link:** https://github.com/rust-lang/rust-project-goals/issues/406