---
title: Triage meeting 2023-01-10
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2023-01-10

## Attendance

* Team members: Tyler Mandry, Josh Triplett
* Others: y86-dev, simulacrum

## Meeting roles

* Action item scribe: simulacrum
* Note-taker: Tyler Mandry

## Scheduled meetings
- No pending proposals this time.

## Announcements or custom items

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

## Action item review

* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)

## Pending lang team project proposals

None.

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**
### "Tracking Issue for "C-unwind ABI", RFC 2945" rust#74990

- **Link:** https://github.com/rust-lang/rust/issues/74990
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/74990#issuecomment-1363474839):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * docs (https://github.com/rust-lang/rust/issues/74990#issuecomment-1364528477)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/74990#issuecomment-1363474832):
> Shall we stabilize the `extern "C-unwind"` and other `-unwind` calling conventions? This change will leave `extern "C"` unchanged for now, but have the existing feature gate continue to opt into the new behavior on nightly. We'll do a separate change later to make `extern "C"` and similar not permit unwinding.
>
> @rfcbot merge

tmandry: Took an initial look, want to go over everything again to see if there's anything that jumps out.

## Active FCPs
### "Create an Operational Semantics Team" rfcs#3346

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

### "Tracking issue for RFC 2515, "Permit impl Trait in type aliases"" rust#63063

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

### "Stabilise inline_const" rust#104087

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

josh: Lots of back and forth over what the RFC precisely means. Not necessarily a blocker.

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "Properly allow macro expanded `format_args` invocations to uses captures" rust#106505

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

> Should format_args! invocations that were generated by a proc-macro be able to use implicit argument captures?

tmandry: My expectation is yes *if* the span comes from code that can name the variable.

josh: Sounds like that requirement didn't exist before, and now I'm not sure we can break backward compat.

josh: Two pieces of evidence for things that would break: indoc and ...

tmandry: Is this a feature for them or accidentally relying on it?

josh: Doesn't sound accidental.

mark: Seems like this PR is checking whether a person actually wrote a literal in source, which seems like the wrong direction. Macros should be able to concoct their own source literals

tmandry: Agreed (as long as the span is correct)

mark: RFC 2795 restricted to source literals because it might be too confusing, but if your macro expands to a format args string it seems like it should just work.

josh: Don't necessarily want to build an expectation that other macros will work based on `concat!()` working.

mark: But if you have a proc macro and it attaches the correct span it should work.

tmandry: Fine with summarizing the point about what it *seems* like the ideal behavior would be and why it's feasible, and asking for clarity here.

mark: Maybe worth reverting PR since it breaks actual crates, instead of fixing rare ICEs. Top priority is fixing nightly. (tmandry: Will do.)

y86: Seems like this PR (to fix the ICE) is between the RFC and what was there before.

https://rust-lang.github.io/rfcs/2795-format-args-implicit-identifiers.html#macro-hygiene

### "Edition Based Method Disambiguation: Preventing inference ambiguity breakages with extension trait methods" rfcs#3240

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

josh: Idea is to allow changing signature of a method in, or avoid introducing a method until, an edition.

tyler: How would this help with preventing conflicts with existing methods in extension crates?

josh: We'll defer the breakage to an edition and batch them there. Not necessarily the tool we have to use every time – I think we should look at *whether* something would have widespread breakage and decided to use it then.

josh: We had a hack for `[]::into_iter()`, this is a more general solution for something like that.

mark: Someone mentioned tagging T-compiler, though I'm not sure that's necessary. Perhaps we should ask petrochenkov as the resolution expert.

josh: Also we should do the work to cc lang advisors on any RFC that involves t-lang (when FCP is initiated).

mark: Easiest way to do that is in triagebot. Something in label-based automation. Hard part is doing it across the org automatically.

mark: Will take a look.

felix: Question about meaning of "crate matches the new edition" wording.

josh: I think that should mean "matches that edition or newer". If you think it could be more clear, please comment or leave a suggestion.

josh: Two cases are <, and >=.

### "inline_const does not evaluate in unused function" rust#106617

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

felix: Asking what the desired semantics are.

josh: I would expect that it should always be evaluated

felix: Do we want this only if it's monomorphic? / Are we stuck in a world where we have to handle monomorphic functions specially?

mark: In const items you can't use generics. In const blocks you can, so we never eagerly evaluate them.

josh: Is this similar to the concern raised on the inline const stabilization? You can use generics in them, and they can have monomorphization-time errors.

tyler: The distinction between const items and const expressions makes sense to me. Makes this seem like a non-issue.

y86: If you want eager evaluation / compile time error you should use a const item for that.

fn run<T>() {
    const { assert!(std::mem::size_of::<T>() > 0) };
}

mark: I would expect that to fail at compile time if you call `run::<()>();`. If you use it we're going to evaluate and throw a hard error.

josh: Would we guarantee we use it if it isn't generic?

y86: Sounds like that would be inconsistent, but not documented.

tyler: My expectation would be that control flow needs to reach the point (either at run time or compile time, during const eval of some const item) to get a panic / compiler error.

y86: but that does not seem to be the case currently: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=29c44ff12da623b5dcc0bbc247529ad3

tyler: Feels wrong to me.

y86: This is due to the desugaring of the const block, which is to make it into an associated constant.

josh: Torn between whether that seems like an implementation-dependent view, and whether there is any other feasible implementation.

mark: If we wanted to do significantly better we'd need to do symbolic evaluation

tyler: We could change a use of the expression to a panic in MIR or something

mark: Diverges from what we do today, e.g. with static_assert, where you really want failure at compile time.

tyler: I could be convinced but my initial feeling is that const expressions seem fundamentally different in this way; don't involve always evaluating.

mark: You could imagine cases where you want to rely on compile time failure.

tyler: Question of what use cases there are for using const expressions for that. They can do more things like name generics, are there cases where they want to do that *and* rely on compile time failure?

mark: Could possibly change across an edition.

felix: I think we kind of have to make a decision since we don't want people relying on it for UB detection.

y86: People do have the option to panic at runtime.

mark: Feels like using const for "please evaluate eagerly at compile time for performance" is not the use case for this.

tyler: I would expect them to be used for that.

josh: Let's please follow up on the issue async; file a concern to pause stabilization if you feel like we should do something substantially differently.

## Nominated RFCs, PRs and issues NOT discussed this meeting

### "RFC: Start working on a Rust specification" rfcs#3355

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

### "Implement a lint for implicit autoref of raw pointer dereference " rust#103735

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

### "make &mut !Unpin not dereferenceable, and Box<!Unpin> not noalias" rust#106180

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

### "Clearly specify the `instruction_set` inlining restrictions" reference#1307

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