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

# T-lang meeting agenda

* Meeting date: 2022-03-01

## Attendance

* Team members: nikomatsakis, Taylor, Scott, Josh
* Others: Mark, Lokathor, Mara, Jane, lcnr, Urgau

## Meeting roles

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

## Scheduled meetings

* Planning meeting tomorrow!!

If you have proposed design meetings, open issues on the lang-team repository regarding them!

## Announcements or custom items

### Proposed "traits team" or "formality team"

* [Discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/making.20a.20team.20for.20traits.2C.20polonius.2C.20etc):
* [Charter doc](https://hackmd.io/@nikomatsakis/rJ3h_-kJc)

> The "traits team" is dedicated to implementing and guiding the design of the "core type system" for Rust, including the type checker, borrow checker, and trait system. The traits team also maintains formalities, a formal model of the Rust type system.

One highlight, an experimental formal model for Rust: [a-mir-formality](https://github.com/nikomatsakis/a-mir-formality/)

Niko's initial goal: "modeling implied bounds + coinductive trait matching (that enables perfect derive)"

## Action item review

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

## Pending lang team project proposals
### "Deprecate target_vendor " lang-team#102

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

### "Async fundamentals initiative" lang-team#116

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

### "Attribute for trusted external static declarations" lang-team#118

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

### "Support platforms with size_t != uintptr_t" lang-team#125

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

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

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

### "Heap allocations in constants" lang-team#129

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

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

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

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

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

### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143

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

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**
### "Tracking Issue for RFC #2972: Constrained Naked Functions " rust#90957

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

joshtriplett: Seems to have stalled out. Do Taylor/Felix/Scott have concerns or just lost track of it?

scottmcm: blockers?

joshtriplett: last thing I remember was getting a list of attributes that are valid or not, which is now documented.

Lokathor: .section seems to be broken with global_asm! in at least some cases, and in those cases using a naked function has been the fix

joshtriplett: say more?

Lokathor: (more about the .section issue, then) naked functions are more useful than they seem as they solve one current bug.

joshtriplett: Has that bug been reported?

Lokathor: No, very hard to reduce to something debuggable.

joshtriplett: even without a minimal repro, would be good to report the issue so it can be tracked. Is it public?

Lokathor: I think they are both public

joshtriplett: then people could help with the minimization

nikomatsakis: +1 to filing a bug and seeing if others can help reduce it

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

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

scottmcm: Niko, did you mean to resolve your concern?

nikomatsakis: oh shit, yes.

joshtriplett: Could someone look at https://github.com/rust-lang/reference/pull/1169 and review?

nikomatsakis: is it blocked on stabilization?

joshtriplett: I don't think so, I think it's primarily documenting existing behavior, but I'm not suggesting it as a blocker for stabilizing. But it would be really useful to have those docs land.

### "Stabilize `let else`" rust#93628

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

nikomatsakis: I'm super into this but also a bit concerned about some of the details. Is someone following along here?

scottmcm: +1

cramertj: I don't have my box checked, I was waiting on the concern regarding temporary lifetimes.

nikomatsakis: I was concerned about temporary lifetimes and generally saw some comments that made me a bit nervous, things that hadn't been included in the stabilization report. Wanted to be sure that things are being followed up on and we can evaluate.

joshtriplett: for temporary lifetimes, not just a matter of "this needs to be summarized", also a "is this doing what it needs to be doing". Context is that the original desugaring described in the RFC -- implementor found that really common patterns don't work with that desugaring. Don't have the PR number handy, but somebody as a result did a "native impl" of let-else, effectively, giving it its own separate representation. That addressed the initial issue, so that most code people wrote would be fine, but there's still a further issue (addressed by #94012). I've not followed exactly what the temporary lifetimes issue was, other than to see "here is the difference between let-else and a normal let in drop location". The question then becomes "if we change it so that let-else behaves that way, would that break anything people are doing".

nikomatsakis: I feel like we need to review this closely, it's probably me or pnkfelix who is most familiar with those rules.

joshtriplett: I think there are people actively working on this, but help would be welcome from an expert on those rules. Somebody dropping by, taking a look at the proposal, would substantially help I expect.

scottmcm: cormacelf left a comment 14 days ago with an expander that details the history of things.

joshtriplett: the one that starts with "to summarize it..."? (yes) that was the source for my earlier statements.

pnkfelix: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=97844d29f488fec5bb242e38d8635483

pnkfelix: Understanding I have is that the open PR does not resolve the issue raised in [this playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=97844d29f488fec5bb242e38d8635483). Simple enough example to look at now.

fn main() {
    {
        let _ = Droppy::default().0; // <-- drops here
        println!("Drop should have occurred");
    }
    {
        let _ = Droppy::default().0 else { return };
        println!("Drop should have occurred");
    } // <-- drops here
}

pnkfelix: my instinct is that this is a blocker. Curious if there is a reason that this pattern is important.

scottmcm: agree with the statement that `else { unreachable!() }` should not change its behavior.

joshtriplett: I'm mildly surprised that -- I thought from the original RFC that `let else` on a irrefutable pattern was considered an error. Didn't realize it was only a lint? Possibly we changed that because macros?

nikomatsakis: we should add that to the stabilization report!

scottmcm: feels a lot like dead code, which is also not an error.

nikomatsakis: did a [write-up of the temporary rules]( https://hackmd.io/TT5mmiwtTZKESnlPT_2Fnw) recently, would love to get some of this stuff better documented in the rust reference

joshtriplett: possible to reproduce this in a context where let is refutable?

nikomatsakis: (for the record, I agree with scottmcm that permitting irrefutable patterns and flagging it as dead code is reasonable).

joshtriplett: I can confirm that if you change this to `let 0 = ...` then you still get the same bug.

nikomatsakis: (summarizes from document above) meant to cover cases like this:

let x = &Droppy::default();

pnkfelix: compare against: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=57e814fa57019bc62930bc9d61c894da

pnkfelix: (which adds `&` to the playground example.)

joshtriplett: I think that making `let else` match `let` here should work fine as long as we have test cases that (e.g.) borrowing a lifetime that needs to last until end of block works

nikomatsakis: right, something like this:

let Some(ref x) = Some(Droppy::default()) else { panic!() };
// or, equivalently,
let Some(x) = &Some(Droppy::default()) else { panic!() };

pnkfelix: yes, we have to test both sides of the coin (dropped at end of statement vs end of block) and driving this via the reference seems good.

joshtriplett: seems like it should be a blocker for stabilizing let-else.

pnkfelix: I'll register a concern

joshtriplett: niko has a concern raised at the moment. I think we now have that summary, we know what the current issue is, so I suggest niko resolve the "summarize concerns" item and simultaneously raise a concern for "need to deal with temporary lifetimes".

pnkfelix: I'll register concern, nikomatsakis can resolve his separately.

simulacrum: you had a concern about the irrefutable pattern being just a lint, should that at least be in the stabilization report?

joshtriplett: I'll double check original RFC to be sure first. Oh, never mind, I see that it is doing just what the RFC said.

### "Stabilize ADX target feature" rust#93745

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

* all set!

## Active FCPs
### "Stabilize const_fn_fn_ptr_basics, const_fn_trait_bound, and const_impl_trait" rust#93827

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

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

None.

## Nominated RFCs, PRs and issues (discussed)

### "Stabilize --pretty=expanded" rust#43364

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

joshtriplett: I believe we've discussed this a few times and just need to clear the nomination.

nikomatsakis, silently: :tada:

### "Always evaluate all cfg predicate in all() and any()" rust#94295

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

joshtriplett: proposes that we remove the current short-circuiting behavior of predicates in cfg. The motivation is that a mechanism is being added to the compiler to tell "all the cfgs that might exist, even if they're not enabled", which allows the compiler to do "typo" testing: "this isn't a known cfg, maybe you made a mistake".

joshtriplett: this particular approach went through and evaluated every cfg predicate, which causes some regressions detected by crater. Hits cases where people write an unstable feature "further to the right" in an `all` where on the left they have `feature = "unstable"`. There are 3 regressions, 2 of which are just bugs (used invalid syntax on RHS of an all). The other is "used all where future-unstable is selected"....oh, wait.

pnkfelix: I think these are all bugs, right?

scottmcm: they all look like bugs to me.

joshtriplett: ooooook, so they're all bugs, but the question is, is this behavior we actually want? nobody has apparently used this short-circuiting behavior, but you could plausibly use feature=unstable to gate something. Example: when target_abi was unstable mechanism (or was at some point). If you have an unstable cfg predicate, you could do `all(feature=unstable, nightly_only_cfg_predicate)` and today that would be ok. Nobody apparently *does* that.

scottmcm: if you did need to do that, after this PR, you could use two CFG attributes, right?

pnkfelix: you can't express the any shortcircuiting, right?

scottmcm: true

pnkfelix: not that I think there's a reason to worry about that

joshtriplett: agree any is less likely to come up

joshtriplett: question for us is, do we want to *allow* shortcircuiting? we *could* go and parse the RHS even if they shortcircuit to see what is referenced. but if we do that we will not necessarily work on a stable compiler that doesn't know about a nightly feature yet. it's a tradeoff.

nikomatsakis: the fact that you can rewrite to nested cfg's is good, b/c it gives us a workaround, but it is also kind of a bug, since you will not get a warning if you do nested cfgs but you will if you use `all`

joshtriplett: we could look inside the cfg

scottmcm: these feel like a warning, not an error

pnkfelix: comment thread suggests a hard error...?

simulacrum: I'd expect deny-by-default lint

joshtriplett: error if you use invalid syntax, lint if you use the mechanism for possible cfgs to know about

joshtriplett: does anybody feel like this should be shortcircuiting? does anybody feel like it *shouldn't*?

nikomatsakis: when you say shortcircuiting, is the only visible side-effect (a) whether or not you get a lint and (b) whether invalid syntax are detected?

joshtriplett: can anybody think of anything else?

m-ou-se: can't you call proc-macros there?

joshtriplett: 1) probably, 2) why am I not surprised that you're the one who thought of that?

m-ou-se: time to put in some python code !!

m-ou-se: a few months ago it was changed that you can have macro expansion in attributes for doc, does that work for configure?

pnkfelix: cfg is special, but maybe...

joshtriplett: excellent question. I can imagine someone ... in theory we could add a cfg predicate that lets you test if A == B, using some compile-time constants, not const declarations, but something available to cfg, and in theory you could say "cfg include-str something is equal to this". Horrible but could make sense to have shortcircuiting.

m-ou-se: macros don't parse btw, you get a parser error.

joshtripett: seems ok.

m-ou-se: doesn't even treat `!` as a macro

nikomatsakis: I think it is supportive to give warnings to people who have typos in an `all`. I do not want to commit to evaluating the RHS in general yet, but it seems like we're not committed yet. Since it's a lint, it implies to me it's "best effort" anyway, so we have room to add macros or whatever in the future. If that means you don't always get a warning, that seems fine.

joshtriplett: you'd prefer, iow, not to commit

nikomatsakis: I wouldn't want to foreclose the possibility of having macros, and if we were, I think it'd be useful to be able to control whether they get evaluated. But I don't think we are.

joshtriplett: today you can do "all(feature=nightly, ...)" and if `...` uses something that only works on nightly rust...

m-ou-se: alternative is to put the cfg in a cfg-attr, right?

joshtriplett: right.

m-ou-se: I think that's how we do it with bootstrap.

joshtriplett: if we want to say, if you ever want to do this, you should use `cfg-attr`.

nikomatsakis: I prefer the nested case, it seems clear to me to say "we will parse the entire attribute and it has to be syntax the compiler understands".

joshtriplett: I'm in favor of making cfg less complex and less capable.

m-ou-se: We still parse the whole thing, so any new syntax would still have to be parsable.

joshtriplett: Right, it would only work for things old rust can parse and just doesn't understand (e.g. `token = "thing"` where new rust assigns meaning to `token`)

nikomatsakis: I still think there is room, if we add macro expansion, to decide *then* whether we will expand the macro eagerly or wait until the all is evaluated (though I don't know which I think is better). But I think it's fine to parse and detect invalid (or not yet valid) syntax and require a nested cfg for *that*.

### consensus

- we wish to require all predicates to parse as valid, even if an earlier item is not satisfied
- we wish to give warnings on all parts of an `all`, even if an earlier item is not satisfied

josh to report

### "Tracking issue for `const extern fn` and `const unsafe extern fn`" rust#64926

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

TL;DR you can give an ABI to a const fn, e.g.

const extern "C" fn foo2(val: u8) -> u8 { val + 1}

joshtriplett: so it is not allowing you to reference a function written in C and const evaluate it...ok. makes sense.

### "Lazy tait take two" rust#94081

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

no time to cover in depth, here is an example:

fn bar(b: bool) -> impl std::fmt::Debug {
    if b {
        return 42
    }
    let x: u32 = bar(false); // this errors on stable
    99
}

joshtriplett: do we want a design meeting?

nikomatsakis: I'll review in detail, prob not