---
title: Triage meeting 2026-01-28
tags: ["T-lang", "triage-meeting", "minutes"]
date: 2026-01-28
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202026-01-28/
url: https://hackmd.io/GiLB0VK7S52-WdVxMSnsBA
---

# T-lang meeting agenda

- Meeting date: 2026-01-28

## Attendance

- People: TC, Josh Triplett, tmandry, scottmcm, Tomas, Nadri, Ed Page, Amanieu, Jack, Aapo, Chris Sena, James Muriuki

## Meeting roles

- Driver: TC
- Minutes: Tomas

## Scheduled meetings

None.

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

## Announcements or custom items

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

### CPython interest in async drop

The CPython folks are looking at the interaction between Rust and Python objects. We think/hope their API would be cleaner and less restrictive if we could bring async drop in. We'd love to invite someone familiar

Josh: The Python interpreter needs to be available to do reference count manipulation. If you need to drop/clone a Python object, you need to know which interpreter it's attached to. This reminded me of async drop where you need an async runtime associated. This seems similar. Whoever's working on async drop might be worth talking to the Rust-in-CPython folks.

Nadri: This also reminds me of the context & capabilities work.

Josh: That may be a potential approach too. Whatever makes the most sense for "I want an ambient object around when cloning/dropping" would work.

Tyler: There's work going on unblocking this. Also experimental work like Move trait. Once that's in place we can start experiment with types that aren't Forget. And async drop in earnest. AFAIK nobody's working on async drop at the moment. "Relaxing default trait bounds", part of Sized hierarchy work.

Josh: Do you know an obvious person driving this forward or do you think we're not there yet?

Tyler: I don't know who's actively driving async drop

Nadri: same.

TC: There was that work petrochenkov and co were doing.

### Companies and budget time - talk to folks if you need support

Josh: It's that time of year, many companies are doing their annual budgets and deciding what to support and what to cut. If anyone is in need of support from others to endorse the value of their work, or if anyone finds themselves suddenly looking for work, remember to reach out to fellow Rust Project members. We should stick together and help each other.

TC: I'm happy to sing the praises of people; be sure to ask.

Josh: Same. I'm also pretty good at helping to pitch the value of things based on what a company is looking for.

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

TC: Due to Ed joining, we'll pull up front matter to the top.

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

TC: Nadri proposed having a hard limit of 10 minutes per item. We'll try this. We've done similar in the past.

Nadri: I also proposed running the meeting.

Tyler: I like the idea of timeboxing but for guest-attendee items I don't feel good about the hard cutoff.

Nadri: I'm less interested in timeboxing if I'm not running the meeting.

Ed: If my thing does get cut-off, how many hours from now would that be deferred?

TC: It would be 2h 4minutes

Ed: Two hours from now would work for me.

TC: I'm in favor of pushing pace, I want our inbox to get to zero.

### 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 on 2026-01-28 to review the status of RfL project goals.

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

## Nominated RFCs, PRs, and issues

### "Stabilize Frontmatter" rust#148051

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

TC: We have the stabilization up. We have FCP on it -- one concern on it. We've got inconsistency on the CRs. We talked about that in a meeting, Ed was not present there. Ed's here now.

Ed: First question: what are the team's thoughts on the text direction lint being managed by the tools or by Rust? There's the text-direction lints (one for comments, one for strings). Is it correct for Rust to lint for those, the tool managing the front-matter here?

Josh: Context, we talked about using right-to-left having potential security issues. We've opened lints.

TC: I see difference between linting and erroring. For the Reference we don't care about the lints at all. We care about the grammar. From that perspective I'm less concerned about linting. I know there's concern about confusing users.

Ed: Sounds like T-lang doesn't care about lints?

Josh: The Reference doesn't care. T-lang very much cares about lints.

Josh: There's a question on how much ??

Ed: Who should manage a lint like this? And then bring taht to CR: should that be a lint or hard error? And my framing would be: the tool should be managing the lint not Rust.

Tyler: Your framing is we should treat the RtL characters same as the CRs. That makes sense to me. TC brought up CR/LF normalization, I'm curious on TC's thought. My mental model: front matter isn't Rust. It's whatever the tool parses. We typically don't lint on that.

Josh: I originally aligned with the notion of adding careful checks for things that look differently from what they mean. Ed made the point that the first user for front matter is Cargo. We should treat it as a feature trying to integrate with Cargo. In that context we're talking about a tool that's capable of processing and linting it. I don't want to get to a point where the tool has its own syntax and lints and be constrained with what rustc does. I propose rustc to just pass it through to Cargo.

Josh: These lints are to help the programmer, we're not protecting against malicious tooling. I'd recommend we drop the check for CR now. And work with Cargo later to evaluate whether that should be handled and where.

TC: I look at this as: CR hard error is distinct because it interacts with our CR/LF normalization. We do a single pass of that normalization and anything that's left over stays there. The reason for the CR exclusions in our grammar is to make the edge cases of our CR/LF normalization unobservable. I think it's plausible to just reject CRs that would remain after CR/LF normalization. To leave the door open, I'd like us to be consistent with our existing grammar in a lot of places. I see this is simplifying the grammar by upholding the consistency.

TC: To Tyler's point, I do think this is Rust. Just as much as docstrings are. A tool like rustfmt need to know how to lex.

Josh: We're not responsible for CRLF normalization in front matter. Other tools are. So we should discuss the difference between strings and

Ed: I'd like to discuss what issues you are talking about with CR/LF normalization. If this hinges on that, we need to discuss it.

(Hard cut for time; we'll return to this later.)

---

scottmcm: some thoughts here, said offline

> Generally, for lints vs hard error, to me it's only a hard error if we don't know how to handle it. If it's clear what it does but that's not what the person wants, that's a lint. Like we're defined the behaviour of `0_u32 - 1`, so it's not a hard error, but we also `deny` lint it because we know *in that case* that it's probably not what you wanted.
>
> So it's a question of whether it's something we need to know to understand the file (including cross-platform consistently) vs something that we're doing to help the programmer.
>
> So to me I think the L2R checks are clearly a lint, but TBH I don't know for sure about CR stuff.

### "Stabilize `if let` guards (`feature(if_let_guard)`)" rust#141295

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

TC: It was in FCP, then we noticed the drop order didn't make sense in some cases. I think it's all there, I've resolved the concern that's been blocking us. It's in FCP now.

Tyler: Happy to see this moving forward.

Ed: When I see a match, my assumption is that match arms are all going to be based on the expression evaluated at the top. This surprised me because as a user reading it I can't think locally about the match. I hadn't seen that in the RFC.

Josh: Why does that feel different for `if let` arms than `if` arms. Match already has `if` and this extends it to `if let`.

Ed: I see. If match has this problem already, ok.

### "Support importing path-segment keyword with renaming" rust#146972

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

TC: we checked this off, it went into FCP. Eric Huss brought up: (1) we were signing off on the change to the 2015 edition. We were accepting new code in the 2015 edition. (2) There's inconsistency: we allow `use self::super::something` and we allow `use super as something_else` but we don't allow `use self::super as something` or `use self::super`

TC: Niko had a lot of thoughts on this.

Josh: As far as I can tell, this is supporting a change across all editions. I din't see anything doing it differently in 2015.

Tyler: That was my understanding too.

TC: The author confirmed with Eric Huss's analysis.

Josh: I'm not aware of there being an edition-specific change here.

TC: We're not claiming any edition purview. This is coming from the Reference side in documenting the new behavior.

Tyler: What is edition specific here?

Josh: I'm testing it right now.

TC: What is our expectation about `self::super`?

Josh: `::{self as something}` currently doesn't compile in any edition. If that starts compiling, that won't be edition-specific.

Tyler: This PR was fixing some inconsistencies. Does it not fix all the inconsistencies and we have further cases to fix? Is it introducing new consistencies?

TC: It's more about what rule we're writing down for when this works and when it doesn't. For the Reference, when we have inconsistencies we often write down what we think what the rule should be and note down where rustc diverges from the rule. Here it's not clear what model we're changing.

TC: Petrochenkov described the rule here: https://github.com/rust-lang/rust/pull/146972#issuecomment-3797153587

TC: The model mu0019999 is proposing is: https://github.com/rust-lang/rust/pull/146972#issuecomment-3798045136

Josh: Sounds like rust curretly allows super after self. And petrochenkov is saying that self should only allowed after super.

(Hard cut for time; we'll return to this later.)

### "Inhibit all-absent-variant optimization for all enum reprs that inhibit layout optimization, not just repr(C)." rust#146989

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

Nadri: That's waiting on crater, nothing new today.

Josh: This is just the enum reprs that act like `repr(C)` but set the size?

Scott: they're both C compatible.

Josh: Confirming: both `repr(u32)` and `repr(u32,C)` are considered "enum reprs that inhibit layout optimization" or the purposes of this proposal?

Yes.

Tyler: I think we should do it.

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

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

TC: This one is only waiting for the Reference PR.

Josh: And there's a reference PR as of 15 minutes ago: https://github.com/rust-lang/reference/pull/2147

Amanieu: What still needs to be done is: I've been looking at the type-level name resolution code. That shouldn't be too difficult to support supertrait shadowing.

Amanieu: We have 2 separate code paths for name resolution: (1) path expression and (2) path for generic bounds etc.

Jack: If you make that change, feel free to request me as a reviewer.

Amanieu: Is this the direction we're willing to go? Alternative is to go the otherway and restrict supertrait shadowing to only support the method call syntax and not the `::` syntax.

Josh: I think we should be fully consistent and make item shadowing work the same way for supertrait and subtrait shadowing for associated types, associated constants, method syntax using `::`, and method syntax using `.`. But it's fine if we do that incrementally: an error can always become code that compiles later.

Scott: We have interest in being able to split traits and keep things working. The reasons we want this for methods are similar reasons for other things. So being consistent makes sense to me.

Tyler: What Scott said is compelling. We're resolving it to the most specific things. I don't foresee any problems.

TC: Agreed. I'd expect the fully qualified syntax to work.

Amanieu: The reference PR only currently documents the method call syntax with the `.` method. There's no general name resolution section yet.

TC: There's a placeholder. You just add the bullet points for what the rules are going to be. When Jane gets to writing the name resolution, it'll get pulled into that.

### "Stabilize `core::hint::cold_path`" rust#151576

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

This is in FCP. Niko and TMandry have unchecked boxes.

TC: It's creating a function item `cold_path`. You can put it in a branch and mark it as a hint for cold_path.

Josh: We previously had `likely` and `unlikely`. This was added because it works for match arms.

TC: We do have a stable `cold` attribute. You can implement `cold_path` in terms `cold` attribute. You can implement `likely` and `unlikely` in terms of `cold_path`.

Amanieu: The only reason it's an intrinsic at all is: it's better than an inline function that has a cold attribute because it eliminates the inline call.

Amanieu: The fact that implementing them using `cold_path` at all relies on mir inlining a lot the weights in.

Scott: We depend so heavily on mir inlining for anything performance related that I'm not concerned about it. But it's worth mentioning we depend on it.

### "deprecate `Eq::assert_receiver_is_total_eq` and emit FCW on manual impls" rust#149978

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

TC: It's a dual FCP. We're picking up checkboxes from Niko and Scott.

TC: This in about an internal method on the `Eq` crate. Used for derive. We don't want people to implement it directly.

Josh: Give the proposed alternative that allows doing this without this method, let's start the doing FCW.

Jack: Why is this T-lang?

TC: We're adding a lint.

(The first part of the meeting ended here.)

## Nominated RFCs, PRs, and issues, part 2

- People: TC, tmandry, Tomas, Nadri, Chris Seda, James Muriuki, Benno Lossin, Jack, Aapo Alasuutari

### "Make PinCoerceUnsized require Deref" rust#149218

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

TC: We have proposed FCP, all of us have checked our boxes.

### "Mark const SIMD intrinsics as indirectly stable" rust#149648

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

TC: We asked a question, we don't have an answer.

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

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

TC: 2 things are outstanding: (1) we're waiting on a lint to merge and (2) there are some oddities in the grammar in the Reference. We should wait for an answer from Folkert

Josh: Regarding the grammar issue, I wrote the implementation I had this exact consideration in mind when writing it. The issue is mostly the difficulty of parsing. It's nontrivial to get it exactly right. It's a reasonable follow-up. We should document what the grammar says now and we can expand later. We shouldn't block on the grammar.

TC: I'd wait for Folkert and if he says it's hard we can reconsider then.

Josh: If that's the concern, we should spell that out more consistently in the ask.

Tyler: What is the trailing comma issue?

You can write this..

    match 2 {
        2 => {},
        _ => {}
    }

TC: You can see it in my comment in the Reference PR: https://github.com/rust-lang/reference/pull/2103#discussion_r2701898189

CfgSelectArms ->
    CfgSelectConfigurationPredicate `=>`
    (
        `{` ^ TokenTree `}` CfgSelectArms?
      | ExpressionWithBlockNoAttrs `,`? CfgSelectArms?
      | ExpressionWithoutBlockNoAttrs ( `,` CfgSelectArms? )?
    )

Josh: An expression with a block is a single expression that happens to end with a brace but it's not a brace of a match brace. And that expression will eat a comma.

Josh: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=96fa7db1ae9a175f5a323251b0d416c8

#![feature(cfg_select)]

fn main() {
    let x = cfg_select! {
        windows => { 1 },
        unix => { 2 },
    };
}

Josh: If we're going to have a concern here. The reference item has a question. We should spell out what our ask here is: we'd like a consistency with match if that's possible.

### "Do not deduplicate captured args while expanding `format_args!`" rust#149926

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

TC: We discussed this last week. We re-FCPd it as dual FCP with Libs-API. BurtSushi filed a concern.

Josh: We had several rounds of back and forth with lang and libs. The original concern was what theemathas noticed. We talked about that in a meeting. We proposed fixing it. There was a PR, that's being evaluated Mara brought up this was an important optimization. dianne brought up it would be possible to do an as-if optimization. We treat this as if it wasn't deduplicated, but we could optimize the common case. Mara and Jubilee felt this complicated format_args to have that optimization. They thought the original RFC specified this, Ralf came back saying that it wasn't said explicitly.

Josh: (a) I propose we do the optimization that only applies when you can't observe the optimization. The other alternative (b) would be to ratify the current behavior despite the inconsistency. I propose with option (a) an let the FCP to go forward. BurntSushi would remove his concern.

TC: I agree this FCP should go forward. If we were not to do this I'd be sceptical of extending our interpolation behaviors with `format_args`.

Tyler: My position is the same as week ago: we should move forward with this.

Josh: It's worth acknowledging that a couple people are not happy with T-lang. They think the RFC said something and lang is saying something else. I don't that's an accurate characterization, but there's a lot of stress going there, let's go with extra abundance and empathy.

Tyler: Agreed.

### "Make operational semantics of pattern matching independent of crate and module" rust#150681

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

TC: I think we're just picking up checkboxes on this. We need Niko and one more from Jacob Degen, digama0 or saethlin. This is a joint lang/opsem FCP.

Nadri: only the items (2) and (3) from the original proposal is what we're checking boxes on.

(2) matching on a #[non_exhaustive] enum will always introduce a discriminant read, regardless of whether the enum is from an external crate
(3) uninhabited variants now count just like normal ones, and don't get skipped in the checks

TC: Item (3) is a bugfix.

Niko: And the first one we're waiting on because there's no consenus?

TC: I asked for (1) to be broken down. It's harder.

Tyler: Is the current behavior that we do skip discriminant read if enum only has one variant?

TC: Yes. We skip it if you have an enum, it's not marked `non_exhaustive` and it only has one variant. That will remain the behavior even after this PR.

Tyler: And (1) was proposing to change that behavior?

TC: Yes.

### "Lint against inherent methods on types implementing `Receiver` and `Deref`" rust#151583

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

TC: Benno is asking for a vibe check from us whether we'd be interested in this lint. Things implementing `Receiver` and `Deref`, you should not add new methods on them after you're stabilizing the type.

Benno: This came from method resolution in field projection. What is the difference between `Receiver` and `Deref`? One part was implementing `Receiver` would restrict you from adding inherent methods. I thought it'd be good to have a lint for this.

Josh: Having a lint for this seems potentially reasonable. I wouldn't support doing this as warn-by-default. I wouldn't surprised if stdlib wanted to opt into this lint. To catch when we add a method on a type that is `Deref`. At least Libs-API took a position that we shouldn't add these, but sometimes we do add them when they're unlikely to produce conflicts. My only concern is about it resulting in an `allow` fatigue: you deny it, allow in a lot of places and then copy/paste the allow.

Benno: I grepped through the stdlib for cases that would trigger it. I found four methods on `Pin` and one unstable method on `peek_mut` on `BinaryHeap`

Josh: I thought we had more methods like that.

TC: Do you agree it's okay to add methods to the type concurrently with exposing the type and it's only bad to add them later?

Benno: Yes.

TC: I like this as a lint.

Josh: This could be done in conjunction with cargo-semver-check.

Nadri: I was going to make the same cargo-semver-check point. If users should know that this is a breaking change that's cargo-semver-check. If we make this a lint then it would imo be to "warn the API writer than they may be causing confusion"

Niko: This is closely analogous to the capitalization rules on variance. But there's no convention to get this lint go away other than by doing `allow`. I'd prefer it to go to semver-checks rather than an allow lint.

TC: I see allow-by-default lints as staging ground for the profiles. Putting them in appropriate lint groups and documenting that.

TC: But I'm lukewarm on this too. I could see it as warn-by-default, it's still uncommon exposing this. We see this in the standard library too. In this case I might say it's unusual enough and you don't want to be adding these methods to let people know.

Tyler: Looks like it's not linting in all cases. Are we only linting on public structs that are generic over type.

Benno: I intended it to be only on things exported from the crate. For deref implementation, the target type would have to be a generic type. If you derefernce to slice, like Vec does, it wouldn't trigger.

Josh: The fact that it interplays with pub and that we feel it should only apply to new things makes me feel like semver-checks is a new tool. So I'd say punt this into semver-checks.

Josh: We had a discussion in the Libs meeting to use semver-checks in std. Someone just needs to integrate it.

TC: Josh, you're the most reticent on this and many of use are more lukewarm.

Josh: I'd defer to everybody else if folks want to allow by default. If folks want to warn-by-default I'd be okay with that too, albeit even less enthusiastic. But it sounds like many people are lukewarm.

Benno: It would be useful to have a next step.

TC: Write up what you heard and we can talk about it next time.

### "UB inconsistency when derefing a place in a closure" reference#2121

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

Nadri: There's a tension in the Reference between: if there's a `**r` in a closure, we don't capture it (it's a place that's not used). Ralf and I think that `**r` should count as a read of `*r`.

Tyler: If write ` let _ = **r;` we read this in the normal code, but we don't inside the closure?

Nadri: Yes. This computes the place.

Nadri: We're reading from the outer pointer to get to the inner pointer and we don't read from the pointer because that's what `let _ = *...` does.

Josh: I'd very much align with treating this case as UB. You're writing something that appears to dereference a reference to a thing that no longer exists (use after free). That feels like it should be UB. I'm less concerned about this case and more about the case where `r` is a valid thing to dereference and changing to capture it would cause a borrowchk error. And normally we wouldn't have the borowchk error because we're not capturing it. Are we going to break existing code by suddenly creating a capture where we weren't creating a capture before?

Nadri: In some cases (e.g. `let (_, _) = x;` inside a closure I think?) -- in this case we don't capture. We could check whether the places is valid outside the place.

Niko: That's approx what I was going to say. I'm not keen on changing closure desugaring to capture data it's not going to use. But mentioning the places at the time of closure creation seems like a good idea possibly.

Josh: +1 for "check if it's valid but don't capture it", if that's what you're saying, Nadri.

Nadri:

Niko: If it did read from the place, you'd get an UB.

Nadri: If the read is conditional..

Niko: It would unconditionally capture it.

Nadri: It would capture `*r` but reading it is a problem

Niko: I propose you'd do a place mention at the closure creation.

Nadri: But if we did capture it, UB wouldn'1t happen at the closure creation time. It'd happen when the `let _` is executed.

// could capture `*r` or `r`, neither of which are instant UB
let f = || { let _ = **r; };
// UB happens when the function is called
f();

Josh: I think I can write an example that seems like UB with Niko's rule.

Niko: Doing it at closure definition time is inaccurate unless the closure is immediately invoked.

Niko: Why are we making the other one UB? Interesting that this does not compile...

fn main() {
    let a = Box::new(Box::new(String::new()));
    let _a = **a;
    let _closure = || { let _ = **a; };
}

...there's *some* kind of place-mention-y thing going on there, since we are getting an error from accessing `**a`:

error[E0382]: use of moved value: `**a`
 --> src/main.rs:4:33
  |
3 |     let _a = **a;
  |              --- value moved here
4 |     let _closure = || { let _ = **a; };
  |                                 ^^^ value used here after move
  |
  = note: move occurs because `**a` has type `String`, which does not implement the `Copy` trait

Tyler: Can we put some point of resolution on this? This could easily be deep dive.

Josh: Can we ask opsem for recommendation? We always need to load the context in. How about asking people who always have that context?

Niko: I like that idea.

Tyler: Me too.

## Deep dives

### "Stabilize Frontmatter" rust#148051

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

(continuation from line 100)

Josh: I'd like to propose to consider difference between handling within raw strings and handling within front matter. We have to be cautious about strings. That affects the exact string value we embed in the binary. There's also always an alternative, insofar as you can write a non-raw string with escapes rather than using a bare CR in the file. With frontmatter this is a thing that isn't Rust, that's between delimiters in Rust code. Handled by tools like cargo. The main thing is: are we delimiting it correctly.

Josh: I think there's a meaningful difference to what we're getting by applying lints there. What are we losing/gaining?

Tyler: I think there are 2 framings of this: Josh, your framing makes sense to me. TC started describing one including CRLF normalization that also makes sense. I'd like to see it written out. Could we try out our new conflict resolution process?

TC: I agree with Tyler theres' a risk of doubling down. But the conservative thing is to reject the CR. Josh said we could allow the CR for now. But that's not how it works -- stability guarantee. We could reject it and allow it later. I think the right thing to do is to reject the CR for consistency with the grammar. We don't want to expose the details of the CRLF normalization.

Ed: If this still would be raw string vs linting. But this new CRLF normalization concern intriguing. It's hard for me to evaluate without knowing more. It could be like CRLF where front matter ends up neutral. My assumption would be for TC to write up his concerns with CRLF normalization problems and why we need to reject this from the grammar.

TC: Tyler, Ed: you've seen I wrote up this comment on the issue?

Ed: I don't recall you calling out a CRLF normalization.

TC: https://github.com/rust-lang/rust/pull/148051#issuecomment-3782660300

Josh: TC, sounds like you'd like to push for rejecting CRs that survive normalization across the board everywhere in Rust consinstently going forward.

TC: Right. Eric and I keep running up into this: why do we allow CRs after normalization. We'd liko to consider the a rule of doing a single-pass CRLF normalization and then rejecting any CRs left. My primary driver is grammar simplification.

Josh: For the purposes of front matter alone: I'd advocate our correct position is to leave it alone. Parse delimiters and ignore everything in between. However, if the position is "across the board in Rust we should try to remove CRs across code" that as a simplification feels it has merit to it. So there, if the goal is to hold space for any CR rejection across the board, I wouldn't object to removing CRs.

Josh: In terms of parsing, if we wanted to reject CRs across the board, we'd need a crater run. If we allowed them in the front matter for the time being, and rejected them later, we'd need the same crater run but also reject in front matter.

Jack: +1

TC: We could do it over an edition.

TC: The framing I'm putting for is: do the conservative thing and reject CRs now. We do that in a lot of other places and relax it later if we need to. If we relax it now, we wouldn't get it back. I don't see a usecase for CRs that pass CRLF normalization.

Josh: I'm trying to suggest this isn't clear to me that this is the conservative choice. My framing is: it's not that theres' a specific usecase for having CRs. It's that doing something is more complicated than doing nothing. "nothing" here is just passing the front matter to the tools.

TC: I see the consistency going in the other direction.

Niko: I follow TC your point that crater will not be an effective tool for finding cargo script in the future. So you're nervous about making changes there. I also follow Josh's point that this is unlikely going to be a blocker.

Niko: When do we do CRLF normalization currently? Does it apply across the board?

Josh: The only job of rustc is only to skip the front matter.

TC: There are toher tools like rustfmt and rust analyzer

Niko: When do we treat CRs in Rust code?

TC: Doc comments, strings, raw strings, there's a ton of places where you'd expect `Char*` in the grammar you see `[Not CR]*`

Ed: When CRLF normalization happens -- that happens before any lexing ever happens.

Ed: TC, this is a black box to Rust. Rust is a container format for this. But if we're framing this in terms of "we're leaving room for a future change and we're seeing this as an implementation detail before that change happens". Then I see this as a stopgap until Rust removes it and the front matter ??

Josh: I would continue to advocate against us needing to do front matter specially to hold space. But front matter is important. Cargo scirpt is an important feature. Whether we block or don't care about CRs is not going to affect the usage of the people. So whichever position can pass consensus, we should ship and do. In one direction it's free to do (going from error to not error), in the other direction it's not free to do but still possible. Either way we should pick the one that's faster to move forward with

Ed: TOML does reject stray CRs also. So anything that gets parsed by cargo it will be safe.

TC: Eric Huss and I've spent hours many weeks trying to formalize the grammar. It's hard to me to express certain aesthetic points that come to me when doing this. If the group wanted to override me on this, it would bring me bring closer to your concern resolituon.

Tyler: My suggestion was to use the concern resolution template, not to try and override someone's concern.

Niko: It seems to me that usually when there's a simple forwards compatibility and no strong usecase, that's the simpler way to resolve this. Is it hard to block CRs? Why not just block them for now and maybe lift them later?

Josh: The total importance of the CR issue feels incredibly low compared to the value of front matter. So: can we get consensus on rejecting CRs and ship the feature?

Ed: That was my point: is anyone against just rejecting them for now? This is just temporary until TC cleans up the grammar and rejecting them in the future. Compared to the original T-lang conversations, the CRLF is a new concern. I'm fine with blocking CRs and moving forward.

TC: Good. I look forward to that PR merging. Ed, is there anything else?

Ed: There's also the item context. Has that been resolved yet?

Jack: That either needs to be documented in the reference. Or we need to decide to disallow ..

TC: I'm happy to ship frontmatter with it being consistent with shebang removing today. I.e., in item context, both the shebang and frontmatter are stripped; in expression context, neither are stripped.

Ed: I'm fine with that.

Tyler: I'm fine with that.

Jack: I don't care either way. I want to make sure the team is clear that this adds another place where there's context-dependent include shebang.

Tyler: As long as we're consistent with the existing behavior and not add further branching in the decision tree, that's fine.

Jack: Josh, did you have a thought on this?

Josh: I want to see a crater run stripping all shebang but I don't feel it should be a blocker. I felt we had an inconsistency where we were doing one kind of stripping of front matter and shebang. Now that inconsistency is no longer there. But we should make an appropriate crater run to drop the stripping entirely. But that shouldn't hold up front matter because we're now consistent with the other things.

Josh: Shebangs didn't have a lot of value without cargo scripts. Now it has value and people will start using it. But still, ship it and we'll do tat experiment separately.

TC: We know how to resolve the CR concern, the documenting CR removal, Jack do I understand you'd be okay with resolving the advisor concern.

Jack: Yes. As long as everyone is fine with this.

TC: Scott and Tyler this could use your checkboxes on the FCP.

Ed: There's still an overall blocker on docs.

Josh: They're currently tot allowed in doc tests?

Ed: I think fmease doesn't want them allowed, I need to ping them again on it and get a clarification.

Tyler: Sounds like we're not stabilizing info strings with this?

Ed: We're parsing a single info string with no attributes after it. I.e. `---cargo`

Josh: do ew want to allow CR: we agreed to not allow them

Josh: Sholud we

Josh: Document front matter removal -- has that been resolved?

TC: We needto check the Reference and we'll get back.

Josh: For rustdoc, do we feel we should raise a concern for them or not?

TC: I think it's within our purview to file a concern on behalf of other teams. I don't feel strongly to file concern here and I'd rely on `r+`.

Josh: I was raising the question to verify if any of us should. I agree with you.

TC: I'll resolve the CR concern when that corresponding PR gets merged.

Ed: I'll update it as soon as this call is done.

Tyler: Do we allow whitespace between the dashes and info string?

Ed: We do allow whitespace. The style team wanted to encourage one space.

Tyler: I'm happy to check a box.

Josh: I want to rewrite half my shell scripts now.

Ed: I use these every day. Every time I see an issue, I'll write a cargo-script to reproduce it.

(The meeting ended here.)

---

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

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

### "`#![register_{attribute,lint}_tool]`" rfcs#3808

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

### "`RUSTC_ALLOW_UNSTABLE_<feature>`: a `RUSTC_BOOTSTRAP` alternative" rfcs#3882

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

### "CMSE calling conventions" rfcs#3884

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

### "RFC: Exhaustive traits. Traits that enable cross trait casting between trait objects." rfcs#3885

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

### "Complex numbers" rfcs#3892

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

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

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

### "RFC: cfg_target_version" rfcs#3750

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

### "repr(ordered_fields)" rfcs#3845

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

### "Match guard can both move and static-promote a single constant" rust#145237

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

### "`ref` patterns can const-promote a single constant more than once" rust#145555

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

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

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

### "Decide about future of `rustc_legacy_const_generics`" rust#146613

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

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