owned this note
owned this note
Published
Linked with GitHub
---
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.
```rust
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