---
title: Triage meeting 2021-05-25
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2021-05-25

## Attendance

* Team members: Niko, Josh, Taylor, Felix
* Others: simulacrum, Mara

## Meeting roles

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

## Scheduled meetings

- Done: "Generators planning" [lang-team#92](https://github.com/rust-lang/lang-team/issues/92)
- Done: "May updates" [lang-team#93](https://github.com/rust-lang/lang-team/issues/93)
- Tomorrow: "Rust language "guiding principles"" [lang-team#91](https://github.com/rust-lang/lang-team/issues/91)

## Action item review

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

## Pending lang team project proposals
### "MCP: Allowing the compiler to eagerly drop values" lang-team#86

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

- Pending action item: Niko to make sure we have a lang team design note on eagerly drop https://github.com/rust-lang/lang-team/issues/86
- Niko: started working on this. Will be done soon.
- No discussion needed.

## PRs on the lang-team repo

### Draft design notes

#### "Initial draft of copy ergonomics design note" lang-team#62

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

#### "Autoref/autoderef for operators" lang-team#63

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

#### "Auto trait design note" lang-team#69

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

#### "Add design notes for function-type `Default` implementation discussion" lang-team#71

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

#### "Add draft of variadic notes" lang-team#76

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

## Proposed FCPs

**Check your boxes!**

* Mark deleted several from here - the ones needing discussion are nominated, so will be below. Several have outstanding action items (mostly on Niko).

### "RFC: Add `target` configuration" rfcs#2991

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

* Blocked on consideration of more ergonomic target configuration as outlined [here](https://github.com/rust-lang/rfcs/pull/2991#discussion_r496090143)
* would be an alternative to permitting specification of explicit target, potentially seen as avoiding negative effects of overly-specific cfgs.

## Active FCPs

### "rustc: Allow safe #[target_feature] on wasm" rust#84988

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

* Trailing comment by Ralf: We should ask for clarification of the LLVM spec that this is not UB at the LLVM level. Could end up like other LLVM UB but not Rust UB bugs; Ralf thinks this is likely a reasonable tradeoff to make.

## P-critical issues
### "ICE when reifying function pointers to copy / copy_nonoverlapping using an if" rust#84297

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

* With some intrinsics, the way they are implemented, you can't get an actual function pointer
* That can cause breakage when something becomes an intrinsic where it used to be a wrapper
* We can fix this by always making things wrappers around intrinsics, but this impacts codegen etc
* Or we can make the compiler generate shims automatically

Example:

fn main() {
    let _unused = if true {
        core::ptr::copy::<i32>
    } else {
        core::ptr::copy_nonoverlapping::<i32>
    };
}

* Niko: I think we should just get rid of intrinsics as a concept and have lang items, and then use eddyb's trick to generate shims (direct calls are special indirect calls make a function pointer):

#[lang(likely)]
fn likely(...) {
    likely(...)
}

* There's a distinction that some functions (e.g., `copy`) make sense to invoke by pointer and some don't (e.g., `likely`).
* It doesn't make much sense to invoke `likely` by pointer, but then it doesn't hurt, right?
* Meeting summary:
* Lang would prefer that functions act like functions, and hence that the compiler can generate wrappers.
* Not our purview for whether this is fixed in the compiler or not.
* Question: Can all intrinsics be represented with a fn pointer -- notably not sure about SIMD?
* Mark to leave comment

## Nominated RFCs, PRs and issues
### "RFC: Overconstraining and omitting `unsafe` in impls of `unsafe` trait methods" rfcs#2316

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

* [matklad requested real world examples](https://github.com/rust-lang/rfcs/pull/2316#issuecomment-823507045)
* originally motivated by the future trait, but Pin made that unnecessary
* Primarily blocked on concerns about learnability
* (but also ~no checkboxes ticked)
* Proposal to shift to trusted/unsafe model, perhaps.
* Meaning of unsafe is very context dependent.
* But this RFC in some sense codifies the relationship more clearly
* It makes them *unsafe to call* and not *unsafe to implement*
* How does this combine with requiring an unsafe block inside the method?
* You can put an unsafe block inside the function but not have an unsafe on the impl
* That will compile
* But is this different from any other unsafe function?
* cramertj: I find it weird to have to write unsafe when there is not specific condition to write
* Niko: I'm fairly convinced this is not making the space worse, though I'm also convinced trusted could be useful
* scott: +1 to the idea of splitting up the keywords better here. Would be nice even just to make it easier to say out loud without the confusion. And with `try`/`?` and `async`/`await` it seems quite reasonable to have `unsafe`/`trusted` or similar for introduce and discharge. (Though `unsafe` isn't "carried" so it's not a perfect parallel.)

### "Calling methods on generic parameters of const fns" rfcs#2632

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

* Sort of not-clearly blocked. Really old pending FCP (since April 2019) - https://github.com/rust-lang/rfcs/issues/2632#issuecomment-481395097
* May make sense to close this RFC, in favor of a fresh one given all the changes since then, at least to start a fresh thread.

### "Tracking issue for RFC 2523, `#[cfg(version(..))]`" rust#64796

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

* Ongoing discussion of cfg(version(...)) stabilizing before cfg(accessible(...))
* https://github.com/rust-lang/rust/issues/64796#issuecomment-844173493
* One possibility: implementing a subset of cfg(accessible) that requires the accessibility item be in std/core/alloc
* cramertj: stdlib + rustc?
* josh: it'd be nice if we had feature detection for the language, but right now cfg(version) is the only thing we have for that
* we could use the names of feature gates but we dropped that from the earlier proposals due to opposition
* I'd still like to see it, but less concerned about blocking cfg(version) on that
* utility of cfg for language features is much lower because of the fact that we have to be able to parse the item body
* mara: you can avoid it with an identity macro though
* mara: people use versioning to check for const -- that's not possible with cfg(accessible), right?
* josh: that doesn't work now, is that an important use case?
* mara: a lot of scripts use versioning for that (I can make myself const if my callees are const)
* taylor: Feel like we should stabilize -- already immediately useful. Crates can't use cfg(version) until it's in their MSRV window as is.
* niko: +1, given that build.rs versioning is in active use, the utility of delaying seems low to me

### "Stabilize "RangeFrom" patterns" rust#83918

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

### "Uplift the invalid_atomic_ordering lint from clippy to rustc" rust#84039

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

### "Deny float matches" rust#84045

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

### "ICE when reifying function pointers to copy / copy_nonoverlapping using an if" rust#84297

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

### "Add `expr202x` macro pattern" rust#84364

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

### "Allow struct and enum to contain inner attrs" rust#84414

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

### "stabilize member constraints" rust#84701

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

* r+'d

### "implement `Default` for all arrays" rust#84838

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

### "add back support for inner attributes on non-block expressions?" rust#84879

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

### "rustc: Allow safe #[target_feature] on wasm" rust#84988

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

### "Re-add support for parsing (and pretty-printing) inner-attributes in match body" rust#85193

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

### "Stabilize RFC 2345: Allow panicking in constants" rust#85194

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

### "Ignore derived Clone and Debug implementations during dead code analysis" rust#85200

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

### "Check for union field accesses in THIR unsafeck" rust#85263

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