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

# T-lang meeting agenda

- Meeting date: 2025-10-15

## Attendance

- People: TC, Santiago, 0x00x0, Jack, Tyler, Tomas, Amanieu, Josh, Duncan, Yosh, Aapo, Zachary Sample (zachs18), Eric Holk, Urgau

## Meeting roles

- Driver: TC
- Minutes: Tomas Sedovic

## Scheduled meetings

- 2025-10-15: Extended triage / deep dives

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

- T-lang relationship with subteams, and delegation (Jack)
- T-spec discussion awareness/heads-up (Josh)

### Delegation policy

Jack: One thing that came up in the Spec meeting. T-types is delegated a bunch of responsibilities and able to make text changes without involving the Lang team. But the Opsem team doesn't the same thing -- Lang is involved in all the final signoffs. The lang team should have a discussion about why this is different, what's the reasoning and figure out if that needs to be changed. What the Lang team wants from the subteams. How it wants to delegate to the subteams. To what extend it needs to be involved and why.

Josh: Also wg-const-eval, and possibly others. We have somewhat delegated a lot of the area around const-eval and we still do FCPs on the final result. Should it become a T-const-eval and delegate Lang work to them. Right now it seems like more of an accident of chartering rather than a deliberate decision. We should make a more consistent and deliberate decision across teams.

Jack: We should raise awareness that this should be talked about. But without Niko and Scott here it's prudent not to dig into it too much right now.

Josh: We should have a more detailed discussion on policy and delegation among all members of the team. We may need to schedule a dedicated hour to talk through this.

Tyler: Maybe we could do this as a design meeting.

Josh: That may make sense if we can't find extra time. But then we should have a goal.

TC: We can talk about the planning meeting. Or we can pencil it in for one of our deep dives.

### T-spec discussion

Josh: The other item was some detailed discussions in the spec team. About the future of T-Spec and what its responsibilities and future should be with respect to FLS, the Reference. Question on how much T-Lang wanted to delegate to T-Spec that should be re-evaluated. It's important that T-Lang is aware of this. Questions around where does the FLS work happen.

TC: You, Niko and I are of course aware, except Niko wasn't there recently.

Josh: I hope Niko will be back for the Spec meeting tomorrow.

TC: Do you want the meeting tomorrow?

Josh: If we have Niko we should have the meeting.

TC: Even then, there are things you didn't want to raise in the meeting; I feel it's likely to go in circles before we resolve those. We should probably have the lang meeting first.

Josh: That's fair, then we should have a link to the Lang discussion.

Tomas: Link to the latest Spec meeting: https://hackmd.io/1DtwXsv2Q0GZof9wa8QedA

### 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 **next week** on 2025-10-22 to review the status of RfL project goals.

https://github.com/rust-lang/rust-project-goals/issues/407
https://github.com/rust-lang/rust-project-goals/issues/116

## Nominated RFCs, PRs, and issues

### "Lint regression: `dead_code` ignores `#[allow(dead_code)]` on traits" rust#144060

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

TC: We have the PR here: https://github.com/rust-lang/rust/pull/144113. Unnominating the issue.

### "Impls and impl items inherit `dead_code` lint level of the corresponding traits and trait items" rust#144113

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

TC: I checked a box here, and so did everyone else in this room.

### "Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro" rust#145656

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

TC: We're waiting on Scott.

Josh: And it's a joined FCP.

TC: And Libs-API changed membership so we'll need all the checkboxes.

Josh: I think it's worth pinging The 8472.

Amanieu: I'll go check Mara's box.

Tyler: I think it's possible to edit a checked box to mention that Amanieu checked it.

### "Uplifts and extends `clippy::needless-maybe-sized` into rustc" rust#145924

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

TC: Finished FCP but it's still nominated. Someone brought up they would prefer to split it to two lints. One for when you're redundantenly stating that it is sized and the other where you redundantly state that it's not sized.

TC: If we did that, we should rename the lint and maybe create a lint group.

Josh: Is there a comment that succicntly shows the two cases people want to split apart? What those two cases were?

Tyler: The examples in the PR show both cases.

// `T` cannot relaxed the `Size` bound because `Clone` requires it to be `Sized`.
fn f<T: Clone + ?Sized>(t: &T) {}
// `T` must already be `Sized`, so the bound is redundant.
fn g<T: Clone + Sized>() {}

Josh: That makes sense. The former seems much more important than the latter. It seems more rare that people name Sized when it isn't.

TC: Looking at it this way, you end up calling for broader lints in both directions. You're saying you've stated a supertrait explicitly that's implied by a subtrait that's in the bounds. In the other direction the bound is ignoring a relaxation because a supertrait is implied by the trait you put there. As we're planning to go in the direction of meta sized but multiple different sized things, it ends up becoming a general matter of "sizedness".

Josh: I'm wondering if we should *also* lint on `T: Ord + Sized`, insofar as unless you write `?Sized` you *already* imply `Sized`?

Josh: I'm indifferent whether that's one lint or two, we should turn them both on by default.

TC: My proposal is we're happy with this FCP as it is. If someone wants to make a proposal to cover these as a lint group, we can do it later.

Josh: +1 for providing an interface for all of them together and if someone wants to split it later, that's fine.

Josh: It would be worth confirming why people want to split them -- whether they want to keep one on and the other one off. I'd assume the idea is that we want both of these be warn by default.

Tyler: I'm fine with the proposal.

Josh: I could be convinced to work our way to `deny` for the one where one states something that's not true.

---

TC: Looking at this again, it seems less clear cut to me.

Jack: I think the current state ignores Sized bounds and only looks at `?Sized`. I think for this lint it just looks at `?Sized`.

TC: Interesting. That's not what we understood.

TC: If this only going in one direction then it resolves the concern people had. But then we want, I think, to rename the lint. It's called `redundant_sizedness_bounds`.

TC: Should we just make this more general in both directions and have a lint about "unused relaxations" or something like that?

Tyler: There's only one bound you can relax today. Are you proposing to generalize the name?

TC: It'll be sized related but when we do the meta sized, it'll be multiple relaxed things. And this is pointing towards that sort of work.

Tyler: So you're proposing that we rename the lint, change the lint behaviour or both?

Jack: I think the name "redundant-sizeness-bound" is okay. Starting with just linting against `?Sized` bounds is okay and it can be expanded. Regardless whether it's only expanded towards relaxing or also `T: Sized`. I'd expect this will eventually work for meta sized and stuff.

Tyler: We still haven't decided what we're calling the other traits yet. They'll probably have the word "sized" in them. So I'm fine with the name as it stands personally.

Tyler: The question is: if it's called that, should it also lint on unnecessary positive bounds.

Jack: Let's assume we want the lint to lint on the positive bound. Does that have to make it in before the relaxed (negative) bound? I'd say no. There's still plenty usefullness to landing this.

Tyler: That makes sense. So what I understand TC saying is if we never end up doing that, we should relax the lint. I guess that name sounds harder to bikeshed and gives us more flexibility to add in the positive bounds later. And turn it into a lint group. So I'm happy with the PR as is.

TC: The proposal I was going to make was canceling FCP on it, because we were unclear on what exactly we're FCPing here, and solicit proposal form people to generalize this.

Tyler: I'm fine with it as it lands. We can add the positive bounds later and if people want to split that out into a lint group, we can do that later. It is different than what were approving but I'm happy to approve still.

TC: What if we end up generalizing the positive side of this into something like "redundant sized" lints. Then the lint group wouldn't cover that. The positive case doesn't need to be specific to `Sized` bounds, we could lint against any such supertrait relationship.

Tyler: So your point is, we're using a lint name that does more than the lint does and we may end up leaving it that way. I can see that.

overridden-sizeness-bounds?

TC: I want to cancel my FCP proposal, then take some time and come up with a better name (maybe that one above), and then repropose it. Does anyone have an issue with that?

Tyler: In either case, if it changes we're probably going to restart to. I don't want to object to that.

Josh: If we're not clear on what we're agreeing to, let's revisit. Support.

### "Stabilize 29 RISC-V target features (`riscv_ratified_v2`)" rust#145948

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

Josh: We need either Scott or The 8472 (or BurntSushi) to check their boxes.

### "FCW for repr(C) enums whose discriminant values do not fit into a c_int" rust#147017

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

TC: All of us checked a box. And then Ralf said, "wait, I asked you guys questions".

Tyler: Link to comment: https://github.com/rust-lang/rust/pull/147017#issuecomment-3369058256

Josh: I think we did answer the question 1. We didn't answer the second or third questions. C gets a little fuzzier about unsigned vs. signed. That would cause us to warn in 57 cases on crater instead of 3. Sounds like there are 54 enums where the values overflow unsigned int vs. signed int. They have the same bit values in memory that could be an issue if we were to cast it.

Josh: What do we think about warning in dependencies vs. only if you're responsible for the enum in your crate.

TC: What does it do in the PR? Looking, it doesn't warn in deps.

Josh: I think report in deps is the right answer.

TC: Are we going to end up bumping this to deny?

Josh: I expect to bump this to hard error because we'll change the behaviour so this stops working.

TC: What I like is that we start by issuing a FCW as a warning, then we bump it to deny by default and warn in deps. So that's what I'd lean toward here. Issue the warning now, and send us a PR later to bump both.

Josh: I agree with this proposal.

Josh: I think this will depend on the last question. Depending on how many cases this causes.

Tyler: I like the idea of pairing FCW with deny by default. That seems like a good pattern in general. Whether we do this here is an empirical question, is anyone impacted by this.

Josh: For the third question: if you put a 32-bit unsigned value and it's not at all uncommon to use an enum as in C -- to use an enum to define constants. In our code we interpret that just fine and make that work. On 32 bit we'll say it doesn't fit in isize and we end up with enum where the values are `0` and `-1`. And we end up picking a different underlying type (`i32` instead of `u32`) and that's problematic. And then if you `as` cast this to a larger value, you'll get a signed larger value.

Tyler: So right now we're implicitly accepting an overflowing value.

Josh: Not implicitly. We issue a deny by default lint. But if it's ignored, it will wrap and get a `-1`. Having a lint flag this makes sense. But I think the behaviour should be: this fits in an unsized value so we should fit it in an unsized.

Tyle: If the answer was that easy, I feel Ralf would have proposed.

Josh: Right now it's an accident of is: we do the math in `isize` and we decide what type this will fit into. In 32 bit, they both don't fit in 32 bit isize becausee one of them wraps. That produces a lint and if that's ignored, we use i32. I think we should do a math in a fashion of: both of these fit into u32 on a 32-bit platform so we should fit them in u32. We should check what C does, but I think in C they have both the same pattern and and C doesn't care about the enum discriminant -- it will become signed or unsigned depending on where you stuff the value. But in Rust we care whether it's signed or unsigned because we care about the discriminant value.

Tyler: Rust shouldn't surprise you and create a signed value from an unsigned.

Josh: And it should not do something different on a 64 and 32 bit platform.

Josh: I think we should warn in that case. But the correct behaviour is for us to infer u32 as the wrapper size on all platforms. We could warn about it to say this is what we're doing. And that it's a change in behaviour from earlier versions of Rust. And warn (not in deps) to let people know they should use a `repr` if they disagree.

TC: To confirm, the exact problem is this:

https://github.com/rust-lang/rust/pull/147017#issuecomment-3365456860

#[repr(C)]
enum E {
  A = 0,
  B = 0xffffffff,
}

Josh: A `repr(C)` enum with discriminant that has a value higher than the signed discriminant.

Josh: I think we should treat this as a bug. We should also warn that if you wrote ??

TC: You're proposing that for this code we should infer unsigned and we should treat the bugfix as this should always have been doing this.

TC: Is this only for `repr(C)`?

Josh: I think it's for `repr(C)` because that specifies the discriminant type. I think in `repr(Rust)` does the right thing.

TC: Are you allowed to care about it with `repr(C)` (without a discriminant specified)?

Josh: The expectation is that the value should be exactly what you'd get for the same enum in C.

Tyler: I think we should do what the PR does and answer Ralf's question.

Josh: I think we should let Ralf know what we're thinking and see what he wants to do there. For FCW we should warn on the case where it's not fitting into u32. And then we should fix the bug of not fitting into u32.

Tyler: That sounds fine to me.

Tyler: This is coming in RfL too.

TC: Do we need to warn when we're fixing the bug?

Josh: I think we should fix the bug, but it's a change to the language so we want to show a warning that we're changing this.

TC: Do you want to warn after this even after we ship the fix?

Josh: I could see both.

TC: I think we should say we want to fix the bug and then solicit a path forward.

Josh: I think people could be surprised by this. If you took one of these enum values and cast it into an i64, do you get an unsigned int::MAX or `-1`? Both fit into i64 so the question is which one do you get.

TC: By virtue of us declaring it a bug, the wrapping behaviour is not what anyone should have expected.

Tyler: We already have a deny by default lint (not warning in deps). If we added that lint after this code was released, the author of the code isn't going to see it. And the dependencies won't see it. How long have we had this deny by default lint?

Tyler: I think we can ask Ralf. Say this is a bugfix and how he wants to proceed.

TC: We could let him propose it to us at least.

Josh: I'll write up the fact that we consider the behavior to be a bug and ask him for what he proposes to do after fixing the bug.

Josh: We've answered the fist question and that's what we were FCPing here.

Tyler: This is to fix an issue where depending on which C compiler or C standard we're using, the behaviour will change. This is asking about us being explicit. Whereas the third the question is just a bug in rustc.

Josh: After we post these comments, you can resolve your concern.

### "Add warn-by-default lint for visibility on `const _` declarations" rust#147136

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

TC: There's a proposed FCP. Scott and I checked the boxes. Scott said:

> I think this seems fine to warn on from the perspective of "don't write things that you don't need", though probably with the usual "well if it came from a macro it's fine" kinds of limits because if the vis or ident was passed-in then complaining about it might not be worth it.

Josh: As long as we don't warn about the macros, then sold.

TC: Jules proposed we'd FCW it; scottmcm analyzed why we probably don't want to do that.

Josh: I agree we shouldn't be FCW it. While this is redundant, but we're never going to stop this working, we're not going to change behaviour, it's just redundant.

TC: The case Scott mentions generally is that we issue an FCW when we're trying to simplify the language. That's not the case here.

Tyler: Agreed, I'm checking my box.

### "repr(transparent): do not consider repr(C) types to be 1-ZST" rust#147185

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

**Comment:** https://github.com/rust-lang/rust/pull/147185#issuecomment-3393329466

Josh: What about the case where you do have a zero-sized `repr(C)` struct? That's being covered because there's some issue with not having zero-sized structs on some platforms. Probably need more time for context.

Tyler: `repr(transparent)` only works if you have one time and all other types in the struct are 1-ZSTs (1 means alignment=1). This is saying if ZST is `repr(C)` we should never reject this code. Whether

Josh: `repr(C)` types can in theory be zero sized in some circumstances. But that's a different issue. In some circumstances you can have an empty struct in C that is zero sized.

TC: Is the idea that these `repr(C)` 1-ZSTs are 1-ZSTss on some targets but not all targets? So you can't rely on them being 1-ZST?

Josh: That's part of it. The other is that even if they are 1-ZST, it's unlikely that someone would put them on a repr(C) type.

TC: Ralf has four questions for us.

1. Should we phase out repr(transparent) ignoring repr(C) 1-ZST fields?

2. If yes, should we do this as part of the existing repr_transparent_external_private_fields lint (under some new name)? If it should be a new separate lint, please specify how exactly the two lints should behave. Specifically, which lints should fire for a repr(transparent) type that has a 1-ZST non-exhaustive field, a 1-ZST repr(C) field, and a non-ZST field? That type would only get rejected once we make both the non-exhaustive and the repr(C) restriction into hard errors, but we have no good way to fire a lint only if both lints are enabled, and the logic to disentangle these cases would become quite messy. It just doesn't seem worth it for something that so few people will even see.

3. What should the new lint (combined or not) be called?

4. Should the lint fire in dependencies immediately? Even for the combined lint, crater found only two rarely-used old crates that would trigger it.

Josh: In order: Yes, Yes, Don't care, Yes.

Tyler: We probably can't reuse the existing name.

Josh: I agree with Ralf's point where if we're not careful, people may be in a situation where people enable one and not the other. And we want to prevent that. The existing name could be a transitional name for the new name, so we only have one lint.

Tyler: External struct with a private field is another case. Or external struct with non-exhaustive. Yeah, ok. Agreed with all of your answers. Just need to come up with the name.

Tyler: Since we're doing FCW, I think the plan is to break this eventually.

Josh: The first point implies that: yes, we want to phase this out.

TC: For 4, are we starting this warn by default or starting as deny?

Josh: I'd argue for warn. I don't think we should jump directly to deny.

TC: In that case I want to raise the same point as the previous issue. Do not warn in deps initially.

Josh: It sounds like you felt you should not warn in deps right away, but in the previous one it sounded you said we may as well warn in deps.

TC: We should warn without warning in deps. At the point where it makes to warn in deps, it makes sense to deny by default as well.

Josh: And is that what you're suggesting we wanted on the earlier issue `repr(C)` enum discriminant issue.

TC: Yes.

Josh: I see, that wasn't clear to me.

Tyler: I'd argue we can jump straight to deny-by-default. At the last run they only ran into two crates.

TC: Works for me.

Josh: No objection.

TC: Okay, that's our answer to 4.

TC: For the first one we agree the answer is yes.

TC: For 2, if yes, should we do this as part of an existing lint, what do we think?

Tyler: Josh suggested making it one lint and I don't really care if it's combined. And it sounds it's much easier if it's combined.

Josh: That's a pretty fine-grained suggestion there, so I'd argue having a single lint handle all cases and then find the name work for both. And make the existing lint be the alias to that lint.

TC: So we're happy to extend the existing lint, but we want to find a more accurate name.

TC: So the existing lint is `repr_transparent_external_private_fields`. What do we think are some good names?

- Tyler: invalid_repr_transparent
- Josh: repr_transparent_future_ineffective

Josh: When we phase this out it will become an error. Should the lint imply that it's currently wrong or imply that it will become wrong in the future?

TC: I don't think we imply the FCW-ness in our lint names in general.

Josh: It's not FCW, it's that repr transparent isn't currently invalid/ineffective but it will be. We could say `repr_transparent_ambiguous` -- there's more than one field, it's ambiguous on which one to choose.

Tyler: All of our FCW are saying that something's going to break in the future and I'm not aware of any lints that have "future" in them.

Josh: Agreed, "future" is not the right name. Can we find a word that describe that it's currently accurate, but will not be?

TC: `repr_transparent_bad_fields`? They're not necessarily invalid (yet), they're just... bad.

Josh: That reminds me of how we named "bad_style" to "nonstandard_style". But maybe that works here?

Josh: maybe `repr_transparent_deprecated_fields`?

Josh: The current one has "external_private_fields". It also covers "non exhaustive" where it might have an invalid field in the future. Is the problem "not_guaranteed_zst"? The problem is it's not guaranteed that the other fields will be ZST in the future.

`repr_transparent_non_guaranteed_zst`
(possibly with `fields` thrown in)

TC: Does that cover the external private case as well?

Josh: It does. Because due to non-exhaustive, there may be a non-zst field to be added in the future.

TC: What if we dropped the "guaranteed". `repr_transparent_non_zst_fields`? What we're saying is that these fields are not necessarily ZSTs.

Josh: I could buy that.

Tyler: I also think this is fine.

Josh: I didn't find anything better in the thesaurus.

*everyone agreed on `repr_transparent_non_zst_fields`*

TC: That answers all four questions.

Tyler started an FCP.

### "unused_must_use: Don't warn on `Result<(), Uninhabited>` or `ControlFlow<Uninhabited, ()>`" rust#147382

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

Josh: Already in FCP, unanimous checkboxes.

Josh: Scott mentioned we may want to support both variants of ControlFlow. No one came up with a use case, though. The two people in Zulip who asked for `ControlFlow` didn't have any use case for the always-`Break` never-`Continue` case either. Can trivially support that case if anyone has a use case.

### "Do not consider uninhabited 1-ZST "trivial" for the purpose of repr(transparent)?" rust#147588

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

Zachary: That's different from the `repr(C)` one.

TC: That seems accidental to me too.

Zachary: This does definitely seem accidental. But there's a possible usecase for it where it could be analogous for the C no-return attribute on a function. By having it an uninhabited field you can say that it won't return. Not sure how useful that would be.

TC: The question to us is whether we want to statically reject structs marked as `repr(transparent)` that have uninhabited fields. How does that interact with generics? I guess if we don't know if the generic is a 1-ZST we reject it.

Zachary: If there's only generic and there's 1-ZST we accept that.

TC: The case we're missing is we do know prior to monomorphization is uninhabited. We know upfront we're accepting these. And you said there's a usecase?

Zachary: C has the [[noreturn]] which can apply to functions that return any type but relays to the compiler that the function does not return. In rust we could represent this as a repr(transparent) type with an uninhabited field to say `!`.

TC: What does that buy you? You're still not returning the other type, you're returning a wrapper.

Zachary: For FFI it can have an implication. In February we fixed a miscompilation/ICE because we didn't treat it as ABI compatible even though by the letter of the law it should be:

https://github.com/rust-lang/rust/issues/135802

TC: And what Ralf is saying that doing this screws up our ability to optimize our ABI because we have to assume that we can't exploit the uninhabitedness here, right?

Tyler: So the problem is that Hyper is actually using this. And I'm not sure anyone on the thread understands why yet.

Tyler: We're still in the information gathering phase. I propose we indicate we're fine with making this change modulo needing to fix Hyper. And deal with the fallout. I want to learn more about what Hyper is doing. I'd put money on them doing something sketchy that's difficult to express. And if that's the case we should go ahead and break this.

Josh: It seems what they're doing is contra to the layout changes we're trying to get. Which is to try and optimize this.

Zachary: do we want to consider in the future to represent the equivalent of C's `[[noreturn]]`?

Tyler: I thought this opened up the door for us to express something like this in the future.

Zachary: C `[[noreturn]]` attribute does not effect the ABI.

Tyler: You're saying if we wanted to express noreturn in a way that doesn't affect the ABI, it would be useful to use the repr(transparent) struct with the uninhabited field.

Zachary: Yes. There's not currently a way to reprenest this currently other than this. So do we want to consider an other way of representing that?

Tyler: It depends on the use case. If someone showes up with a need for this and we can add this in the future. We're clawing back more functionality in this case if we break it. So we can bring it back if we need to.

TC: I'll post this:

> We discussed this in our lang call. Our vibe was indeed that we'd prefer for this to be a static error. At the same time, we're interested in hearing the outcome of the rest of this investigation and seeing the crater report.
>
> If there turn out to be use cases for a [[noreturn]] equivalent, we'd be interested in hearing proposals separately for that.

### "Make `cpuid` safe and update docs" stdarch#1935

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

TC: This is our first FCP in `stdarch`. We felt ambivalent adding a target feature for `cpuid`. Instead we decided to add it as safe and add documentation.

Josh: That sounds good to me, let's fire it off.

Amanieu: I missed the last meeting where we decided against target feature.

Josh: The reasoning was the only two cases were SGX (effectivel deprecated and technically safe from Rust case) and 586 which we don't support and if we ever do, the target should not have this call.

Amanieu: It feels weird to have the cpuid intrinsic to disappear on older platforms.

Josh: The broader thing is that we should not support those targets.

Amanieu: We may want to add target_feature to those.

Josh: Yeah, we could do that in the future if we add those targets -- make it unsafe there and require a target feature on those specific targets if we ever add them.

Tyler: I guess that makes sense. These are intrinsics, they're only available on the targets that support them, right?

Josh: Yes, they don't e.g. appear on Arm.

TC: I fired the FCP, checkboxes are up.

### "RFC: Allow cfg-attributes on elements of tuple type declarations" rfcs#3532

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

TC: This is an RFC; we must just be doing a vibe check here. What's the nomination and what's the question for us?

Josh: It seems iffy but at the same time I get why someone would want that. The nomination was on the basis of rediscussing this since we gave a follow-up on this and the author updated the RFC.

Josh: We discussed it at a previous meeting where we felt this was awkward but potentially acceptable.

TC: Did we not leave a comment on the thread?

Josh: I can't find one.

Josh: If it's not used carefully, you could end up with spaghetti. But that should mean you should be careful with it. And doing `cfg` attributes on functions can lead to just as much spaghetti.

TC: So is the idea on the tuples that if it's conditionally flagged, it changes the arity of the tuple?

Josh: Correct. We support this today on tuple values. You can write a cfg on a value of a tuple. And the arity of the tuple can change. We support it on function arguments too. We just don't support it on type arguments. This adds that.

TC: Do we support this on function parameters when declaring functions? It seems we should be consistent between tuples and function calls and function paremeters.

Tyler: Yeah we do support it. This compiles:

fn foo(x: i32, #[cfg(false)] y: String)
{}

Josh: If we didn't suport this at all in tuples to begin with. But given we support it with tuple values and support it in function arguments makes me think we should support in tuple types. So you can write the type that the tuple would use.

Tyler: I'm fine with it. It's questionable whether this is a good style.

Josh: Absolutely agree. I'd propose FCP merge on this. I'd summarize this as "doing this has the potential to introduce spaghetti code but since it's supported for values it should be supported the types too".

TC: The vibe sounds right.

Checkboxes: https://github.com/rust-lang/rfcs/pull/3532#issuecomment-3407593688

### "RFC: `#[export_visibility = ...]` attribute" rfcs#3834

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

TC: Tyler, you proposed FCP, then nominated it, then filed a bunch of concerns.

Tyler: I think I nominated it for a vibe check and we did discuss it a couple of meetings ago:

https://hackmd.io/f_pVDH91Q4OkUd6fxDpjnQ?stext=16503%3A59%3A1%3A1760550701%3Aylkrhk&edit=

Tyler: The vibe check was: how do we want to presesnt a visibility knob to users. There were two alternatives being discussed: 1. we have a switch that says "just treat this symbol like an ordinary Rust symbol for export visibility". The overall motivation for this RFC: someone has a usecase they need no_mangle, but when we see no_mangle we implicitly upgrade visibility and that resulted in an undefined behaviour. So at least we need to turn this implicit behaviour off. Through the RFC discussion the scope got more focused to something we don't have to work through a bunch of questions on what the semantics of the options are. But we still have an export_visibility attribute and one option.

TC: Makes sense. Previously I asked whether it ever makes sense to use this without no_mangle. I've now asked on the issue:

> We're talking about this in the lang meeting. Question -- and maybe it's in here -- is there ever a case where one wants to use this without `no_mangle`? If there is, it'd be worth discussing that in the RFC. If there's not, I could see that affecting how we might want to express the syntax for this.

Josh: I think the primary benefit of having this be orthogonal to no_mangle and that any combination of those two is valid.

TC: I think the RFC should call the seperation and usecase explicitly but I agree with having them separate.

Tyler: The only option the RFC stabilizese is `#[export_visibility = "inherit"]` and it's inheriting the default behaviour of the taret. Actually, we did rename it to `target_default`. I think all my concerns are now resolved.

TC: Good vibe check here. I unnominated it.

### "`dangerous_implicit_autorefs` suggestion is wrong" rust#140721

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

TC: Question for us on this one: is this a bug or not? The rules for this lint are hard. Urgau is not sure whether it's a bug so he threw it in our court.

Tyler: Why would this be a bug exactly? I agree with Urgau's first comment that the warnings are on differnt part of the expression. It doesn't seem like a bug to me.

Tyler: Ah:

> The autoref actually happens on the slice operation (*slice)[..]. This is a call to `<[T] as Index<RangeFull>>::index` which takes &[T]. The compiler warning twice is definitely wrong since the call to len happens on the result of *Index::index(..) which is a deref of a reference.

Josh: Yeah, this seems like: "not the correct warning on the code that should be warned".

Tyler: I thitk it should only lint once.

TC: What do you think of Urgau's response? In the compiler the dereference doesn't exist.

> For the compiler, *Index::index(..) does not exist, more precisely in the HIR the output type of (*slice)[..] is [T], there is no implicit or explicit deref.
>
> And because the len function is marked with #[rustc_no_implicit_refs] (and we peel the [..], rule 2. peel place expressions) we then see the deref of a raw pointer and lint on it.

https://github.com/rust-lang/rust/pull/123239

https://github.com/rust-lang/rust/pull/103735#issuecomment-1370420305

Tyler: I don't feel strongly about this in a particular way. If someone has a proposal to make the lint less noisy and still correct in what it says.

TC: How about this response: "Similar to Urgau, it wasn't clear to us that this was a bug. We're always interested in making diagnostics better. If someone has a particular PR that makes it more clear and jsut as correct, please nominate it for us."

(The meeting ended here.)

---

### "Add new `function_casts_as_integer` lint" rust#141470

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

### "`rustc_const_eval`: respect `target.min_global_align`" rust#142198

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

### "error out when `repr(align)` exceeds COFF limit" rust#142638

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

### "Tracking Issue for `darwin_objc`" rust#145496

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

### "Tracking Issue for Reborrow trait lang experiment" rust#145612

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

### "compiler and language documentation disagree on lifetime extension for array expressions" rust#146092

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

### "Add a new lint `UNCONSTRUCTABLE_PUB_STRUCT` to detect unconstructable public structs" rust#146440

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

### "Add lint about redefining runtime symbols" rust#146505

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

### "Not linting irrefutable_let_patterns on let chains" rust#146832

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

### "Add `cargo_cfg_target_family_multivalued` lint" rust#147545

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

### "Extend format_args implicit arguments to allow field access" rfcs#3626

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

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

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