---
# System prepended metadata

title: Triage meeting 2021-07-27
tags: [triage-meeting]

---

---
title: Triage meeting 2021-07-27
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2021-07-27

## Attendance

* Team members: Josh, Felix
* Others: Mark, Lokathor

## Meeting roles

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

## Scheduled meetings
-  "Structural equality" [lang-team#94](https://github.com/rust-lang/lang-team/issues/94)
	- oli says they plan to have doc ready

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

### "negative impls integrated into coherence" lang-team#96

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

### "Trait Upcasting" lang-team#98

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

### "Discontinue meeting recordings" lang-team#100

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

### "Deprecate target_vendor " lang-team#102

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

### "Non exhaustive reachable patterns lint" lang-team#112

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

 * proposed 6 days ago
 * discussed on internals forum in past; just first time its been raised as issue on its own
 * proposal for add way to flag match expressions of non-exhaustive enums to still get linting when variant set changes.



## PRs on the lang-team repo
### "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

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

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



## RFCs waiting to be merged
### "RFC: Overconstraining and omitting `unsafe` in impls of `unsafe` trait methods" rfcs#2316

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

### "RFC: Supertrait item shadowing" rfcs#2845

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


## Proposed FCPs

**Check your boxes!**
### "RFC: Add `target` configuration" rfcs#2991

**Link:** https://github.com/rust-lang/rfcs/pull/2991
- Blocked waiting for author update.

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

**Link:** https://github.com/rust-lang/rust/issues/64796
- Blocked waiting for progress on cfg(accessible(...))


## Active FCPs
### "Associated functions that contain extern indicator or have `#[rustc_std_internal_symbol]` are reachable" rust#86492

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

### "Allow reifying intrinsics to `fn` pointers." rust#86699

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

### "negative impls integrated into coherence" lang-team#96

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

* Need a liaison for this; Niko will be an owner.
* Felix is willing, but we should see who on the team actively wants to be.

### "Trait Upcasting" lang-team#98

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

 * Has been seconded for long time.
 * Under new lang-team initiative process, need to identify who will be liason
 * Josh (who seconded proposal) is willing to be liaison but thinks Niko would be a better choice
 * Does niko want to be the liaison (was listed under "People Involved")

### "Discontinue meeting recordings" lang-team#100

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

 * Felix takes action item to update team documentation to reflect change in practice here (meetings are now by default not recorded, except for cases where we are specifically inviting someone for a recorded session).

### "Non exhaustive reachable patterns lint" lang-team#112

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



## P-critical issues

None.




## Nominated RFCs, PRs and issues
### "Tracking issue for RFC 2294, "if let guard"" rust#51114

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

 * A number of `if let` proposals lately
 * This one changes match arms so that their guard can carry an `if let` instead of an `if`
 * Felix takes action item to figure out what problem, if any, needs to be solved here, and then bring back to a subsequent meeting.

### "Allow limited transmuting between types involving type parameters" rust#86281

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

 * Previously discussed at prior meeting.
 * Waiting for summary comment from scottmcm.
 * Josh will drop I-nominated and leave note saying that scottmcm will write up summary.

### "Allow reifying intrinsics to `fn` pointers." rust#86699

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

 * Nominated for and entered FCP one week ago.
 * New [question](https://github.com/rust-lang/rust/pull/86699#issuecomment-887568940) from eddyb 3 hours ago
 * eddyb's Q: should the reification of `transmute` be special-cased, to either be feature-gated, or outright hard-errored?
 * josh: not sure why we would do that https://github.com/rust-lang/rust/pull/86699#issuecomment-887568940
 * felix: wasn't motivation to avoid insta-stabilization?
 * josh: sounds like motivation for outright feature-gate of the reification operation
 * simulacrum: we didn't feature-gate this because we wanted to make use of it immediately.
 * felix: ?
 * simulacrum: remember, copy/copy_nonoverlapping changed from wrapper functions to intrinsics. So for stability, when copy/copy_nonoverlapping become intrinsics, we need to support reifying those two intrinsics at a minimum.
 * felix: okay. Sounds like choices are either: 1. an allowlist for copy/copy_nonoverlapping, 2. a denylist for transmute, or 3. just don't feature-gate reification of any intrinsic at all.
 * lokathor:

```rust=
fn transmute_foo<T, U>(v: T) -> U {
   std::intrinsics::transmute(v) // ERR: v is generic...
}
```

 * josh: okay. so you cannot make generic wrapper around transmute due to that restriction (and thus cannot construct function pointers for arbitrary generic wrapper around transmute, since they cannot exist). But specific instantiations can become function pointers 
 * lokathor: right. e.g. `transmute::<i8,u8>` could be reified.
 * felix: proposal: we should allowlist just the copy/copy_nonoverlapping case, in order to make the insta-stable changes here as narrow as possible
 * josh: I just posted comment to that effect. Please double check that comment.

### "Support `#[track_caller]` on closures and generators" rust#87064

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

 * Certianly would be useful.
 * simulacrum had [asked](https://github.com/rust-lang/rust/pull/87064#issuecomment-885190936) for clarification of a couple points.
 * (some discussion of whether the `track_caller` annotation could work for functions via `Fn`/`FnOnce`/`FnMut`)
 * Mark will follow up to clarify the specific asks that Mark had put forawrd in their previous comment.

### "Make `#[derive(A, B, ...)]` cfg-eval its input only for `A, B, ...` and stabilize `feature(macro_attributes_in_derive_output)`" rust#87220

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

### "Stabilize built-in attribute macro `#[cfg_eval]`" rust#87221

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

### "Niches of `Cell` and others still not hidden" rust#87341

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

### "Make `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` warn by default" rust#87385

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

 * This is a lint to guide users to remove semi-colon from their macro-definitions, so that we can, in the future, not have to magically remove the semi-colon during expansion.
 * In order to narrow the scope of user-unactionable warnings, it only fires for expression-position macro uses in same-crate that run into the magic semi-colon deletion.
 * lokathor: would this fire for unit tests? Don't those get compiled into separate crate?
 * josh: sounds like it wouldn't fire there, given its focus on same crate triggering
 * (some discussion of motivation for the same-crate rule)
 * josh: could use cap-lints as basis for diagnostic
 * simulacrum: not ideal; don't want build cap-lints into meta-data for a crate
 * josh: unfortunate that we cannot determine instances of this without expanding macro first, since that would help us reduce instances
 * josh: seems next step is to FCP
 * simulacrum: do we need to FCP? This is just increasing a lint level
 * josh: indeed, seems like an easily reversed change. Under new policy, we could just move ahead based on meeting participants not objecting.
 * lokathor: ultimately just a warning, and we tell people not to deny warnings.