---
# System prepended metadata

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

---

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