Triage meeting 2025-12-03

--- title: Triage meeting 2025-12-03 tags: ["T-lang", "triage-meeting", "minutes"] date: 2025-12-03 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-12-03/ url: https://hackmd.io/NmlwGpZhRsSmLloytSrCxg --- # T-lang meeting agenda - Meeting date: 2025-12-03 ## Attendance - People: TC, tmandry, Josh, Amanieu, Robert C. Seacord, Tomas, Jack, Scott, Nadri ## Meeting roles - Driver: TC - Minutes: Tomas ## Scheduled meetings - 2025-12-03: 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!) ### Welcoming Robert C. Seacord Hello! TC: Robert is a convener of WG14 responsible for programming language. They own C, C++, Fortran, Ada, COBOL. Robert: I get to decide where and when we meet. I handle the agenda, I get to decide when we've reached consensus. I spend most of my time with newcomers. TC: What got you interested in Rust? Robert: I was doing some consulting work at Meta. They wanted me to review Rust code. I got sucked into the Rust Safety Coding Guidelines. TC: Robert gave an interesting talk about dangerous optimizations of C code. Robert: We had a discussion on zulip about setting up a liaison. Is your organization the Rust Foundation? Josh: The Rust Project. That's the open source project that develops Rust. The Foundation is a non-profit trade association of companies involved with Rust. TC: Robert has a form that might be looking for a legal entity. So that may be the Foundation. Robert: This liaison is a way for our organisations to share information and keep up with each other. We have C and C++ goals to remain compatible with each other. It might make sense to have a liaison between our two groups. That gets you into the ISO directory, ability to attend our meetings (to either give a report or stay on longer). We have liaison reports on Mondays. Fill us in. You can submit proposals, provide feedback. We actively liaison with the Austin group (Austin Common Standards Revision Group), to make sure that things don't disrupt POSIX, etc. You could become a part of the FC22 group, that would let you liaison with C and C++. Josh: There are people interested in Ada. And there are numeric folks who would be interested to talk with the Fortran folks. Niko: This sounds like it may be a good role for Jon Bauman. Josh: That's a great idea Niko. Jon has been talking with folks in the C/C++ committee. The same heads-up you've mentioned with the Austin group -- it would be great if we could have something similar as a head-up for e.g. a new C feature and discuss it before it becoems a standard. Robert: We'd love to have you. We're working on the "defer" feature, "UB study group", "memory safety study group". I recommend filling out the form, saying you want to be a "Class A liaison". TC: I'll introduce you to Jon Bauman and send the form to him for the Foundation to look at. TC: To echo Scott's comment in the chat, we could talk about an Associate Membership to the Rust Foundation. I think the Linux Foundation is one of our associate members. Josh: We could do more formal direct liaison work (e.g. presenting Rust / C to the other groups). But also having folks come to our meetings is something people are welcome to do. Pretty much every Rust team meeting is open to public. People can drop by and listen in. TC: Thanks for joining us here, Robert! ### Guest attendee items TC: For any guests who are present, please note in this section if you're attending for the purposes of any items on (or off) the agenda in particular. ### Moving right along TC: As we've been doing recently, due to the impressive backlog, I'm going to push the pace a bit. If it's ever too fast or you need a moment before we move on, please raise a hand and we'll pause. ### Design meeting at 12:30 EST / 09:30 PST / 17:30 CET TC: Remember that we have a design/planning meeting that starts half an hour after this call ends. ### Next meeting with RfL We're next meeting with RfL today on 2025-12-03 to review the status of RfL project goals. Note that this will be the **final RfL meeting this year** https://github.com/rust-lang/rfcs/pull/3614 ## Nominated RFCs, PRs, and issues ### "Promote `uninhabited_static` lint to a hard error" rust#149518 **Link:** https://github.com/rust-lang/rust/pull/149518 TC: We've done FCW on uninhabited statics for five years. Thisi s a proposal to make it a hard error. TC: How does this fit your metric of having the language simpler? Scott: It seems we've had all the conversations on how uninhabited types couldn't necessarily be empty. In theory you could project into it since the space is static? Josh: TC: We present ZST statics. Josh: This will always be unitialized. You can't initialize anything in this space. Tyler: What about stacics specifically interacts with inhabitness. Niko: It's what Josh sayd: statics need to be initialized with a value. Nadri: ZSTs don't necessarily have to be empty. In generics people may write Scott: We say if you have a `const` item we would evalueate that. You can't possibly evaluate this and produce a value. I'm not sure how to write an expression for such a static. Is it really a hard error or forbid-by-default lint since it doesn't make any sense? Niko: Is there any way to do this? Seems any static that's in the language we don't allow you to have an unititialized static. But extern static we may allow you to do that. In that case sure, that's unsafe for you to access it. Josh: Digging into the code, part of the issue is you can never initialize it. But what's worse: if you have an extern static, you say that it exists, it's already initialized, so it's saying that there's one that's inhabited that's uninhabited. Nadri: If have a safe extern static, that must be a problem. The initial issue that caoused the FCW was someone being surprised. I think making this forbid-by-default makes sense but I don't think saynig that the language forbids this is true. Tyler: Someone on the issue managed to produce undefined behaviour -- they got an address of one of these undefined statics. It's definitely unsound if we allow this. Scott: I don't think it trips my usual check for the language simplicity. But if you really needs this, you should stick `MaybeUninit` there. Especially if it's a safe static, it's UB. We have hard errors for doing UB things in const eval. This is similar. Given that, making this a hard error makes sense to me. TC: So you're saying we'd allow `MaybeUninit` and `!`? Scott: Yes because that's an uninhabited type. TC: There's a procedural reason to not doing immediately. It does'nt report-in-deps and it's warn-by-default. So next step: make it deny-by-default and report-in-depts. Josh: That seems reasonable. And get some reasonable data to confirm whether that creates any new build failures before making it a hard error. Scott: Given we have a PR taht makes it a hard error, should we do a crater check? If that comes back clean I'd be tempted to merge it. Josh: That's reasonable. If it doesn't come clean, we'll take the slower approach. ### "Forbid freely casting lifetime bounds of dyn-types" rust#136776 **Link:** https://github.com/rust-lang/rust/pull/136776 TC: We previously FCPd it. Boxy nominated it again: https://github.com/rust-lang/rust/pull/136776#issuecomment-3606280481 > This change now also forbides extending the trait object lifetime bound when casting pointers to principal-less trait objects: https://github.com/rust-lang/rust/pull/136776/files#diff-92d326ca17db1aa87f44c9e51a0045b40abcda6be64ec1c271b1b29548c2911b. This has not caused any additional breakage. However, there have been more crates since the last crater run which rely on the pattern broken by this PR (see Alice's summary above). > * Is lang comfortable with the breakage still (assuming PRs opened to all crates) > * Is lang comfortable with the slight behaviour change to this PR since lang last looked at it TC: Do you know what the added lifetime constraint is? Josh: Previously it didn't require one lifetimes subsumed by the other and now it is. But this would cause issues with a crate that's doing this with a simple cast. But if you're doing this for a lifetime where you know out-of-band it's okay you could still do that with transmute, just not with a cast, right? Jack: That's correct. Josh: Do we know whether the affected crates didn't declare an outlives bound that but there is one, or they're doing lifetime stunts where they need unsafe casts. Jack: I didn't look at the actual examples. Nadri: One of them was an actual error (they had a `*mut T` to a `*mut dyn Trait + 'static` for non-static `T`). Josh: So we're breaking broken code, that's awesome. Tyler: It looks like people are writing these bugs and the longer we wait to land this, the more crates will do this. TC: What did we originally FCP here WRT lifetimes? What was this before our FCP? What has changed after our FCP? Jack: There's more breakage since last time. And this change now "forbides extending the trait object lifetime bound when casting pointers to principal-less trait objects". So something to `dyn Send` now forbids too Nadri: That seems like something we would have included Tyler: That makes sense Jack: I need to look at the reason why we didn't include it before, I have to read this thread Niko: So before we allowed you to go from `dyn Send+'a` to `dyn Send+'b`? (TODO is this correct?) Niko: What's stopping us TC: This is good to go as far as Lang team is concerned, we should FCP it? Niko: The fact we're seeing more breakages means we should go ahead with it Tyler: TC, that sounds good ### "Tracking Issue for `new_range_api` (part of RFC 3550)" rust#125687 **Link:** https://github.com/rust-lang/rust/issues/125687 Josh: No lang decision needed, nominated to keep lang informed and make sure plans haven't changed. Josh: The Library team is moving forward with stabilizing the new Range API. The iterators are no longer just the type itself. There are separate (opaque) iterators for the range types. In the new edition, we'll change the range syntax to produce the new type of Range and have those in the prelude. Josh: We want to make sure Lang is aware of the stabilization and that the edition plans have not changed. Tyler: I'm happy this is moving forward. Scott: I think this is really good to do. Even without the language changes, people can move to using the new types in situations where they wouldn't be able to before. Josh: One of the reasons we're going ahead is: because the iterator types are opaque so if we decide to optimize the iterators in the future, we'll be able to do this. TC: Do we have someone back working on this? Josh: We had new activity for pushing forward, updating some API updates and renames for the iterator types. tgross is shepherding the name update and pitaj is still working on it too it seems. Scott: How much of this not making 2024 was that making the change would be annoying to the ecosystem and how much Josh: We didn't have a champion pushing this forward, no one wanted to do a last-minute diving catch. It needed coordination between Libs and Lang. Scott: Cool, I didn't know whether there were places that only accepted one kind of range and we'd have to do some migration. The lang piece of changing the `..` syntax is fairly easy on our end. Josh: We evaluated the transition on our end. There will be conversions to/from and the traits will accept both. Tyler: Josh you talked about a champion. I think it would be great to assigng a Lang champion to this. Josh: Since lang advisors can also be champions, Amanieu would you be interested? Niko: Your job is to write monthly updates and bring in any changes we need to know about and be available for questions Amanieu: Sure. I think the impact should be fairly small. Just what `..` resolves to. Tyler: Thanks, Amanieu. I'll add you to the tracking issue. Scott: Is there anything breaking that would look like a good fit to do in lang anyway to fix this, bring that up please too. TC: Exciting to see that move forward. ### "Tracking Issue for AVX512_FP16 intrinsics" rust#127213 **Link:** https://github.com/rust-lang/rust/issues/127213 Amanieu: These are new intrinsics for AVX512 and the blocker is about legacy const generics. I don't remember if there was a final decision on what to do. TC: No there was not Amanieu: Are we happy to have `rustc_legacy_const_generics` where there's are already intrinsics on the target that we use. Josh: +1 Nadri: +1 Josh: We frequently run into this where we have something we want to decide on. And if someone adds three more of the thing that we've got lots of, we don't want to block progress. TC: I agree. This maybe a bit different that our thing on the lang side that we may want to get rid of for language raesons. Compiler people want to get rid of it for implementation reasons. Josh: The issues with `rustc_legacy_const_generics` are understood. This doesn't make the situation any worse or make the migration away worse. We'd already have wide ecosystem breakage to deal with that. Jack: +1 Niko: I want this hack to go away, but I don't necessarily the users to know that we do. A first-class function that would allow const generics in argument position would be a huge win. Josh: +1 Tyler: +1 Josh: Yes. Last we talked to Types, it didn't seem there wasn't anything horrific, there just needs to be a redesign. Niko: If there is big reason for the Compiler folks to get rid of it, maybe we can talk to them and see how to do it in a principled way. Josh: That would be more of a syntactic resolution. Amanieu: It is currently a syntactic transformation. In AST lowering we turn the arguments into a const generic so it appears as a const generic here. Niko: What is the problem exactly, then? Josh: If I understand it, part of this is that it's a syntactic transformation where you first need to look up what function you're calling and resolve it and then syntactically transform that. But by the time you've done resolution you wanted to have the syntactic transformations done already. Niko: I see, ok. Josh: If we defined them as macros back in the day, that would have been better. But we decided them as functions instead. Niko: Ok. We're in the stalemate now and it would be great if we could figure this out and more forward. Josh: It would be great to have lang talk to some of the compiler's folks who understand exactly why this is painful, and co-design something that isn't painful. Tyler: Rust for Linux really wants a stable version of this feature. I'm +1 on finding a way to implement it that's not horrible. TC: Concretely what we're doing is sending a message saying that we're willing to Amanieu: Are we saying we need an FCP on each intrinsic? These are built on top of LLVM intrinsics. Josh: We made a point a while back that while we want to review new swathes of intrinsics that might have lang implications (e.g. new types, new weird semantics), we don't want to be in the way for every new one-off CPU SIMD intrinsic. TC: Amanieu, create a new issue for the policy that you're proposing here and we'll lang-nominate it? Josh: We don't want to change things on an architecture that has zero of these intrinsics to non-zero. ## Nominations, part 2 People: TC, tmandry, Josh, nikomatsakis, scottmcm, Tomas, Jack, Nadri, Amanieu, bendn ### "Tracking Issue for Supertrait `auto impl`" rust#149556 **Link:** https://github.com/rust-lang/rust/issues/149556 TC: This is about implementing supertraits automatically. This is a piece of allowing evolution of traits without breaking. Ding has a PR open to do this. This is a tracking issue for this lang experiment and it needs a champion. Tyler: I'm willing to champion but maybe Taylor would be a good choice too? Niko: Taylor would be fine although I don't think she's been very active. Tyler: Yeah, that would be my concern. I'm meeting with Ding so I can do this. Josh: We also had great collaboration with the types about the new write fmt macro and the takeaway was we should do this early collaboration more often. ### "Explicitly export core and std macros" rust#139493 **Link:** https://github.com/rust-lang/rust/pull/139493 TC: Jane volunteered to look into it. She came back with extensive analysis. Talked to Jane yesterday, found another interesting piece of this: apparently back in 2019 or so, when we moved the built-in macros into being part of the actual macro system, if you had no implicit prelude on a crate, the built-in macros still worked. The compiler made them available. When we moved them to the macro prelude, after 2015 the macro prelude is not included with no implicit prelude. Petrochenkov added a hack, even when no prelude is specified, the scope for within the standard library prelude would exist so you could add these. TC: It seemed that the Lang team never talked about this mechanism. What this PR does puts all the macros into the stdlib prelude and this adds more things into the hack. My suggestion would be to not expand the scope of this hack but to add a rule that we only do this hack for the macros we've already done it for, not for any new ones. Josh: Confirming what you said: I don't think we were ever aware that this hack was needed or appeared. Agreed: let's not add this to any new macros. And can we move away from this hack in the new edition? TC: I agree and I'd be interested in seeing a Crater report to see if we can just rip it out. no-implicit-prelude is not being widely used. Josh: I agree. Josh: Crater run can let us only for crates that match no implicit prelude that would cut out the amount of crates checked massively. Jack: You can also make a list, do the grep yourself and crater will just run against that list. TC: That's a good point. ### "Don't strip shebang in expr-ctxt `include!(…)`" rust#146377 **Link:** https://github.com/rust-lang/rust/pull/146377 TC: This is related to the fornt matter. We ran into a discussion on whether to strip the shebang for `include!` macros. We kicked out a crater run -- it's still running. Josh: We should wait until the crater run finishes. Josh: While we're in the area, there's also a potential improvement here: https://github.com/rust-lang/rust/issues/146372 ### "Permit `include!(…)` in pattern position for completeness's sake" rust#146372 **Link:** https://github.com/rust-lang/rust/issues/146372 Josh: I was intending to kick off an FCP on it and it seemed like a trivial and obvious change. Josh: `include!` parses something as Rust rather than just a string. It's context sensitive, you can use it in most places. You can't currently use it in a pattern context and this would allow it to parse a pattern. Josh: It seems good to include but needs FCP because it's a one-way language feature. Jack: I'd like to hear from the Compiler folks (maybe Petrochenkov) to validate the compiler won't just blow up on this. Josh: You can CC people on the issue. TC: I was about to CC Petrochenkov anyway Josh: Makes sense. ### "Revert "Do not check privacy for RPITIT."" rust#146470 **Link:** https://github.com/rust-lang/rust/pull/146470 TC: We talked about this. Tyler, you filed a concern on this, wanted to check your understanding. Tyler: I wrote the report that I would have hoped to see when this got nominated. Currently if you return impl trait from a function, it's not possible to call the function if the trait trait is private. It's not possible to even name the function. This is making an even more conservative option: if the define a private trait in a public trait, it's a hard error. Does that agree with everyone's understanding? Josh: +1 TC: It's maybe not how I'd phrase it, but I think you're right. I'd frame it that it's bringing it into the line with the general model. The focus here to align with the associated type behaviour and its interaction with opaque types. I agree it's consistent with what you're describing too. Tyler: TC, you're saying think of return position in impl trait as defining an associated type and this brings it in line with what we're doing with associated types. Namely, that the trait bounds shouldn't be more private than the trait. ```rust pub trait Outer { #[expect(private_bounds)] type Inner: Private; } trait Private {} ``` TC: It's an associated type that has an private bound on this public trait. I'm interested to hear what Niko thinks. Tyler: It's only a warning, it's not a hard error. TC: At the def-site or use-site? Tyler: this compiles: ```rust mod m { pub trait Outer { #[expect(private_bounds)] type Inner: Private; fn get(&self) -> Self::Inner; } trait Private {} } fn foo<T: m::Outer>(inp: &T) { let x: T::Inner = inp.get(); } ``` Tyler: I think it's more a capability model. We control whether you're able to get it out of a type or name a type. Tyler: I was hoping fora confirmation from the PR author. If we're on the same page with justification and whaht this is doing, I'm fine with this. I'm sceptical in whether this is what we want long term. TC: So why is it accepted, let's see. TC: What can you leak about the private trait? Tyler: Let's see if I can call a method. ... you can't, the trait's not in scope. You can't really exploit the existennce of a value that implement this trait. TC: You can post this example on the issue and ask Petrochenkov for his analysis. ### "Stabilize Frontmatter" rust#148051 **Link:** https://github.com/rust-lang/rust/pull/148051 TC: I filed some concerns. Ed put up a PR to limit the number of fences to 255. Josh just pinged me on that. The PR merged. Josh: The PR went through so that particular cornern should be addressed. There are still the other open concerns. One of them is about the carriage return thing that we need to make a decision on. And the other is the Reference documentation that has a PR in flight. Josh: The concern about documentting front matter remover can go away if we stop removing the fornt matter. TC: re carriage returns: we should do the same thing we do with Rust string literals, otherwise the behaviour is surprising. Josh: do we disallow CR or lint about it? TC: We disallow it. The grammar is: https://doc.rust-lang.org/nightly/reference/tokens.html#raw-string-literals TC: Looking at the grammar, you can see the exception of the CR there. This is even more important for the front matter which is very line oriented. If you have text, then CR then the fence, should that be a closing fence? It currently won't but in the rendering it would look like a closing fence. Josh: Should CR be treated as newlines (it shouldn't). But: how should we handle for visual ambiguity. Without the raw string literal precedence I'd say we should lint -- we have lints for characters that look like different characters. Raw strings apparently don't parse it that way so we could consider doing either of those. But having a warn/deny by-default lint seems reasonable. Tyler: These are CRs that resolve after CRLF normalization. Josh: Yes, after CRLF you have CR without LF. TC: You can still have CRLFs in the file after CRLF normalization. We only do one pass. I think why we did this for raw string literals is because of things like this. TC: I'd be inclined to do the same thing here. Tyler: Procedurally, what's the ask on us. TC: Procedurally, it'd be helpful to the author that we talked about it and what the lang team's vibe would be. Tyler: What's the current state? TC: It allowes bare CRs currently. Josh: There are reasons why we should be cautious in what we allow and don't in front-matter. E.g. in front matter you may want to write some chunk in Arabic and need a right-to-left override (even though that's disallowed in Rust code). I don't think there's a reason for CR and if there's need for it later, we can add it trivially. Tyler: I see the analogy to raw string literal. TC: It's a matter of grammar of Rust language and the reference. Tyler: There's a semantic ambiguity. If we allow CRs in raw string literals because it might look like a line break, but you print it and it doesn't go back the way you expect. I don't think the same argument applies equally to front matter. There the semantics is of whatever parses the front matter. TC: With the static semantics, it looks like this program should be accepted but it's not. If you `cat` the program and it looks like it should be accepted and the compiler says it should not. Josh: I think it's clear that we should do something about this. The question is: is this a hard error or a warning? But it is some kind of a "heads-up this is something weird". The compiler should when quoting this escaping the CR and not printing it literally. We do that in other contexts where we escape a weird character (e.g. when showing the unicode "smart quote"). We should clearly do at least that much in our error messages. Josh: The next step should be either unconditionally lint on it or hard error on it. But you should never argue with the compilre because we escape the character. TC: You could make the same argument for raw string literals. I still see these as tightly paired. Tyler: What's the connection to raw string literals. How do we handle CRs outside of raw string literals? TC: Syncactically, it's very similar. You've got some finite amount of fencing that sets it off at the beginning and end. It's a close syntactic analogy. Tyler: If the argument is for the simplicity of the Reference let's use the same rules, I'm fine with that. If someone comes back later with a reason for allowing raw CRs, I'm fine with that too. TC: It's definitely a consistency argument. Scott, does that sound reasonable to you too? Scott: Yes. TC: I'll leave a reply saying we talked about it and we're okay with preventing the bare CR in the front matter and if someone has a usecase they can come talk to us. ### "Stabilize the `supertrait_item_shadowing` feature" rust#148605 **Link:** https://github.com/rust-lang/rust/pull/148605 TC: We asked Amanieu to change the name of the lint. There's a PR (not merged yet) for that. Amanieu put up a table of what's accepted and what's not. Amanieu: The name resolution behaviour and the two lints are all inconsistent with each other. You can put types, functions and constants in associated types. If you have the subtrait item shadowing feature, def-site lints will always trigger even for types. The use-site lint only triggers for method calls using the dot syntax despite the subtrait behaviour still applies. Josh: I reviewed the examples and behaviour. We should fix the use-site lint to be consistent with firing every time we actually apply the behaviour. We should fix the def-site lint to not fire where ??. And we should fix the associated types. I pinged the Types team and not stabilising this for functions and constants won't limit the associated types in the future. Josh: We can take time to evaluate this and cleane up the lint. Tyler: I think it should apply to all items equally regardles of the syntax you're using. Josh: +1 Tyler: You do want to be able to separate the subtrait from supertrait. You should be able to name those. Jack: I think that it could be a little difficult on the implementation side. If we're going to go ahead with ambiguous associated type, I'd want that to apply to the associated constants too. Those two should be the same even if the associated functions would be differnt. But I'd need to look for why this is emitting the ambiguous associtated type error. TC: I think it should lint on all of those and it should lint on the constants too. Anything in the value namespace I consider as part of what we're doing in supertrait item shadowing. I'm curious to hear what people think about blokcing this on the lints. I think it's okay to ship the lints later. TC: I think investigating associated types is interesting but I don't think it needs to happen as part of stabilization. Scott: Associated type defaults are unstable. It's always a breaking change to add an associated type. You can add an associated method without breaking. Tyler: If your trait is sealed you could probably get away with that. Josh: I want to highlight both of these lints are allow-by-default. I think we should improve and fix them but I don't think we should block stabilization. I'm slightly more concerned in the def-site lint in the erroring in the associated type -- where we dont' apply that logic. I think we should go ahead with this after getting some review with what Jack's talking about. And improve it in the future. TC: When you're talking about the def-site triggers, you're talking about the ambiguous associated types? Josh: The correct behaviour would be to pick the subtrait associated type. But we can do taht in the future and it shouldn't block shipping functions and traits to solve the problems the standard library have. I want to give Types the time to review TC: Isn't the def-site lint still okay because it's always the error at the use-site? Josh: The lint message would be confusing. It'd tell you about it being shadowed but the real problem is it's going to be an error. TC: We should clean up the messaging. Josh: The mismatch should be fixed ,one way or the other. Tyler: Agreed what Josh said. I don't think we need to block on future expansion or cleaninrg up the lint. Niko: I think we should revisit why associated type defaults are unstable. I'm not convinced they have to be. Josh: I'm assuming you're not suggested we should block on in. Just something we should revisit. Niko: Yes. Josh: I think one of the reasons was they didn't work the way people expected them. Tyler: There's an interesting interaction with opaque types, but those aren't stable. TC: If Niko and Jack check their boxes, then as soon as the PRs are resolved, this will go into FCP. Jack: I'm not quite comfortable wit hchecking my box until I've checked the behaviour. TC: Does it make a difference that in this context constants and functions are in the same namespace? Jack: It sort of does but they have the same implementation code as far as we resolve them. When we do normalization of types and constants, they're more or less equivalent. Niko: There may be a good reason, but it may be an opposite too. Of the top of my head I don't think it should be ambivalent. I don't think the behaviour should be different. Jack: Yes. Amanieu: I didn't write the original code for this so I'm sure why it's exhibiting the behaviour. Niko: I did write the original code for the ambiguity and I don't think I had a very good reason. ### "Experiment request: macro fragment fields" lang-team#352 **Link:** https://github.com/rust-lang/lang-team/issues/352 Josh: Request to experiment with macro fragment fields. Discussed in the RFC a couple times. I'd like to do this as an experiemnt in the compiler. Match a function, any abstract data type. And add initial type support for fragment fields -- what's the name of this function, return type of this function. Goal: avoid having people recreating a parser either in the proc macro (using syn) or a declarative macro (or recreate the grammar of Rust) just to return a function or return type. Josh: I propose the ability to match a function and have the ability to get its name / return type Josh: There's an RFC for this, I'm working with Oli on further ways on making thins work with ?? TC: Sounds good to me, are you the champion? Josh: I'd assume so if that's what people want. ### "Experiment proposal: `Move` trait" lang-team#354 **Link:** https://github.com/rust-lang/lang-team/issues/354 TC: Does anyone have context on this? Yosh couldn't join us today. Tyler: It's proposing to add Move trait to Rust. Would let us iplement `!Move` Josh: First, I'm interested in seeing a fleshed-out proposal to this as it's presenting an alternative to pin ergonomics so we can evaluate both. Second, lcnr apparently was involved in the experiemnt and is the liaison on the compiler side. So I was going to propose lcnr but if Jack's volunteering then that's fine. Jack: I'll be happy to be the official champion. Scott: Happy to see experimentation. Curious how to mix applies-by-default traits with size type question mark. TC: Is there a tracking issue for this yet? Josh: We should respond for that this is the champion and to create a trakcing issue. Jack: Could I just move the issue to rust-lang/rust? TC: Sounds good. *** Josh: Do we have any experiments for linear types? Niko: I kind of view this as part of this. Josh: I don't get the impression it is. Niko: Let me talk to Jack and Yosh to follow-up. That's what I want to champion as a follow-up work. Josh: Trying that experiment would be worthwhile and then making it incrementally better. TC: I moved the issue, we should still refine it. *** Nadri: we noticed the lang-experiemnt about contracts doesn't have a champion anymore since Felix left. I proposed myself as a champion which was approved by Tyler. Nadri: contracts: https://github.com/rust-lang/rust/issues/128044 TC: Cool. Thank you for doing that. ### "Warn on codegen attributes on required trait methods" rust#148756 **Link:** https://github.com/rust-lang/rust/pull/148756 TC: Jack you wanted us to file a concern, we relayed that. Jack: That was addressed and can be removed. TC: Niko I think that's on you, you proxied it. ### "`const` blocks as a `mod` item" rust#149174 **Link:** https://github.com/rust-lang/rust/pull/149174 Josh: Be able to write a top-level const block directly in a module. It allows you to write things like assert in const. I think this is a good experiment to let proceed. Tyler: That sounds good to me. Niko: Are you going to serve as the champion? Josh: I'm not necessarily the best person for this but I could do this in no one else comes up. Tyler: I think you should do it, Josh. Josh: Okay, I'll reply. Scott: I have some questions about the const-block thing but I don't want to block this. ### "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 Nadri: I had objections last time because I didn't know what the ask for lang team was. I clarified tihs with Ralf. We either say we define exactly what const-eval does (executes bytes) -- that's the status quo. The alternative is we specify the behaviour. And then there are further questions on how we want to specify that. TC: Nadri, thank you for digging into this. We have five minutes left, let's come back to this. Josh: Sounds like you're saying the two asks are the two questions you put at the end. One is: if we're just dealing with the final result of cont-eval then it's just an imprementation detail. If we're trying to specify what const-eval does Nadri: That's accurate. ANd the two questions aren't entirely separate. Josh: Do we want to specify const-eval now or do Nadri: If it's an implementation detail we might do different choices than if we want this in the spec. E.g. for impl details speed is more important; for spec, ease of specification may be more important. ### "NFC normalize lifetime identifiers" rust#149192 **Link:** https://github.com/rust-lang/rust/pull/149192 TC: We normalizse these in other identifiers, but we don' do these in lifetimes. This is proposing to do it in lifetimes. Scott: Treating lifetimes as a tick followed by ident and threating them as any other ident makes sense. Josh: I agree. This is a behaviour we've decided in non-ascii-idents RFC, we should treat them the same here. Do we even need an FCP here? TC: This will need an FCP for stabilization. ### "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 ### "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