---
title: "Triage meeting 2026-05-27"
tags: ["T-lang", "triage-meeting", "minutes"]
date: 2026-05-27
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202026-05-27/with/598021969
url: https://hackmd.io/mZFYKMR-R46CznGnFwHkUg
---

# T-lang meeting agenda

- Meeting date: 2026-05-27

## Attendance

- People: TC, Josh, tmandry, Mark, Chris Sedna, Nia Deckers, Jana, Tomas, scottmcm, yosh

## Meeting roles

- Driver: TC
- Minutes: Tomas

## Scheduled meetings

Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.

TC: I propose we cancel the second meeting. We don't have Niko, we won't have tmandry for the second one, and I assume people are catching up.

TC: OK, hearing support, let's do that.

## Announcements or custom items

(Meeting attendees, feel free to add items here!)

## Nominated RFCs, PRs, and issues

### "`dyn Allocator` together with `Allocator + Clone` requirements is unsound, leading to UB with `Arc`" rust#156920

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

Nia: We want to stabilize Allocator. We'd like it to be dyn compatible. But we require that implementers of `Clone` must uphold semantics: if you've allocated with allocator A, you cloned it, pass that pointer to Allocator B, you can deallocate with that. If Allocator is dyn compatible, that's impossible to uphold. You can make a subtrait of Allocator, impl Clone and it can be a mallicious implementation. If make it not dyn compatible, this works, but you're relying on the orphan rule. The other alternative is to have a marker trait `AllocatorClone`. That works, but if we ever want to

Nia: My proposal is to be able to mark traits to conditional rely on the implementation of another trait for their environment. We mark one of them that the soundness of allocator requires you to implement Clone correctly. Once we detect the implementation of Clone, we require that the implementation be allocated with `unsafe`.

jana: It's a conditional unsafe trait. It's only unsafe when another trait is also implemented. If I built an attribute, it would say e.g. on Clone, if Allocator is also implemented, it requires an `unsafe` keyword on the `clone` implementation. It would be a relatively rare situation.

Josh (in chat): The ability to mark trait cross-conditions like this doesn't have to be stable; initially only the standard library would need it in order to stabilize `dyn Allocator`.

Tyler: An alternative: making `Allocator` itself to be unsafe. That wouldn't require any unsafe lang feature

Nia: It's already unsafe. But it would have to be an unsafe always dyn-incompatible trait. Becuse `dyn Trait` is a trait, there's no way to prevent a downsteram implementer to do this.

Tyler: Is this depending on Box being special?

Nia: Box being fundamental is what makes this a problem.

jana: Option 4 as outlined by Nia is we change how `#[fundamental]` works in combination with allocators. I don't like it, but it's a possibility.

Nia: These are the four options: https://github.com/rust-lang/rust/issues/156920#issuecomment-4547308627

Nia: Option 1 is what I outlined. lcnr and jana think this is implementable. Would Lang accept there being some syntax for this? It could be an attribute for now.

TC: Procedurally, we won't be able to answer this right now in this call. The comments are probably enough for us to have a look later. If you file a separate issue where you write up this proposal by itself, giving syntax options, as a vibe check for us, and nominate, that wolud help us — I'm trying to think of what you can do to help move this forward. This would need to be RFC'd. As I understand, you're asking us for a directional hint for what we'd be likely to accept.

Nia: Yes. It's needed for stabilization. The lang matter is if you'd like to have a special syntax for this.

Josh: This wouldn't block stabilising Allocator. But we'd have to keep it not dyn compatible. And we'd have to decide on this before shipping dyn alocator support.

Nia: You're correct. But the question is what we want. If you impl Allocator on Foo and dyn Allocator on Foo, you require unsafe. There is a wold where we wait for this and change the syntax required over an edition

Josh: I agree we're not going to make a decision today. But we may be able to offer a vibe check. The types team will be more involved in this than lang. We'll lean heavily on the types team on what seems feasible. The next step would be us saying "this direction seems worth pursuing" and if types make it work, we'd be open to exploring that. I'm hoping we might be able to say that today.

jana: I think we can experiment with the first option. From the types point of view it's implementable. And if we go attribute first, we can make it an unstable attribute. For lang, this seems to be possibly a broader feature that we might want syntax, docs, diagnostics etc. The feature being safety on one trait dependent on invariants upheld by another trait.

Nia: +1

Scott: Other traits wanted this. This makes sense to me as an experiment.

Tyler: I'm trying to think how one would naturally express this in the language. "unsafe if not implemented Foo". My vibe is that types feel confident we can implement this. Then it's a matter of we could explore it from the standard library. I'd feel more comfortable if we found a way that it'd feel natural for something you'd reach for in a program. None of that is a true blocker.

Josh: I'd want to have a more serious RFC if we want this for more things beyond the standard library. But trying this as an unstable rustc attribute for things in the standard library, I'd be happy for libs and types to experiment.

Scott: Agreed with Josh. We can't let make other people add these impls outside of the standard library.

(Scott, clarifying later: As in we don't want to accidentally allow people to start doing these implementations in a way we wouldn't want to keep around. We've done that accidentally before and it's sometimes caused problems, so we need to be careful. It might be fine to do it intentionally, but we should default to blocking both declaring and implementing.)

TC: I need to look at this and it'll take me longer than I can do on this call.

Tyler: I'm happy to see an experiment. We should talk more about how to frame it in the language itself before we expose it.

Nia: Thank you for your time.

### "Allow `global_asm!` in statement positions (take 2)" rust#156919

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

TC: This is an extension of the `global_asm!` feature. It allows us to use `global_asm!` from not just item but also statement position.

Josh: If you can write `global_asm!` in statement, if you end up with more than one in the final binary, do you get multiple copies?

Mark: We're proposing an unstable feature and we can add that as an unresolved questions.

Josh: I missed this was an unstable feature proposal. Then yes, let's add it as an unresolved question.

TC: So we're approving a lang experiment here. We don't need an FCP; we just need to signal we talked about this and are OK with it. I've been taking all the inline `asm` features, so I'd be happy to take it.

Scott: If you're inside a function body, you could write items. What's the goal of having it in statement positions?

TC: It says "this is particularly useful for macros where you otherwise have to wrap them in a module". I'll look into it after the meeting.

Josh: The 2 pending questions: why is this not covered by the item position and what happens if you have more than one? Will you add both in the comment?

TC: Yes.

Mark: To Scott's question:

error: non-statement macro in statement position: std::arch::global_asm
 --> src/main.rs:2:5
  |
2 |     std::arch::global_asm!("");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^

Scott: But we allow `struct Foo {}`.

### "allow repeated repr attributes" rust#156856

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

TC: There was a comment saying we should go in the other direction:

https://github.com/rust-lang/rust/pull/156856#issuecomment-4529831557

> we overwhelmingly do not allow duplicates of attributes. For example, duplicating `#[link_name]` (just to give an example) gives a (fcw) unused attribute warning, even if the arguments are identical.

TC: That would be my inclination too.

Tyler: Ther's already an FCW and this PR allows duplicates?

TC: This is trying to make it more consistent, but it's making it more consistent in the wrong direction probably.

Scott: I think we should not allow this in any place and if we want to allow this, we should split the repr into multiple attributes.

TC: I agree with everything you said. If others are happy with it, you want to write that out on the issue?

Tyler: I'm happy with that. The only alternative we could go is combining pieces of the repr and erroring if we find any duplicates.

Scott: Is it FCW to have multiple?

Josh: Some subsets are FCW. For instance, `repr(u32, u32)`.

TC: Scott, click through the underlying issue. theemathas has an enumeration of cases.

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

Scott: The FCW for being inconsistent is what we want to change. Would we want to start FCWing on repeating the same attribute?

TC: We should at least lint it. We do this in many places. We're moving in the direction of linting these consistently and giving more errors (see the Reference: we've been documenting these extensively). The places where there's actual ambiguity or conflict are obviously the priorities for where we should be giving errors or FCWs.

Josh: +1 for erroring for conflict. If it's an exact duplicate, that's less of an issue but let's not make it worse.

Scott: The note about multiple alignments that picks the highest one is interesting.

Josh: People get confused about which order attributes apply in. That makes me thing we might want to take that back and have macro authors that want to allow overriding an align accept an optional argument.

Tyler: I'd be fine with us linting on it.

TC: Scott, when writing this up, along with hinting a direction, you might consider asking people to come back with a stronger proposal. You don't necessarily have to think of one yourself. Getting a sense of direction may be what people are looking for here.

### "remove `box_patterns`" rust#156749

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

TC: This is a removal of a long-standing nightly feature.

Tyler: There was a pre-1.0 RFC that feature-gated these. I'm not sure we even have an RFC for the feature itself. I'm fine with this. My understanding is deref patterns are a better version of this feature. And field projections provide an even more general version of this.

Mark: Sounds there's a potentioal breaking change because the syntax wasn't gated pre-expansion. But I can't imagine there's a lot of people writing box patterns that are `cfg`d away.

Tyler: +1

Scott: +1

Tyler: We could wait for the crater to come back or start FCPing this now. I'm comfortable proposing an FCP. (Done.)

### "Implement `asm!` `interpolate`" rust#156719

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

TC: This is a nightly feature. It may also be proposed as `verbatim`. I'm happy to pick this one up as an inline assembly item. This is asking for us to approve an experimental extension of inline asm.

Tyler: Is the "interpolate" word new within the asm macro syntax?

TC: That's right.

Josh: This seems reasonable as a feature modulo exact syntax.

Tyler: So normally you can use format string placeholders for registers and values and this lets you have them for instructions themselves.

Josh: Or for regular strings in general.

Tyler: I'm fine with this as an experiment.

Josh: Looking at tests I see you're allowed access consts from various contexts (e.g. associated consts). Are you allowed to use const eval to generate it? That sounds cursed and delightful and I'm all for it.

### "Tracking Issue for Unnamed Enum Variants (Open Enums)" rust#156628

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

Tyler: This is a new experiment, it's an FYI, for experiments the process is we nominate it. I believe Josh you were the champion for this?

Josh: I believe originally the intention was to have Scott champion on this one. But needed a champion in a pinch to move it forward. I'd be happy to hand it to Scott at any point he wants.

TC: And Scott, I think you had the most particular concerns here.

Scott: I've been thinking about that, trying to distill it to something more productive.

Josh: I'm happy to help, but feel free to take it.

Scott: Updated.

TC: Typically what we do is leave a comment at the bottom: we talked about this, lang approves the experiment, you're the champion, etc.

Scott: Will do.

### "riscv: promote d, e, and f target_features to CfgStableToggleUnstable" rust#156188

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

TC: We talked about this yesterday at our lang-docs meeting. We have a reference PR ready for it. I proposed FCP merge. We're picking up checkboxes.

TC: I'd recommend looking at the Reference PR for the exact description of what this is doing:

https://github.com/rust-lang/reference/pull/2274

Scott: I wish we had a non-lang team to delegate these lists of things to do.

Josh: Having something like lang-arch that would cover architecture-specific intrinsics, targets and asm features sounds like an interesting cohesive delegation.

TC: On these, generally, we're looking at whether we trust the person putting it forward to have looked into the details and that items such as the Reference PR are checked off, then we're signing off as a kind of ministerial action. In a sense, that's already a kind of delegation.

Josh: Yes, since that's what we're doing, recognising that formally makes a lot of sense.

Tyler: Are we moving to a direction that we're able to use the target feature for these?

TC: Yes.

Josh: The specific target features affect ABI so it's easier for the compiler to handle them on a complete program level rather than tracking it across functions.

Tyler: I'm happy with that. I don't see a particular alternative or reason why we shouldn't do this.

### "Support if-let guards in `matches` macros by using `:guard` matcher" rust#156025

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

Josh: The `matches!` macro wanted to support placing guards within it. That's nontrivial to parse. Multiple people suggested to take advantage of hte parser in the compiler and add the `:guard` matcher. We added that and went to use that guard matcher in the macro. The matcher is not stable yet, is this an issue to use it in a stable macro. We're not exposing any new stable area here -- you can write the whole thing by hand without this.

Scott: Do you know of any particular concerns about the guard matcher? Could we stabilise both of them?

Josh: My understanding was it wasn't particularly hard. The only thing stopping us from stabilising is is someone writing a stabilisation report and asking us to stabilise it.

Scott: My concern is if we find an issue and have to end up fixing it, that might end up being a breaking change to the standard library macro which would be bad. (I suppose that we could always add a `guard_oops2026` matcher for the macro to use if needed, though.) If someone wrote a stabilisation report and say this is easy, I'd say go for it.

Josh: +1

TC: I think I expect greater lang involvement on core macros like `matches!`. Macros are weird; they're syntax-level abstraction, and syntactic lowering is most of what we do on lang. It's often an implementation detail whether we expose something via direct language syntax or via a macro. I don't expect the syntax on `matches!` to wildly diverge from what we do in the language syntax (i.e., this is a question about the "flavor of the language"). So I wouldn't go quite as far as because technically it could be written by hand that it doesn't involve lang. But, practically speaking here, I agree with Scott's point. It seems better to stabilize the matcher fragment specifier.

Tyler: I'm inclined to stabilise the `:guard` matcher.

Josh: For this particular macro, I'd agree just stabilising the matcher makes sense. But I don't want to set a precedent that just because a macro has similar syntax to a language feature, the macro syntax is a lang matter.

TC: There's existing precedent for this.

Scott: I can write up my concern about if we have to change the guard it would be a breaking change to the macro and it would be great to stabilise both instead.

Tyler: Sounds good.

TC: Let's do it.