---
# System prepended metadata

title: Triage meeting 2022-05-24
tags: [triage-meeting]

---

---
title: Triage meeting 2022-05-24
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-05-24

## Attendance

* Team members: Felix, Josh
* Others: Mark, Urgau, C. Kuhnke

## Meeting roles

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

## Other agenda items

- unsized locals: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Status.20of.20unsized.20locals

    * conversation on zulip topic indicates that people in general are okay with `unsized_fn_params`; its `unsized_locals` that present a bigger problem.
    * Its possible we could stabilize `unsized_fn_params` on its own, though the experience of using `unsized_fn_params` may be somewhat painful in the absence of `unsized_locals`
    * risk of unsoundness: LLVM alloca does not respect alignment. This is something we could workaround (e.g. by over-requesting and then adjusting) or fix in LLVM.
    * what about the risks commonly associated with `alloca`?
        * Rust provides stack probes (for targets that can support them; note Tier-1 ARM 64 still has [open issue re stack probes](https://github.com/rust-lang/rust/issues/77071)), so that addresses one vector typically associated with `alloca` in the context of C.
        * error associated with failure here is not as a nice as typical memory allocation failure
        * All these issues also apply to `let x = [0; 1024*1024*1024];`
    * (some targets emulate `alloca` via `malloc` -- is that actually routing through Rust's GlobalAllocator? Or is this some LLVM trickery that side-steps that?)
    * concern: will new users use this by accident when they didn't intend to? (But that could be addressed, e.g. with a lint, or with some language/type machinery like `Alloca<T: ?Sized>`, or some function intrinsic)

## Scheduled meetings

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

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

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

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

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

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

### "Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147

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

### "Async fns in traits" lang-team#150

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

### "dyn* trait" lang-team#158

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

### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160

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

### "Initiative: Ghost types and blocks" lang-team#161

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

### "Keyword generics" lang-team#162

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

### "Add const evaluatable `where const { <block> }`" lang-team#163

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



## PRs on the lang-team repo

None.




## RFCs waiting to be merged

None.




## Proposed FCPs

**Check your boxes!**
### "Refined trait implementations" rfcs#3245

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

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

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

### "Lang: Stabilize usage of rustc_nonnull_optimization_guaranteed on -1" rust#97122

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



## Active FCPs
### "Create a types team" rfcs#3254

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

### "tracking issue for `infer_static_outlives_requirements` (RFC 2093 spinoff)" rust#54185

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

### "Remove migrate borrowck mode" rust#95565

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

 * in last two days, description was edited to say that a stabilization post is prerequisite before merge; that still remains to be done.

### "Modify MIR building to drop repeat expressions with length zero" rust#95953

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

 * last week, scott resolved their concern
 * since then, there has been progress on implementation; all participants in the discussion seem happy with the current direction

### "Remove label/lifetime shadowing warnings" rust#96296

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

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

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

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

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

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

### "Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147

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

### "Async fns in traits" lang-team#150

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

### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160

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

### "Initiative: Ghost types and blocks" lang-team#161

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

### "Keyword generics" lang-team#162

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



## P-critical issues

None.




## Nominated RFCs, PRs and issues

None.



