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

# T-lang meeting agenda

* Meeting date: 2022-02-15

## Attendance

* Team members: Josh, nikomatsakis, pnkfelix
* Others: Mark, Jane, Lokathor, Michael Goulet

## Meeting roles

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

## Scheduled meetings

* Feb 16th -- libs team sync / [lang-team#130](https://github.com/rust-lang/lang-team/issues/130)
* Mara/Josh to make doc
* Feb 23rd -- "Never type next steps" [lang-team#141](https://github.com/rust-lang/lang-team/issues/141)
* Mark/Niko to make doc

## Announcements or custom items

* [CTCFT on Feb 21](https://blog.rust-lang.org/inside-rust/2022/02/11/CTCFT-february.html)

* Compiler Ambitions for 2022 (living) draft doc: https://hackmd.io/Hrl30lX9Q0mbLIT4VkR_UA?view

* Community survey
* https://rust-lang.zulipchat.com/#narrow/stream/294169-t-community.2Frust-survey-2021 is a good (public) place to reach out
* preliminary RFC for a better way to interact with teams (more for next survey than the previous):
* https://github.com/rust-lang/surveys/pull/189

* rustbot note is available!

## Action item review

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

Niko working on a write-up for scoped thread closures, per Mara's request, but digging into one oddity he cannot explain. =)

[Draft](https://gist.github.com/nikomatsakis/ca87d4326de2baa58ef7a1273a8fc3bf)

## Pending lang team project proposals

* no new items to discuss this time

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

* needs a few more checkboxes! all concerns are addressed!

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

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

* blocked on some follow-up work -- Mark has action item to cancel FCP here.

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

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

* joshtriplett:
* Unusual case of a joint lang/libs rfcbot! the usual "you only need all but N" gets awkward for multiteam items.

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

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

* needs a few more checkboxes! all concerns are addressed! (DO IT NOW! --ed.)

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

### "Stabilize `#[cfg(panic = "...")]`" rust#93658

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

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

### "Tracking issue for #[cfg(target_has_atomic = ...)]" rust#32976

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

* simulacrum: actually tracks more than just `target_has_atomic`, also tracks "load store" and "equal alignment"
* we were pretty clear that we did not intend to cover "equal alignment"
* the PR that was filed to stabilize included `target_has_atomic_load_store` and it's not clear if we intended to do that
* joshtriplett: what is the difference?
* simulacrum:
* has-atomic == you have compare-exchange
* load-store == you have atomic load-store
* joshtriplett: why wouldn't we stabilize it?
* simulacrum: not very intuitive; my ideal world is that people probably don't want to be doing fine-grained dispatching on whether they have load-store etc
* in practice on most platforms you either have nothing or the whole thing
* joshtriplett: I assume there are platforms for which `target_has_atomic_load_store` are not available but exchange is?
* simulacrum: I think it's the other way around, some platforms have 'load store' but not 'exchange'
* Lokathor: on some embedded platforms, for some widths, you can call it an atomic store but you don't have compare-and-swap
* joshtriplett: I see, you don't have atomic at all on those platforms, but for single-threaded programs you have atomicity
* a reasonable question is "what do we expect target-has-atomic to mean", should it perhaps *be* load store? or ...?
* simulacrum: what I recall is "let's stabilize the thing that gives you the broad set of behavior and that's present most of the time" and you don't have to think about the details of precisely which operation you have available, and maybe if somebody asks for load-store, equal-alignment we can stabilize those down the line
* joshtriplett: one way to do this is "can we define that any platform which has atomic will always have atomic load-store"? in that case, it's not a problem to say that "has atomic" is covering that?
* simulacrum: it's true now
* joshtriplett: can we put that in the doc as an actual requirement for having `target_has_atomic`?
* simulacrum: I don't think it's really documented, which is the concern that Niko raised late in the process and it didn't really get registered, but I think it means "you have compare-exchange and load-store"
* joshtriplett: does anybody have objections to saying we should not stabilize load-store
* nikomatsakis: no objection, but I would like to see the meaning documented; what is the downside of having more options? more opportunity to get it wrong?
* simulacrum: yes. but also has-atomic-load-store feels closer to cfg-accessible, if you're going to be so fine-grained, why not use that?
* nikomatsakis: ok.
* joshtriplett: I can capture a summary comment that says what we'd like done here, sounds like a consensus would be, let's rollback a portion of the stabilization PR, and that we'd like to have atomic load-store documented for what it guarantees. Any objections to saying we'd like to document that it implies load-store?
* nikomatsakis: I don't see the harm in it, we can always use cfg-accessible or a new flag if in the future we decide you want a more narrow thing.
* joshtriplett: posted a comment. Mark, can you take the action item to see that get rolled back before it ships?
* simulacrum: yes
* joshtriplett: thank you, and thanks for staying on top of that! how did that get caught from a process standpoint?
* simulacrum: I looked at the PR; a process failure here was that there was not a clear stabilization report before we initiated FCP. I think in those cases we should immediately raise a concern that we don't know what we're stabilizing yet. People checked boxes but didn't know what they were ticking boxes on.
* nikomatsakis: it feels like it would be nice to FCP on PRs, so you can see the actual diff, but it's a lot of work to create the PR if it's not wanted
* joshtriplett: libs does stabilization on the tracking issues to avoid that and because of the wait-rebase etc. there's the question of 'how hard is the PR to rebase'. anyway.

### "Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust " rust#44930

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

* joshtriplett: tracks C-compatible varargs functions. Ability to define a `...` function in Rust that is callable from C. dlrobertson did a great amount of work implementing this for various architectures. The main reason it hasn't made progress towards stabilization yet is that it needs architecture specific support on every architecture that we ship. It also needs support for multiple ABIs.
* lang team question:
* can we (and should we) support a move to stabilize something that works on some targets but not on all targets?
* if so, what subset of targets need to be supported to be stabilized?
* Developer commented that it works on every Tier 1 target modulo bugs. That is worth considering as a basis for "is that enough".
* My understanding is we did something similar for i128/u128.
* pnkfelix: what happens when it "doesn't work"? UB, unspecified behavior, or compiler error?
* joshtriplett: yes I would expect it would fail to compile on a target that doesn't support it
* pnkfelix: I think we should spell that out. It's important that you get an error that is easily interpreted -- a human can say "ah this doesn't work on this target, it's a known issue".
* joshtriplett: even with a compiler error, you have to ask "is it ok that portable code using a stable language feature doesn't build on all targets", but I don't think there's any other way we could do this given the long tail of targets
* nikomatsakis: I propose...
* to be stabilized, must work on all Tier 1 targets
* and all other targets must produce a clear error message
* lokathor: if it doesn't work on all tier 1, then someone is not tier 1 *for real*
* joshtriplett: interesting point, is it ok that a tier 2 target can't compile it?
* (that's supposed to keep building)
* nikomatsakis: I think it's ok
* joshtriplett: should we open a separate policy issue for this?
* nikomatsakis: my proposal would be to open a PR against forge or lang-team repo and FCP *that*
* joshtriplett: for the rules on stabilizing a feature that doesn't work on all targets?
* nikomatsakis: yes
* joshtriplett: under what circumstances would be willing to accept where it gives you an obscure error?
* nikomatsakis: I think that could be decided on a case-by-case basis, but probably yes
* joshtriplett: my inclination is "must work on tier 1" and either " must give clear error on tier 2, should give a clear error on tier 3", or just "should" for both tier 2/3?
* pnkfelix: I'm ok with "should" for both.
* lokathor: in a case like `...` the compiler ought to be able to give a very clear error.
* joshtriplett: yes, but for some features, e.g., there was a long tail of architecture specific codegen bugs for i128.
* simulacrum: let's say we brought this one of these targets to tier 1. the lang design part of this is that we either knowingly opt out of some targets, or we can modify the design so that the bugs are all compiler bugs, not "oops, new syntax is needed on these targets".
* nikomatsakis: in other words, we should know that we *could* implement it, but haven't?
* simulacrum: to the extent you can, given the full universe of targets, shouldn't just think about 32/64 bit targets, but also think about more esoteric ones
* pnkfelix: another thing to consider is whether you will want a portability lint to indicate "hey, this might work on your target, but not this other one"...especially if we promote another target to tier 1 where it doesn't work, we would want some kind of lint?
* related to something about zero-sized arrays and struct definitions that doesn't *work* on msvc
* nikomatsakis: I feel like part of promoting a tier 2 to tier 1 would be implementing the feature
* pnkfelix: but sometimes you have targets like msvc that you can't ignore but have hazards that you can't fix
* just a thought that there may be opportunities to improve dev experience
* joshtriplett: ok, I am happy to take the action item to write a rough policy and FCP it against the lang-team repository
* should it live in the lang-team repository?
* nikomatsakis: I would have expected lang-team or [forge.rust-lang.org](https://forge.rust-lang.org/)
* probably forge
* joshtriplett: should we coordinate it with libs?
* nikomatsakis: would be nice
* nikomatsakis: there were instructions about "how to stabilize", ah, in rustc-dev-guide
* https://rustc-dev-guide.rust-lang.org/stabilization_guide.html

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

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

* joshtriplett: this is a compiler question for stabilization itself, but there is a lang team question of whether there is stable output. It started out as a debugging tool for macro expansion. That only requires human readability, but tools (cbindgen) started parsing this to accommodate macro-generated structs etc. Given that, it needs to be machine parsable Rust as well. Based on that, what requires, if any, do we want to place on pretty=expanded before stabilizing it?
* how uncomfortable would we be with this getting stabilized in its current form
* nikomatsakis: personally, I would not make guarantees, and would prefer that we eventually offer a stable detail
* joshtriplett: unless we go out of our way to make it NOT machine readable... saying we don't consider this stable would just make it not stabilizable? otherwise, we are committed to it?
* simulacrum: it includes unstable details, which will probably always be the case
* joshtriplett: I don't think anybody is expecting that the expansion of stable code is always stable code
* but I think it should be documented that expanding stable code may result in unstable constructs
* nikomatsakis: I feel like we could say it will always be syntactically valid rust, but because of hygiene and other things, it will never be compilable
* pnkfelix: there's also a hygiene version that includes hygiene information in comments. I worry that this format, if used for debugging, will mislead people.
* joshtriplett: debugging tools want to expand a whole file, but cbindgen -- afaik -- wants function signatures and data structures at the top level
* nikomatsakis: when we stabilized emitting MIR, we included a comment at the top saying "human readers only", we could include a comment here with caveats and things
* joshtriplett: what if we included a feature at the top whose sole purpose is to define that, if you are parsing this code, you're parsing unstable rust; e.g., `#![feature(macro_expanded_output)]`. If you're parsing code with a feature, you are accepting that you are maybe parsing unstable Rust. Accepting that you know how to parse it is effectively saying "I accept that the specifics of the output are not completely stable."
* nikomatsakis: and we could put the comment on the feature.
* joshtriplett: so we are stabilizing more than that there is "some output", we are also saying, it can be parsed, but is unstable.

MIR output:

// WARNING: This output format is intended for human consumers only
// and is subject to change without notice. Knock yourself out.
fn main() -> () {
    let mut _0: ();                      // return place in scope 0 at src/main.rs:4:11: 4:11

    bb0: {
        return;                          // scope 0 at src/main.rs:6:2: 6:2
    }
}

joshtriplett: yes, something a bit less caveated, but "does not take hygiene into account, may use unstable features, etc".

nikomatsakis: I'll write a comment

pnkfelix: I might do it

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

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

* nikomatsakis still working on write-up for this

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

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

joshtriplett: Set of intrinsics for the ADX feature of X86 architecture. Related to addition.

simulacrum: the intrinsics were already stabilized but there's not a cfg-target-feature for it.

joshtriplett: so this is just being able to use it in feature-available?

nikomatsakis: any reason *not* to do this?

joshtriplett: would potentially tie into features around carry flags, but the issues are with the intrinsics, not the feature name.

nikomatsakis: let's fcp it

### "Stabilize guaranteed compile time evaluation of unnamed constant items" rust#93838

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

joshtriplett: we support unnamed constants

`const _: X = { ... }`

but don't actually guarantee that it is evaluated at compilation time. There are workarounds for this. Are we willing to guarantee that the right-hand side gets evaluated at compilation time?

nikomatsakis: isn't that the whole *point* of this feature? why would you ... not want to do it?

joshtriplett: we don't actually guarantee evaluation of *named* constant items, so consistency?

simulacrum: we might want to soften the guarantee to like "will produce errors if there is a panic". I could imagine we would want to stop evaluation if there was something that we didn't want to run the build.

joshtriplett: you'd still have to execute it enough to know that it did or did not panic?

simulacrum: part of me wants to say that there are subtle things that maybe we do sometimes want to skip evaluation, but I don't have evidence.

joshtriplett: it sounds like you're saying, if -- in theory -- the compiler can do enough evaluation to surface errors, but can avoid doing work that it can prove won't produce an error, that would be acceptable. e.g. the compiler is allowed to optimize away things that won't execute.

simulacrum: it gets into what do we guarantee that const evaluation even *is*? most simple example would be like "you can't depend on us actually copying 20GB of memory that never gets used".

nikomatsakis: how would you know if we did it or didn't?

nikomatsakis: I don't see any harm in saying "compiler has the freedom to skip if it can see that it won't get an error", though I suspect we have that guarantee either way.

## Not discussed

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

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