---
title: Triage meeting 2025-12-10
tags: ["T-lang", "triage-meeting", "minutes"]
date: 2025-12-10
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-12-10/
url: https://hackmd.io/zN_Q58egSa685t7YOEm1ZQ
---

# T-lang meeting agenda

- Meeting date: 2025-12-10

## Attendance

- People: TC, nikomatsakis, Josh, tmandry, eholk, Jack, Nadri, RustyYato, Nia Espera, Yosh, dianne, scottmcm, Eric Huss

## Meeting roles

- Driver: TC
- Minutes: Tomas

## Scheduled meetings

- 2025-12-10: Extended triage

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

Niko: Should we schedule a champion update in December? If so, the next week is our opportunity.

TC: Next week sounds good to me.

Tyler: I think that's a good idea so we don't forget everything over the holidays.

Niko: Everyone, please review and update your items.

Niko: We'll go over each issue and discuss it.

***

TC: The Rust in the Linux kernel is no longer marked as experimental. It's here to stay.

Josh: But it's not in the core kernel. That will wait on it being usable for it being on Stable Rust.

Tyler: That's what Miguel said at the conf.

---

Josh: The next Rust in Python meeting will be scheduled on Thursday. We'll focus on technical direction, how we can help, align on the social and organizational aspect as well. These communities are excited to have a lot of cross-pollination.

TC: Are they still early or are they interested in setting up the relationship similar to RfL?

Josh: That's what the Thursday meeting is about.

TC: Is Tomas involved?

Josh: He's on the discord, he's involved.

TC: Have they been invited to Zulip?

Josh: They know it exists, but we haven't invited them directly. We should be explicit about telling that they're always invited

Jack: Their needs may not rise to the level of not needing ongoing discussions and meetings. RfL need a lot of features stabilised but I could imagine this not being the case for this. We need to figure out what they need first and figure out how to collaborate with them.

Niko: Sounds good. I like the idea of making sure they're welcome. If there are any Project Goal-like idea, let's hear them too.

### 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

There are *no more Rust for Linux meetings* scheduled for the remainder of 2025.

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

## Nominated RFCs, PRs, and issues

### "Explicitly export core and std macros" rust#139493

**Link:** https://github.com/rust-lang/rust/pull/139493

TC: I think we're still waiting. The author is looking into it. Let's skip it for now.

### "Permit `include!(…)` in pattern position for completeness's sake" rust#146372

**Link:** https://github.com/rust-lang/rust/issues/146372

TC: I asked Petrochenkov and Jane for thoughts. We didn't get any yet.

Josh: I think we should wait for confirmation but if there's not any issue, I think we should allow indluding Rust code from another file anywhere you can write RUst code

Jack: Looks good. I haven't seen FCP on this. I'd expect FCP on the PR that makes the change.

TC: Yes. Josh, what do you want to do about that?

Josh: The reason I proposed FCP here is: (1) I didn't want to ask people implement this until we have confirmation that we want this. (2) This would be a good opportunity to ping all the rust-lang lang-advisors. It also seemed like a really small change. But we can run the experiment here if people want that.

TC: In other cases, we said that we've talked about this at the lang meeting, we have appetite, if someone wants to create a PR please nominate it for us.

Jack: If this was a big design space, that'd be one thing. But this should be a small implemnation change that would FCPd on the PR. I don't think we need an FCP here.

Josh: I'm all for cancelling this FCP and invite them to submit a PR. Does anyone have an objection for that?

TC: I was about to make th esame proposal.

Jack: +1

Tyler: +1

Niko: The new process I proposed this fits perfectly: you nominate it, if nobody requests an FCP you can go forward (noting that this doesn't represent an FCP consensus)

TC: We also talked about the concept of a meeting consensus. That doesn't represent the whole team but it could work here.

Tyler: The champion process you described does include a meeting consensus.

Niko: The form of objection is requesting an FCP.

Josh: I've already cancelled the FCP and invited the creatino fo the PR.

### "Don't strip shebang in expr-ctxt `include!(…)`" rust#146377

**Link:** https://github.com/rust-lang/rust/pull/146377

Josh: we were waiting on a crater report.

TC: It's finished. Zero regressions.

Josh: How shall we proceed. FCP to make the user-visible language change?

TC: This is not the crater run Jack wanted. Jack wanted a more precise crater run that would fail any shebangs, not just the ones that would break the build. Jack, is this enough for you?

Jack: This doesn't detect any usage of this pattern, but what is the risk we expect there's going to be some subtle bug that compiles and is broken? I think it's minimum. This is fine for me.

Josh: You'd have to have a shebang in the file, it was being stripped, now it no longer is and somehow is parsed as valid Rust now. The only way I can think of making that actually work would be to have a program name equal to an attribute syntax.

TC: I was about to ask whether you can construct a syntactically valid program.

Josh: You can.

Tyler: I think the author wasn't sure whether we should do this change. I'm fine with making the language more consistent.

Jack: The crater run I proposed is more important for item context. That's not for this PR.

Josh: The other rationale for remove this shebang stripping is: having extra logic in `include!` that's not in `include_str!` is surprising behaviour. Especially once we start introducing cargo script. If we ever wanted to go down that road, it'd be a macro that takes a string and runs a macro (??).

TC: Why we wouldn't want to do this: it's weird for macro include to have different behaviour between item context and expresision context.

Tyler: Why is this only for expr context in the first place?

Josh: I think it's incrementalism. The original we were stripping shebang and front matter. In expr context we were stripping shebang and not front matter.

Jack: I have an open concern for the "stabilize front matter" PR for that example.

Josh: And we definitely need a crater run for that. If someone would do an include with a rust file with shebang for it

TC: We want this for the expression context. It's unfortunate that this is a difference between the item context. But we can discuss that later. What do people think?

TC: I'm typing an FCP for that now.

Tyler: So we're not stripping shebang in expr context include.

Josh: It's unlikely you'll have a Rust file with a shebang whose contents are not a Rust program but a single Rust expression. There's a different argument for having a whole Rust program you want to include as a lot of includes. I'd argue for avoiding stripping front matter and shebang in that case.

Tyler: The argument is, you wouldn't have a file with a shepbang that's a valid Rust expression.

Josh: Yes.

TC: Checkboxes are up.

TC: Nadri, what would you do on this one?

Nadri: I agree on not-stripping.

### "Revert "Do not check privacy for RPITIT."" rust#146470

**Link:** https://github.com/rust-lang/rust/pull/146470

TC: Tyler, you updated your summary comment here. You still have an outstanding concern. You aksed petrochenkov to roll a commit into this. He did, no someone tried to kick off a crater run and they didn't do it the right way.

TC: We need to do `try build` first.

Tyler: They probably didn't have permissions either.

Scott: Try builds don't care about tests so if it's just failing test it's still ok.

Tyler: I updated my comment. My concern was to make sure that was accurate. And I think it's now accurate so people checking boxes disagreed with what they thought they were checking a box for.

https://github.com/rust-lang/rust/pull/146470#issuecomment-3583156673

Tyler: TC and Josh, if you want to look at that. I added associated type bounds.

> The type privacy RFC states that due to technical limitations in the compiler, we should treat all occurrences of a private trait in the bounds of a public trait's associated type as an error.
>
> RPITIT is documented in its RFC to behave like an associated type is created for the return type of the method, and it is also implemented in this way in the compiler. This implies that any trait method of a public trait of the form fn method(...) -> impl Private where Private is a private trait should be an error. It currently isn't, and this change corrects that.
>
> Note that we do not currently implement this correctly for the bounds of user-written associated types. @petrochenkov wants to include c5221eb in this PR, which would mean fixing the bug both for RPITITs and explicit associated types.

TC: Scott, it's a build failure in test. Will that screw up the try build?

Scott: No, it won't build the tests.

Tyler: Petrochenkov now wants to include a change that will fix the associated type bounds.

TC: I'm okay with that change. It's an answer to a question I had there earlier.

Tyler: I'll resolve my concern about understanding but file concern about crater run.

TC: Nadri, what do you think about this one?

Nadri: I would have to check it more throroughly.

TC: Niko, waht do you think?

Niko: I agee with tmandry's take. Im' not in love with our model, but I want to see what the breakage is.

TC: Jack, what do you think?

Jack: I'd check a box. The conservative thing here is to restrict and possibly relax it later if needed.

Josh: I'd agree with Tyler's overall assessment. This feels consistent with how we handle type privacy elsewhere.

Tyler: If there's significant crater breakage we should look at it again. If not, we can more forward and discuss it later. I checked my box and filed the crater concern.

### "Stabilize Frontmatter" rust#148051

**Link:** https://github.com/rust-lang/rust/pull/148051

TC: This is waiting on an outstanding concern. epage put up a PR that would resolve one of the concerns

Jack: Two concerns: documenting the current behaviour and the second was do we want to strip the item context shebang.

Josh: I'm inclined to make this a lint. We have lints elsewhere for things like right-to-left override. To make sure we capture code looking differently than what we believe it is. If those are indeed lints, I think it's consistent to use similar lints for CRs.

TC: Jack was talking about shebang stripping. There's already a PR handling the CRs. If we're doing the lint, we shoudl do this for raw string literals too. For consistency

Josh: I agree with the consistency argument.

Tyler: I don't think they're quite the same but we can discuss that later.

scottmcm: Hmm, I thought the reason for the CR thing was to avoid problems with git autocrlf, basically, which is materially different from things like RTL overrides. But agreed with Tyler that we don't need to talk about it now.

TC: Not much we can do now. We're waiting for documentation on the behaviour.

### "Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint" rust#148214

**Link:** https://github.com/rust-lang/rust/pull/148214

Jack: We recently changed `Result<(), !>` to not be must-use anymore. Waffle put up this PR for any `Result<T, !>` where T is not must use for the Result to not be must use too.

Jack: Josh brought up that people may be relying on this today. You can annotate a type as must-use today. So people would have to annotate a newtype. I suggested a crater run, we did it and this comes up in a lot of crates (25k). These are types in which the lint would have fired and would no longer fire. Most people aren't going to be writing a type that's must use and not using it today. But I put a couple examples here:

https://github.com/rust-lang/rust/pull/148214#issuecomment-3603231378

Jack: I couldn't find cases where not using it would cause subtle bugs. But in my expectation it's that not observing the value is a bug (e.g. ignoring error codes). In the cases I saw, not using it may be not implementing a behaviour that you want.

Jack: The first example is an into_iter kind of thing. I wasn't able to address whether Josh's concern would surfase up. But it has a lot of cases coming up.

TC: What do you mean by "it" here?

Jack: Types like `Result<T, !>`, where T is not must-use. They're everywhere. Making those not must use, you would not see a lint where you otherwise would have.

Josh: Jacks crater run did capture cases I was concerned about. I was concerned about must-use catching a bug where the only purpose of a function is to provide a return value. This is useful for e.g. functions that return a copy but people think they would mutate in place.

Josh: I think the `no_std_net` example is a case study of what I was talking about:

pub trait ToSocketAddrs {
    type Iter: Iterator<Item = SocketAddr>;
    fn to_socket_addrs(&self) -> Result<Self::Iter, ToSocketAddrError>;
}
pub enum ToSocketAddrError {}

Josh: This is currently must-use because all `Results` are must-use. We would miss these cases now. I'd love to make this change, I think it's perfectli sensible. But we need to have a transition period for people to mark thething they need. But we also don't have a way to mark a type you don't own (e.g. String) as must-use.

Tyler: You can mark something as must-use by marking the *function* as must-use.

Tyler: If a function returns `Result<T, !>` and you put must-use on a function, does that mark it as must-use?

Jack: The method into_iter is not must-use. It's not used in theterms of "no status changed so make sure that you use it". Is it "you must make sure you use all the types in th efunction" or is this more error codes? If you return a value u32 that's representing error, you want to be able to say that people can check that in compile time. If we want to make sure users don't accidentally use a result then we should do that for any return value rather than just Result?

Josh: We had several PRs couple years ago that added must-use to a massive amount of functions in the standard library. If we could come up with any argument that calling the function would have a side-effect, then we wouldn't do it. In the other cases we've added it. And we've added it to a lot of cases.

Scott:

warning: this function has a `#[must_use]` attribute with no message, but returns a type already marked as `#[must_use]`
 --> src/lib.rs:2:1
  |
2 | fn demo() -> Result<String, std::convert::Infallible> { todo!() }
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: either add some descriptive message or remove the attribute
  = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.91.0/index.html#double_must_use
  = note: `#[warn(clippy::double_must_use)]` on by default

Scott: If we allow must-use on a function to mean you need to look at the result, today, clippy will warn you. So we should give people time time to do that where Clippy doesn't warn you.

Niko; (Side note, If I could go back, I would make *every* type must-use apart from `()` -- we debated it for a while back in the day. A common counterargument was stuff like `map.insert` which returns a boolean but which you can frequently ignore. It never occurred to us at the time to have individual *functions* opt-out though.)

Niko: What I find persuasive is that if I saw a warning about a return value not being used, I wouldn't think to myself "I could remove the funtction call entirely" I'd think there's something about the return value. To distinguish it from idempotent functions. But then I realised we get that by the custom text that you do in the must-use attribute.

Niko: I'm in favor in doing this in general. More precise we can be when doing these warnings the better.

scottmcm: I still think we need to move to having annotations in both directions so we can have more heuristics about warning by default (and *stop* spamming `must_use` all over the place).

Niko: Agreed, for `Result`, and `ControlFlow`.

Nadri: My understunding was: must-use is "don't forget the question mark" and that's very important. I think the intent was about control flow. And we don't need the question mark for the infallible case.;']?'

Tyler: To add to what Niko said: +1 for reducing the noise level. Swift had must-use for everything and then had an opt-out. But Rust is not Swift. But for now we should look at making it as consisntent as possible without the noise.

Jack: Reading the room, maybe the right choice at the beginning was to make everything must-use. ANd we want to encourage peole to not forget they called something and not using it. Given T is not by default must use, maybe we keep this behaviour so users don't forget about it. This will have a big impact and we should think about what we're using. How do we best help users? It's not what we originally expected this. The way to restore this to put must-use on a function, but that's not the case for the 25k crates.

tmandry: Jack: The way to restore that is to put #[must_use] on the function.

Jack: Since Clippy lints against that, it's an anti-pattern today. I'm not necessarily saying we shouldn't do this, but there are implications to it.

Josh: I think we should make the change, but we need a very deliberate transition plan. I don't think we should block in place of adding a more fancier version of must-use that would reach into the type. The only thing we should do is to give people some way to mark all these things must-use before we start giving warnings.

Jack: There's difference between people *relying* on must-use vs. it being helpful. And this is helpful.

Tyler: The actual clippy warning is only if you don't have a message to the must_use attribute. I don't consider this a strong reason to delay this. I feel the argument that this is helping people feels impossible to disprove. That's making me uncomfortable. I don't have a lot of evidence it's helping people. I don't know that people expect this behaviour. We have an existing mechanism that gives people the behaviour they want.

Jack: I expected the crater run was going to give us clear results. I think it made it worse. Everything people said is valid. And it also affects a lot of people.

Josh: This is a gap we have in general in language changes. It's hard for us to prove or get useful metric about bugs that weren't written because compiler caught them because someone saw them in rust-analyzer and fixed them. Or compiler rejected. That code never got written in the first place. But this is great value Rust provides. People are getting a lot of value on must_use on Result. It's hard to know how much value people get on a function that returs a u32. The value is probably not zero.

TC: Tyler, do you want to propose FCP merge so people can start putting concerns there?

Tyler: I like that as a path forward. I'll go and write a comment with my thoughts.

## Nominations, part 2

People: TC, Josh, tmandry, Tomas, Nadri, Eric Huss, Dianne, Jack, scottmcm, Yosh

### "Stabilize the `supertrait_item_shadowing` feature" rust#148605

**Link:** https://github.com/rust-lang/rust/pull/148605

TC: I filed a concern to rename the lint. The PR has merged, I can resolve my concern.

Jack: I wanted to look into why the behaviour between associated types and associated constants is different. I'd expect those to be teh same. I don't feel strongly to block on this but I want people to consider us being careful about this. Especially give you may get different behaviour.

Josh: So your concern is the behaviour difference may be a sign of some underlying issue that's worth looking into.

Tyler: I don't see anything on the table that concerns me. If it were picking the supertrait version in one case and the subtrait in other that would be concerning. I'd be ok with stabilizing as is.

Jack: I wonder if this table is maybe incomplete. But there's nothing completely wrong in the behaviour.

TC: Agreed about stabilizing it. I do want to note that we're setting ourselves up for a lint expansion. It's not linting items and it should be. I think that's OK; I don't think it'll come up often enough to stop us from expanding these lints.

Jack: I looked at th eplyground link. It says the associated constant isn't a value. If we were to use the associated constant as a turbofish, that would error. That's likely the behaviour, but I'd need to write a test. That's a potential future not-consistent behaviour. Sometimes an associated constant would pick a subtrait and sometimes it would be ambiguous.

Tyler: The vibe of the lang team is we should ship this but there are still concerns on the implementation side. Jack do you want to file a concern?

Jack: no concerns from me. Just saying there may be future inconsistencies. I think they'll only show up in MCG when associated constants / const traits will show up.

TC: Jack, are you planning to check a box on this? You're on the list due to the dual FCP.

Jack: Yes, I think I can check a box on this.

Tyler: As long as the inconsistency errors and we can fix it later

Jack: We're safe with associated types. I could imagine there are cases where we can't unambiguously pick a subtrait on a supertrait. And I'd expect you'd get the same for associated constants. That's okay if we say that in value space and name spaces you can subtrait ; but if we say that we want to have associated constants to be consistent that would be a problem.

Jack: This is theoretical, I haven't dug into it yet. Which is why I'm not filing concern.

Tyler: That was helpful. It'd be helpful if you left the comment on here.

Jack: I'll leave a comment.

TC: There's still one pending concern for me. This needs a Reference PR for method resolution.

### "const-eval: always do mem-to-mem copies if there might be padding involved" rust#148967

**Link:** https://github.com/rust-lang/rust/pull/148967

Scott: I think we roughly understood the change correctly, but are we okay with the change in the sense that we said we don't always catch the UB? Or do we want to say there's not UB?

Nadri: Theres' nothing about UB here.

Scott: If you're copying the undef that could cause UB.

Nadri: That's not a question in the issue.

TC: Scott, it's suprising for this reason. There are examples that Ralf has where there's no UB in the program at all. But what the final state and provenance is depends on whether we accept the program. So it affects our static semantics -- what the behaviour of the

Nadri: In a completely valid program with no UB, there's a transition point between const eval and runtime, there's codegen that where we could observe something that the Rust machine doesn't care about but we'd have to reject them.

TC: What's the cost of always zeroing or turning into uninitialised the padding bytes during a type copy? Ralf says this is probably expensive. We're only doing it during const-eval. How expensive is it? It's theoretically doing the right thing.

Scott: A consequence of this is we no longer detect some UB because of how we did the copy. What TC said, if we always re-uninit the padding, we'd detect the UB again.

TC: Yes, in general uninitting padding is better for detecting UB.

Tyler: That makes sense to me. Unless theres' somithing missing. We can ask that question on the thread and come back to it next week.

TC: That makes sense.

TC: I asked the question on the cost previously for both options; this PR answers the question for one of them, I'll reiterate the ask for the other.

### "Promote `uninhabited_static` lint to a hard error" rust#149518

**Link:** https://github.com/rust-lang/rust/pull/149518

TC: I kicked off a crater run, it's not come back yet.

Scott: We said we wanted to see crater to decide whether we want to do warn-in-deps. We should wait for it.

### "resolve: Report more visibility-related early resolution ambiguities for imports" rust#149596

**Link:** https://github.com/rust-lang/rust/pull/149596

TC: petrochenkov has a lang description for the lang team: https://github.com/rust-lang/rust/pull/149596#issuecomment-3620449013

Scott: This is a lint about ambiguity. Since it's just a lint, I'm inclined to say this sounds reasonable.

Tyler: It's a FCW lint, that implies we intend to break it.

Josh: petrochenkov mentions this comes from a glob import. We added support for including two modules with wildcard where we support if both have the same trait.

Nadri: If the items are the same and have the same visibility, the lint doesn't trigger.

Josh: I see, this is only complaining if the two things have different visibility. Nevermind then.

Niko: How can two declarations have distinct visibilities?

Nadri: If you have a re-export in the middle

Niko: I don't think that would change visibility. When I use something, it won't become privat.

Josh: Suppose you have a public module prelude that re-exports `Foo`

Niko: The model in my head: When you declare a thing, you give the broadest possible visibility. And the next question is do you have a path to get there. But once the path is resolved, that's no longer relevant. I'd expect if you have a prelude from a pub(crate)

Josh: Multiple visibilities can effect what's visible

TC: Here's the example in the lint documentation:

#![deny(ambiguous_import_visibilities)]
mod reexport {
    mod m {
        pub struct S {}
    }

    macro_rules! mac {
        () => { use m::S; }
    }

    pub use m::*;
    mac!();

    pub use S as Z; // ambiguous visibility
}

fn main() {
    reexport::Z {};
}

Niko: I think this should work. Independently on whether the macro is there or not. I don't know why it matters whether the intermediate use is pub or not.

Josh: Agreed the macro doesn't matter here. You could get the same result if you had a standalone `use m::S`. The concern is that you do end up with ambiguity because you could have `pub(crate) use S;` and we care whether the thing you're trying to export is not already public.

Niko: When you `pub use` something that's already used. It's surprising these programs behave differently:

mod reexport {
    mod m {
        pub struct S {}
    }

    // mildly surprising that this is an error
    use m::S;
    pub use S as Z; // Error
    
    // but this works
    pub use m::S as Z; // OK
}

fn main() {
    reexport::Z {};
}

Niko: Given that it is an error, I guess it's ok.

Tyler: My intuition agrees with yours, Niko. My worry is we should twist ourselves into knots to report errors we don't want.

Niko: Exactly. It seems that `use` behaves like an item, like a symbolic link. When you use the `use` as a single path, you're getting an intersection of their privacy. That's not how I thought of uses.

Josh: It's consistent with what we do elsewhere. If you have a `pub(crate) mod` with a `pub` item inside that. If you reach out to it from outside of the module and make it `pub use` then it's exported.

Niko: I do see the point that the thing I was proposing would mean you can always reach in any thing you want as public and that's not desirable.

Niko: This is the example I'm concerned about:

pub mod data {
    pub struct S;
    
    pub mod inner{
        use super::S;
    }
}

// data::S; // good
// data::inner::S // bad

...but I guess that if we distinguish "resolving the path" from the "thing you resolved to", then being able to resolve `data::inner::S` is something that occurs at a given location, but if you `pub use` the visibility of what you get when you resolve would just be a function of the item.

Tyler: What it would remove is the ability to reason about reachability of Foo when only looking at the module m:

pub mod m {
    mod inner {
        pub struct Foo;
        pub struct Bar;
        pub trait Baz {}
    }

    // If this is the only place Foo is reachable outside m, I can know that Foo isn't reachable outside the crate.
    pub(crate) use inner::Foo;
}

// Should this be an error?
pub use m::Foo;

Niko: I don't expect `Foo` to be usable from `m::Foo`. It's not about the visibility on the struct. What I'd expect is:

pub mod m {
    mod inner {
        pub struct Foo;
        pub(crate) struct Bar;
    }

    pub(crate) use inner::Foo as Foo1;

    // I would expect `Foo2`
    use inner::Foo as Foo2;

    // I would expect `Foo3` to be accessible
    pub use Foo2 as Foo3;

    // ERROR: Bar can't be re-exported that
    // broadly
    pub use inner::Bar as Bar1;
}

// from another crate:
m::Foo1 // errors
m::Foo2 // errors
m::Foo3 // OK

TC: Yes. I was just writing out a similar example. It's an error today; are we saying we can't think of a good reason for it (I can't think of a good reason for it)?

Niko: It doesn't match my model and I think it's an implementation detail.

Tyler: I agree with your model. But I think it's difficult to change.

Niko: What would break people's reasoning? What you described still works. The end user still has to have a path that's visible to them. And having a path that's visible to them is reaching the item should still be visible to them. I think I'm only allowing declarations that didn't use to compile to now compile. So I think it's backwards compatible.

Tyler: Back to my example (line 552), should this be an error in your model?

Niko: I think it's an error today and it should compile.

Tyler: Do you think that `pub use m::Foo` in the root of my example above should be an error?

Niko: Yes.

Tyler: Whereas `use m::Foo` would work.

Niko:

mod crate {
    mod outer {
        mod inner {
            pub struct Item;
        }

        pub(super) 
    }
}

Nadri: should we take this offline?

Niko: we should. I'll drop this on Zulip and we should get petrochenkov's take.

Josh: we should differentiate how we want to redesign Rust's visibility model vs. whether the proposal is consistent with what's true today.

Tyler: I agree with that in general, but I feel it's a lot of work just to make it consistent.

Josh: This is not just about consistency. Petrochenkov's case is complicated, but we could simplify things by fixing it.

TC: Coincidentally, I was just reviewing the name resolution Reference PR with Jane. Name resolution is very complicated, and it's been petrochenkov's long-running quest to make it less complicated. And I think this iss part of that quest and there are other things in flight that are part of this also.

Niko: That's why we need to talk to him. It may be this model permits more simplifications by correctly taking the original intuition that it doesn't matter how you reach the matter.

Josh: We should do it sooner, but at the latest at the next year's All Hands we need to decide whether we want to do automod etc. That's a discussion where we would benefit from a high-bandwidth in-person conversation, and we should pull in folks like petrochenkov. We've been talking about that for several years.

### "Policy on the use of `rustc_legacy_const_generics` in stdarch" rust#149654

**Link:** https://github.com/rust-lang/rust/issues/149654

TC: We solicited Amanieu to write up a proposal. I almost proposed FCP merge on this but Ralf commented about wasm. My thinking was we probably want to carve wasm out of this and set this policy for x86 and arch64 here

Josh: The policy is under what circumstances people can add new generics using legacy_rustc_const_generics. Not having wasm hear means people still can use the legacy rust const generics, but it needs to be discussed.

Tyler: +1

TC: I'm typing a comment. Let's exclude wasm, and start FCP merge.

...

TC: We're in FCP. We can unnominate.

### "stabilize `cfg_select!`" rust#149783

**Link:** https://github.com/rust-lang/rust/pull/149783

TC: Thanks for Eric Huss for asking some incisive questions. As implemented currently, we don't even parse the branches that are not taken. That makes it significantly more powerful than `cfg`s today. There's pros and cons for that.

TC: The con is you don't even notice syntax errors on the branches that are cfgd out.

TC: The pro is if you think about the use of this something like cfg_version; then you can handle parsing, but not lexing changes.

Josh: I'd expect this to come up often. One thing people use this for is features which may depend on version of Rust. It's notable that it's differt from cfg. Not by design, but bythe nature of the built-in is that it does't even bother to try because it's a macro.

Niko: Lexing is (for better or worse) *absolutely* part of our stable surface area, isn't it?

Tyler: What Niko said. We do expose teh difference where macros are involved. We lex macros but don't parse them.

Josh: Yes. If you think of cfg_select as macro than the this is expected behaviour. If you think of it as a cfg, then it's unexpected.

Scott: When it's just the attribute to know when whatever we're looking at ended. But as long as we have the block aorund it and we have the `tt` we only have to do the `tt` and that's reasonable to expect this.

Niko: I'd call it not unexpected. It's expected that this is possible. But not necessarily what it would do or if it's desirable. I'd say it's undesirable. I think it would be really useful to opt-into this behaviour to handle nightly features. But I don't think it's something you'll want by default.

scottmcm: Historically we've basically only had `#[cfg] mod foo;` for "I want to not parse it if the cfg is false".

Josh: I'd agree in principle there arre often cases where you do want this. I want to raise that more broadly we want access to both behaviours. People will want to have access to both behaviours for regular cfg as well. We want to handle this in a uniform form for both cfg and cfg_select!. And it's reasonable to be consistent here and then add it for both.

Scott: I'm not sure we want `cfg` to necessarily work because the parsing implications can be funky. If you had that on `async fn` before that was stable, you'd expect old compilers would be able to parse and you wouldn't want that. But for this one, is the reason it doesn't parse because we're just taking `tt` becaues we don't know if it's item ocntext or expression context?

Josh: FWIW cfg_if has the same behaviour, I think.

TC: cfg_if is a macro_by_example. How would you write the macro?

Josh: I'd have to look. But you could implement this behaviour both in proc macro and macro just by not parsing. You have to parse the cfgs, you don't have to parse the rest (that could be tts)

Tyler: The macro doesn't have to parse but has to expand to something the compiler can parse.

Josh: I see.

Niko: Based on my reading of the source, it does not.

Nadri: If you don't test your code it will fail in CI. I don't think the issue with not parsing is a big issue.

TC: I'm aligned with what Niko said. I don't think you want it by default but it would be great to have a way to opt in to it. I'd find it surprising for us to not parse all the arms by default.

Scott: Do we care whether it's a hard error vs. lint?

Nadri: Is that imlementable?

Scott: I don't know.

Tyler: I like the idea of making it a lint instead of an error. We should be consistent between config and this macro.

Niko: I agree Nadri in principle. Not *sure* how I feel in practice. I think it might be very annoying. But I kind of hate cfg in general tbh, this is partly why I want where-clause-based portability 😃

TC: The conservative option isto make it a hard error because we can always relax it and make it into a lint later. But if we ship this as is, we've closed a lot of doors. I propose to make it an error and stabilize.

Josh: Making it a hard error and making it a deny-by-default lint in the future seems reasonable.

Niko: I'm ok with that. Long term my favourite option would be not parsing anywhere including cfg. I'd prefer if the parser matched the token tree and then we lint it.

TC: Another thing is it's implemented with an unsuppressable warning. I'd prefer we not do that. I left a comment.

Niko: I'm more or less against unsuppressable warnings under any circumstances.

tmandry: Agreed.

scottmcm: +1.

TC: Another thing is: macros like that really are part of the syntax. They're a Lang concern. It makes me think about how and where we want to document the specification for macros like this.

Tyler: It really is the case that if it's a macro that expands to stable syntax it's not a lang matter. But otherwise it is.

TC: And that plays into deciding on whether it should go to the Reference. Is it a part of a language or not. This is an interesting case.

TC: We'll wait for those things to be adjusted and come back to this.

### "Lint against `cfg({any()/all()})`" rust#149791

**Link:** https://github.com/rust-lang/rust/pull/149791

TC: The author of the cfg any/all RFC proposing to stabilize them.

Josh: This is a common idiom for doing true/false before we had them. Now taht we have them, it makes sense to lint them.

Josh: One reason not to is: Clippy when handling MSRV ??. Do we want to do this in rustc too?

Tyler: Wasn't there a proposal to add that for rustc?

Scott: Using cfg is so tied into things where people are particularly tied into MSRV that it makes me hesitate. And it also isn't that much nicer that everyone should move into it. I don't think it meets the "we should warn about this". It's a fine clippy lint.

Niko: And we've no plans to deprecate it.

TC: +1 this feels like a Clippy lint to me, not like a warn-by-default rustc lint

Tyler: Same here. I do think true/false are more readable. But a lot of code uses these. We're not savinng you from a bug. If cfg(true/false) were out for many years I'd feel differently.

Josh: Personally I see Clippy sandbox test bed for lints. Potentialyl anything in Clippy should end up in rustc. But the question on whether we want to warn-by-default is easily testable.

TC: As it exists today, Clippy has categories such as style lints that don't exist in rustc. In the world as it exists today, I do see clippy having things that aren't necessarily appropriate as rustc lints.

scottmcm: Disagree strongly, Josh, but we don't need to discuss why now.

Josh: FWIW, there's a lot of deny-by-default clippy lints would be warn-by-default. But we don't need to discuss it now.

Tyler: I don't see a lot of cases for allow-by-default lints in rustc. Without some kind of mechanims of "pleas opt me into more verbose lints in general" it doesn't seem too compelling to me.

Josh: How much of this rely on the MSRV question. If we had that mechanism, would folks still object to this as having a lint that uses that mechanism?

Scott: I'm sceptical of the mechanism because of the consequences of the compiler mechasnism. If we paid the cost already it'd be fine. There are cases where we know something is misleading where we push people via a lint to a different function. But I don't think this is that case. It's used a bunch, it works fine. I don't know that the majority of the changes we'd be pushing with this lint would be solving a problem.

TC: Josh, to your question to me this still feels like a clippy lint.

Josh: I suggest we put it in clippy because it has an MSRV mechanism. And we should add an MSRV mechanism into rustc. But we're not doing that so we should defer this and have them come back once we have an MSRV mechanism in rustc. I'll write a response.

### "Add a FRC about implicit numeric widening" lang-team#356

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

Scott: "Frequently Requested Changes" (FRC). It's worth a conversation but not critical.

Tyler: This shouldn't be a drag-1

Josh: +1 this shouldn't be a drag-1.

TC: Now drag-2.

### "Revise decision process: champion vs FCP decisions" lang-team#360

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

Niko: I haven't read al lthe comments. The high level view: (1) we discusesd already: champions nominating things and people having the ability to request FCP if they don't like it.

Niko: (2) proposal around blocking concerns. When you have a blocking concern -- first we should create dedicated issues and resolving it should have a write-up. I'd like to shift it to: the act of resolving a concern should be the write-up. It's also saying that people who raised the concern can't block the resolution. I find giving more freedom to someone to stand up and argue without having all the weight on their shoulders.

Niko: At some point I'm ready to stop talking about an move on.

Jack: +1 I'd eventually like eventually all decisions to be brought to the lang team. But not all of them should be brought up right away. The small ones will be brought up during review eg. The bigger things we can nominate. There's going to be gray areas, but at some point all decisions will be brought up. And it should be as early to not block needless work.

TC: Agreed. There are things I'd have written it differently maybe. But I decided this is OK. What's most important is for this to be simple and legible for people outside team to understand how it works. I'm not worried about us exploiting the process. I have faith in us here -- that's how we operate -- in a collegial manner. This is a great place to start and we can iterate on it.

Josh: I think 95% of this is awesome. The porttions where it interacts with champions make perfect sense. The mechanism having a team to resolve a concern follows what we said a number of times before: if someone's concern has been addressed, it makes sense for the team to resolve it. I still think overriding someones' concern is an issue. But the idea of using the FCP process to resolve a concern is great -- to show how we procedurally addressed the concern. It helps to ratify what today is an informal process of talking about it in a meeting.

Josh: I thikn that makes sense and it would be worth incrementalyl adopting that even if we don't adopt the override.

Tyler: I left some comments to understand the process. I agree with Josh and TC's point about the simplicity and using the FCP mechanism. I want to appreciate Niko moving this forward. It's important.

Tyler: I resonate a lot with Niko saying not carrying the burden of weighing the importance of your concern, whether it blocks the team etc. That's a very difficult position to be in. I'd be happy to say "I made my case". As long as I believe the rest of the team actually understands the concern. And I trust the team to be self aware to do that.

Josh: I fully agree withteh point Niko and Tyler made that this emboldens people to raise concerns without having to worry about whether it's a blocking concern etc. It would encourage people to file concerns.

Josh: I started a discussion on the thread that we could use the process built around rustbot handling multiple directions of consensus. I appreciate that's not our current process even though it's written down. But I'd like to revisit it. I think the process and tooling improvements there are substantial. But it's not our current process so we should avoid confusing people.

Niko: I agree with Josh's point just the second FCP alone does give a chance of "dying on this hill" moment. I see having a value in that. It's hard to predict how it will all play out. I've also seen people not in their best place on this team from time to time and sometimes I'd like there to be a way for us to say "we don't think you're being very rational so we're moving forward". And I could see it either way. I want to sit and think about it.

Josh: I'm in favour of "let's make an incremental change and see how it goes". I've seen the same history you have Niko where things came to a head and should have been resolved in better ways. I think that's more a people problem than a process problem.

Niko: The point is not that they can be solved, but that they shouldn't block us.

Josh: Should we keep the mechanism of being able to dismiss the FCP if someone file a concern and drops it still works.

Niko: That still works.

TC: I don't think we'll go through the full process for most concerns.

Niko: Next step: I'll read the comments. We're in FCP, I'd appreciate checking the boxes.

Josh: With that line removed, I'd check a box today. The issue whether the person raising the concern could participate in the FCP.

Niko: They can file a concern, they just can't block.

TC: It says specifically the're encouraged whether the text resolving it actually resolve the concern. They just can't file a blocking concern.

Niko: I also said they can request a design meeting.

### "Trait method impl restrictions (`final` methods)" rfcs#3678

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

Josh: Seconded. The libs team in particular is waiting on `final fn`.

TC: I'm planning to give it a final read through and hopefully check a box.

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

### "Add `cargo_cfg_target_family_multivalued` FCW" rust#147545

**Link:** https://github.com/rust-lang/rust/pull/147545

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

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