---
title: Triage meeting 2022-02-01
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-02-01

## Attendance

* Team members: Niko, Felix, Josh, Scott
* Others: compiler-errors, Lokathor, David Barsky, Jane, simulacrum

## Meeting roles

* Action item scribe: simulacrum
* Note-taker: nikomatsakis

## Scheduled meetings

- Tomorrow: planning meeting!

## Announcements or custom items

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

### `asm!` stabilization and documenting supported (and unsupported) directives.

* Discussion on t-lang Zulip
* current definition is (llvm asm) intersection (gnu AS)
* May want to add documentation on which directives are supported inside asm
* notably, macro directive seems pretty likely to be something we want to avoid
* `asm!` will ship stable in next stable version
* future compilers may (at least partially) parse and warn on such usage, but not necessary to stabilize.
* josh: No action needed here but wanted to ensure
* if somebody wrote up a document with what we intend to support
* if we saw that as a PR to the reference or the `asm!` docs
* would we be willing to merge?
* nikomatsakis: current status is that they're "just" accepted?
* josh: yes, and that doesn't change, this would be documentation
* lokathor: concern was that someone was working on an alternate backend that didn't support all these features (not based on llvm / gnu)
* josh: right

### Project board update (nikomatsakis)

* More up to date but not *yet* complete:
* https://github.com/orgs/rust-lang/projects/16/views/1
* nikomatsakis to write up guidelines but in short
* create a tracking issue, tag with T-lang, C-tracking-issue
* assign to the liaison / owner
* if there is a repository, create the tracking issue on there; if not, on rust-lang/rust or rust-lang/lang-team is fine
* set the status appropriately

### Status reports

* nikomatsakis: Did want to raise the question of status updates -- we still haven't really built the infra to do this, just wanted to sync up on this
* simulacrum: in our last discussion we talked about tying this to triage meetings, but that didn't yet materialize
* josh: had a conversation with someone interested in contributing by process or coordination, I mentioned to them we could use help figuring out how to scale up status etc, and they seemed excited about doing that, was planning to setup a conversation between them, niko, and myself to talk about how that should look
* don't think anyone in this meeting is super excited about sending pings or building infra, so it'd be great to have help

### RPITIT update (nikomatsakis)

"Return position impl trait in traits" / tmandry and nikomatsakis had some discussions about this.

trait Foo {
    fn bar() -> impl Trait;
}

impl Foo for u32 {
    fn bar() -> impl Trait;
}

impl Foo for i32 {
    fn bar() -> String;
}

If we know specifically which impl applies, you get the concrete type (if one is given).`i32::bar()` would return `String` and not an opaque type.

tmandry was drawing an RFC about this idea as a general principle:

* If the trait and impl are different, the impl is "specializing" the trait interface and when we know which impl applies, we should use that.
* Accepted an RFC along these lines already for `unsafe`, this would generalize it.

josh: Is this effectively covariance?

niko: yes, you could think of it like that.

pnkfelix: would it permit `impl Subtrait`?

niko: yes.

josh: to be clear, if `impl Foo for i32` still said `-> impl Trait`, it internally would be allowed to know it returns a `String`, right? So it's more for users of the trait.

niko: I think the impl trait with this notation is scoped to the function, not the entire impl, but we could do it either way.

josh: it seems like we would want the desugaring to be...

// if you write
impl Foo for i32 {
    fn bar() -> impl Trait;
    fn otherfunc() {
        ... bar() ... // this should get to know the concrete type
    }
}

nikomatsakis: this is further in than I wanted to go, but you can use TAITs to get a lot of precision...

type Bar = impl Trait;
impl Foo for i32 {
    fn bar() -> Bar;
    
    fn otherfunc() {
        ... bar() ... // this should get to know the concrete type
    }
}

scottmcm:

trait Trait {
    fn foo() -> impl Debug;
}
impl Trait for Foo {
    fn foo() -> i32 { 0 }
}

<Foo as Trait>::foo() // would this know the specific type?

pnkfelix:
strawman syntax:

impl Foo for T {
    pub(impl) type LocallyKnown = i32;
    fn foo() -> LocallyKnown { ... }
    fn otherfunc() { /* knowns LocallyKnown == i32 */ }
}

oh but this is essentially niko's TAIT example

### Never type (nikomatsakis)

Mark and I are having misgivings about `!` because the rules are seeming more complex than we'd like, but the simple rules have concrete downsides.

scott: Does that mean that `return` would not have type `!` but instead an uninferred inference variable?

niko: Not exactly sure, we'd have to answer some of those questions.

josh: upshot is having less special rules and being less automatic

mark: yes, less special case, I'll note that if there are use cases for `!` special cases.

josh: design meeting?

mark: yes, I can file an issue.

josh: I would definitely like more context.

david: I was wondering if inline asm reduces pressure for the optimization benefits of never type?

mark: I don't think it's really got strong optimization benefits, certainly not over empty enums.

scott: layout wise, it's the same, but the main difference is that the compiler is a bit smarter around some things with never specifically, assuming you have the feature gate, you need more matches with no arms without the special never type. That said, details tbd, but some sort of "let's just cut it back to something simpler we can do", given that I know a lot of smart people have looked at this a lot, making it happen by simplifying the rules seems like a good idea.

josh: Another question for design meeting, to what extent can we be forwards compatible if we figure out ways to be more clever later?

### Current status of a global singleton `impl Trait` mechanism?

- e.g. having a single crate-wide implementation of `impl AsyncRuntime` or `impl Allocator`
- wg-async looking at this

- niko: I don't know of anyone actively looking into this, but I'm more interested in [scoped capabilities](https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capabilities/) as a route to solving this. It seems better to me to be non-global.
- josh: I think there are tradeoffs between the global crate-wide version and scoped capabilities, would like to talk about those tradeoffs
- josh: do you think the global version if completely consumed ?
- niko: yes! well, maybe.
- pnkfelix: there are probably things to consider, make sure all uses cases are covered.

## Action item review

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

## Pending lang team project proposals

### "inner crates, aka multiple crates per file" lang-team#139

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

josh: lots of discussion on Zulip, pnkfelix do you want to elaborate?

pnkfelix: I wanted this for contexts that tend to be a single file, doc blocks, playground-- it's hard to express multicrate examples in these contexts. I've seen people write system calls to generate and compile files.

pnkfelix: one thing I will note is that I claimed this could help solve the proc-macro phasing problem (how they need to be in a distinct crate), and people pointed out in the zulip discussion that there would be a whole host of problems associated with that, e.g. host vs target machine. So I take it back as a motivating example, but I still think there is motivation here.

One assertion was that it might help the efficiency of compilation problem by letting people migrate their existing code to multiple crates.

josh: Also the issue of interaction between this a macros / cfg. Can you generate an internal crate like this using a macro? etc

pnkfelix: in my head, this would occur before macro expansion. petrochenkov pointed out that we have no precedence for something like that.

josh: I'd expect a different syntax to ensure it gets parsed at the right time.

If this is primarily motivated by the playground or examples, next best alternative would be special-cased support in the playground or doc tests. Something that lets you make an external crate. That's an alternative to trade off against, right?

pnkfelix: yes, we could special purpose.

josh: e.g. playground could have a "+crate" button

pnkfelix: yes, that's a larger overhaul.

josh: sure, but we're trading off where to do the work (playground vs Rust).

nikomatsakis: There are other use cases, I think idiomatically lots of private impl crates is common, and there are things like the facade where you want coherence rules to stretch across.

Jane: they're have been proposals for this, right?

nikomatsakis: yes.

pnkfelix: c-reduce may be another example-- something that only operates on a single file. Many cases where having it in the language versus each tool having to support multiple files. At some point it stops making sense to have each tool support this scenario over and over.

mark: c-reduce does not support multiple crates.

david barsky: Something I'm seeing at work where this would help is a bazel-style build system. In a lot of cases, I would personally prefer to do my inner dev loop with cargo potentially. The way that projects are structured doesn't fit with cargo, but this might help, so I would register interest.

josh: to interrupt, is there any further discussion valuable to have in this live meeting, versus continuing on the Zulip thread?

(other items not discussed)

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**
### "Tracking issue for naked fns (RFC #1201)" rust#32408

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

Josh: Proposal here is to close the "unrestricted" naked functions in favor of "assembly only" naked functions. Just in need of three further checkboxes.

### "Make `unused_lifetimes` lint warn-by-default" rust#92386

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

Josh: Blocked waiting on us in terms of "are we prepared to do this". A few blocking concerns that we want to see made. Tagged as waiting-on-team, but I think it is actually waiting-on-impl, right?

Mark: Pretty sure this is blocked on the changes to the lint being made.

### "Allow `impl Fn() -> impl Trait`" rust#93082

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

Josh: I'd like to find the next steps here, for RPITIRPIT (return position impl trait in return position impl trait...). Do we want to close this FCP now because of the stack of things that need fixing?

Niko: I would rather see a fresh proposal with the narrower version, if we think that narrower version is worth pursuing.

Josh: Niko can you poke the proposer and get it redirected?

Niko: Yes, I will do that.

## Active FCPs

(Skipping over these.)

### "Positional Associated Types" lang-team#126

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

### "Interoperability With C++ Destruction Order" lang-team#135

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

## P-critical issues

### "Named format arguments introduce implicit positional arguments" rust#93378

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

Josh: I agree with Mara this should get fixed quickly.

> Open PR - Don't allow {} to refer to implicit captures in format_args. #93394

Josh: this is tagged T-compiler. To the extent that there is lang consideration, shall we just respond and say "from a lang team perspective yes please fix this as quickly as possible".

Felix: Might be a good idea to look over the #93394 tests but yes I'm fine with that.

Scott: This is pretty clearly an accident.

Niko: Side note, I love this feature.

Scott: I used it to make URLs and it was so much easier than it had a right to be.

## Nominated RFCs, PRs and issues

### "`no_mangle`/`used` static is only present in output when in reachable module" rust#47384

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

### "Automatically implement AsRepr and allow deriving FromRepr for fieldless enums" rust#81642

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

### "check Projection supertrait bounds when confirming dyn candidate" rust#92285

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

Niko:

* Fixes https://github.com/rust-lang/rust/issues/80800
* `trait Foo { type T }`
* `trait Bar: Foo<T = u32> { }`
* `dyn Bar<T = i32>`
* Main question is do we require a warning period
* No impact on crater
* Any concerns about just landing the fix?

Scott: soundness fix with no crater impact sounds good to me.

Mark: I might ask for a comment that we can paste into release notes.

Niko: That sounds like a very reasonable ask.

Josh: Yes, please write the release notes snippet.

Action item for Niko: write up release-notes snippet

Michael Goulet: we haven't done a crater run for the more general case, so that might break, though I think the cases are correctly wrong.

Niko: Do we have a test?

Michael Goulet: there was a test that failed, because Any requires static. If you check the changes in the last day, you'll see the test fails.

Niko: I'll take a look, I'm glad we made the fix better though!

Felix: I'm guessing it would be difficult do a warning period?

Niko: painful, maybe possible. We could probably use the evaluation machinery. But it seems hard.

Josh: Any legitimate reason to use this? If anyone is depending on this, would have to be by accident?

Niko: It's gotta be a bug. Not the kind of type system bug where you said a reasonable thing that the type system isn't smart enough to handle; more like you said two inconsistent things.

Josh: Let's see if crater turns up anything broken.

Niko: If nothing else, always good to be able to ping crate authors and give them a heads up.

### "[experiment] proc-macro: Stop wrapping `ident` matchers into groups" rust#92472

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

### "Check if enum from foreign crate has any non exhaustive variants when attempting a cast" rust#92744

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

Scott: Looks like a PR for disallowing casting of non-exhaustive enums, since that makes non-exhaustive not work. There's a crater run. I hadn't looked into the errors, but the ones I just clicked on was a false failure.

Josh: So the issue here is effectively if an enum is field-less we would normally let you cast it, but if it is field-less but non-exhaustive, it may stop being fieldless in the future?

Scott: Correct. Issue is #91161.

Josh: Are we disallowing this for a variant that is not-exhaustive? A non-exhaustive enum? Both, right?

Felix: do you think that no-exhaustive is meant to cover adding both variants and payloads?

Scott: This specific issue the *variant has no fields* but because the variant

Niko: but the new variant you add might have a payload itself, like if you added `C` here:

#[non_exhaustive]
enum Foo {
    A,
    B,
    C(u32) // if added later, breaks as casts
}

Josh: Didn't we already decide to disallow casting for `Variant {},`? Do we allow `#[non_exhaustive] Variant,`, and is it not breaking to make that `Variant { field: u32 }` later?

Scott: I can't remember where that conversation landed.

Niko: We had a meeting but I can't remember what fell out from that.

Scott: My recollection was that this came up during some part of that discussion and I opened a bug about it.

Josh: Are we going to only make this change with crater?

Niko: I would want a warning period if there are a lot of affected crates, but I would want to make the change either way.

Josh: OK, starting an FCP seems like a good idea.

Niko: Plus one.

Josh: You can check my box. :heavy_check_mark:

### "Tracking Issue for scoped threads" rust#93203

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

Josh: This is the *kind of thing* I'd love to see us process offline. There's an unresolved lang question for "could we do better on the API here". That's something we can try to evaluate offline. Effectively, libs is asking "Could lang offer us better alternatives that would mean we should defer stabilizing this API". I suspect the answer is "no we can't" but we should confirm that.

### "Named format arguments introduce implicit positional arguments" rust#93378

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