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

# T-lang meeting agenda

* Meeting date: 2022-01-18

## Attendance

* Team members: Josh, pnkfelix
* Others: Mark, dbarsky, Mara

## Meeting roles

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

## Scheduled meetings
- "Structural equality" [lang-team#94](https://github.com/rust-lang/lang-team/issues/94)
- "Never allow unwinding from Drop impls" [lang-team#97](https://github.com/rust-lang/lang-team/issues/97)
- "Dyn upcasting, safety considerations" [lang-team#119](https://github.com/rust-lang/lang-team/issues/119)
- "Const eval overview" [lang-team#131](https://github.com/rust-lang/lang-team/issues/131)

## Announcements or custom items

(Meeting attendees, feel free to add items here!)

- Team roadmaps
- Companies are interested in contributing to Rust in high-impact ways; they want to see team roadmaps, and then make contributions that align with those roadmaps. So, compared to previous years, where a roadmap is read-only output describing plan based on team's own resources, it would be useful this year to have a road map that includes items that we *do not* have resources for (and explicitly tagged as such). expectation is that T-lang, T-libs, and T-compiler are the biggest likely targets/beneficiaries of this.
- May want to do a design meeting on this

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

### "Prototype Sync & Async Iterator Items (Minimal generators)" lang-team#121

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

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

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**

None.

## Active FCPs
### "Change location of where clause on GATs" rust#90076

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

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

* Last lang discussion [here](https://github.com/rust-lang/rust/issues/32976#issuecomment-716787769)
* current interface is to feed in a given size (e.g. `target_has_atomic="16"`). Do we need to be able to specify any other capabilities, e.g. pnkfelix sees mention of `target_has_atomic_load_store`
* but we can extend system with such extra functionality later. We don't need to let that block stabilization of this functionality.
* Q: are people going to actually want target_has_atomic_equal_alignment?
* the latter provides the guarantee that normal `i8` etc can be turned into `&AtomicI8` via the `from_mut` method.
* the `from_mut` method is currently unstable (nightly only)
* team consensus (among present members) is that just `target_has_atomic` is likely to match what people want.
* Q: shouldn't we be striving to support `cfg(accessible)` instead?
* `cfg(accessible)` is not necessarily the ideal API for this, and it will take much longer to stabilize
* Q: should we just pump up `target_has_atomic` to have the stronger semantics of `target_has_atomic_equal_alignment`?
* a big problem with pumping it up is that then you cannot support it for i64/u64 on Intel, which seems like a common case of interest.
* Q: a review of the tier 2 and maybe tier 3 platforms to check that we're not making a mistake
* what kind of mistake?
* e.g. a target that has only partial support for some parts of the API.
* in other words, we should try to check that we've identified a good common denominator between the API's supported by our set of targets
* the current system leverages compare-exchange as *the* common API. Everything else can be implemented in terms of compare-exchange.
* technically there is the *other* guarantee, to support `get_mut` method, that the data can be reinterpreted as a non-atomic. I.e. that `&mut AtomicI16` can be converted into a `&mut i16`.

### "Formally implement let chains" rust#88642

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

* Current belief: This seems to match behavior we want eventually
* no one sees breaking change here, though we would not be able to revert this without breaking change, so we still need to get buy-in
* there is concern that the MIR change should not be necessary to implement let-chains.
* mark will post feedback asking if this can be implemented without the changes to MIR building.

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

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

* impact was widespread, but few unexpected cases arose
* a leading underscore does not currently silence the lint, e.g. for `'_a'`.
* on public traits, lifetime is part of semver exposed surface area.
* so we might consider making the lint not flag that case
* and maybe is useful even if not mentioned in the trait declaration