--- title: Triage meeting 2022-06-21 tags: triage-meeting --- # T-lang meeting agenda * Meeting date: 2022-06-21 ## Attendance * Team members: Josh, Scott * Others: simulacrum ## Meeting roles * Action item scribe: simulacrum * Note-taker: simulacrum ## Announcements or custom items (Meeting attendees, feel free to add items here!) ## 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 ### "#[repr(Interoperable_2024)]" lang-team#165 **Link:** https://github.com/rust-lang/lang-team/issues/165 * Brief update: Seems to be really invested in a replacement/rewrite for C ABI * Likely to be left out of scope from Rust driving it * Josh will communicate to author ## PRs on the lang-team repo ### "Note design constraints on hypothetical `DynSized`" lang-team#166 **Link:** https://github.com/rust-lang/lang-team/pull/166 ## RFCs waiting to be merged None. ## Proposed FCPs **Check your boxes!** ### "Tracking issue for `IntoFuture`" rust#67644 - **Link:** https://github.com/rust-lang/rust/issues/67644 - [**Tracking Comment**](https://github.com/rust-lang/rust/issues/67644#issuecomment-1150164835): > Team member @yaahc has proposed to merge this. The next step is review by the rest of the tagged team members: > > * [ ] @Amanieu > * [x] @BurntSushi > * [ ] @cramertj > * [x] @dtolnay > * [x] @joshtriplett > * [ ] @m-ou-se > * [x] @nikomatsakis > * [x] @pnkfelix > * [x] @scottmcm > * [x] @yaahc > > No concerns currently listed. > > Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! > > See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me. - [**Initiating Comment**](https://github.com/rust-lang/rust/issues/67644#issuecomment-1150164808): > Fantastic report, thank you > > @rfcbot merge ### "Stabilize `let else`" rust#93628 - **Link:** https://github.com/rust-lang/rust/pull/93628 - [**Tracking Comment**](https://github.com/rust-lang/rust/pull/93628#issuecomment-1029383585): > Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: > > * [x] @cramertj > * [x] @joshtriplett > * [x] @nikomatsakis > * [x] @pnkfelix > * [ ] @scottmcm > > Concerns: > > * need-consistency-rvalue-temporary-rules-between-let-and-let-else (https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523) > * ~~not-while-rustfmt-breaks-on-it~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1032936704 > * ~~semicolon~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1059799661 > * ~~stabilization-report~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1033846359 > * ~~summarize-concerns~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1056785904 > > Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! > > See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me. - [**Initiating Comment**](https://github.com/rust-lang/rust/pull/93628#issuecomment-1029383577): > Shall we stabilize `let else` syntax? We've had many demonstrated uses, including extensively throughout `rust-lang/rust`, we've seen the value of it, and there aren't any known issues with it. > > @rfcbot merge ### "Never allow unwinding from Drop impls" lang-team#97 - **Link:** https://github.com/rust-lang/lang-team/issues/97 - [**Tracking Comment**](https://github.com/rust-lang/lang-team/issues/97#issuecomment-1152706219): > Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: > > * [ ] @cramertj > * [x] @joshtriplett > * [ ] @nikomatsakis > * [ ] @pnkfelix > * [ ] @scottmcm > > No concerns currently listed. > > Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! > > See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me. - [**Initiating Comment**](https://github.com/rust-lang/lang-team/issues/97#issuecomment-1152698760): > I had previously raised the question of adding documentation for what patterns people should use to allow handling errors when closing a resource. @Amanieu discovered that apparently we have that documentation already: https://rust-lang.github.io/api-guidelines/dependability.html#destructors-never-fail-c-dtor-fail > > Given that documentation, I'd like to gauge team consensus on the following narrow question: > > Do we want to switch the default over to `panic-in-drop=abort`? > > Note that this is *not* yet asking the question of whether we want to remove panic-in-drop=unwind, or add a stable option for it, or any other aspect of this change, only whether we want to switch the default. > > @rfcbot merge * Ongoing discussion, discussed last week in triage * Desire for an RFC was raised in that meeting -- seems like this is a pending action * Josh to leave a comment in the thread after the meeting canceling FCP in favor of an RFC, which lays out design, rejected alternatives, etc. ## Active FCPs ### "Refined trait implementations" rfcs#3245 **Link:** https://github.com/rust-lang/rfcs/pull/3245 ### "make const_err show up in future breakage reports" rust#97743 **Link:** https://github.com/rust-lang/rust/pull/97743 ### "allow unions with mutable references and tuples of allowed types" rust#97995 **Link:** https://github.com/rust-lang/rust/pull/97995 ### "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 * Process partially broke down here, with a lack of clear message for the proposers about whether this was approved for experimentation/Zulip/git-repo or not; * this particular proposal is now unblocked * but we should continue iterate on process & automation. ## P-critical issues None. ## Nominated RFCs, PRs and issues discussed this meeting ### "New rustc and Cargo options to allow path sanitisation by default" rfcs#3127 **Link:** https://github.com/rust-lang/rfcs/pull/3127 * Primary *possible* interaction is with `file!` * But the specific details of that behavior is T-libs-api, probably. * So inclination to drop lang nomination and indicate leaving decisions here elsewhere. * Josh to post a comment and un-nominate. ### "Tracking Issue for `#[instruction_set]` attribute (RFC 2867)" rust#74727 **Link:** https://github.com/rust-lang/rust/issues/74727 * Felix is formally liaison * May be good to poke for taking a look and fcp'ing * Josh to post a comment to that effect ### "Should `repr(transparent)` require *inhabited* 1-ZSTs?" rust#96921 **Link:** https://github.com/rust-lang/rust/issues/96921 * It's not clear whether we will want to break existing code (particularly since e.g. hyper is affected) * Suggestion to add a lint here linting against this pattern * Our story around compatibility (e.g., if you use an external crate's ZST in repr(transparent)) is not great today * We could roll such a lint in to that * Proposal: unnominate, maybe a lint ### "clarify how Rust atomics correspond to C++ atomics" rust#97516 **Link:** https://github.com/rust-lang/rust/pull/97516 * Josh potentially could investigate here * Some fairly detailed discussion on the PR * Current C++ model is also still not entirely solidified; e.g., relaxed and non-relaxed interactions are under some continued debate * We may eventually iterate to future versions of the C/C++ model or otherwise "iterate", closing the gaps here ### "allow unions with mutable references and tuples of allowed types" rust#97995 **Link:** https://github.com/rust-lang/rust/pull/97995 * No longer nominated; exiting FCP soon. ### "Document the effect of main's return value?" reference#1196 **Link:** https://github.com/rust-lang/reference/issues/1196 * Dropping nomination; this looks done from the lang side at least. Maybe could be closed, but leaving that open. ### "Specify what happens when casting fat pointers more specifically" reference#1206 **Link:** https://github.com/rust-lang/reference/pull/1206 ``` *const [u32] as *const [u8] // same length of slice, but completely different memory ``` Adding an example for the "length of slice" behavior would be a good idea. ### "Always create elided lifetime parameters for functions" rust#97720 **Link:** https://github.com/rust-lang/rust/pull/97720 * Not clear why this is necessary to land as immediately stable * No obvious objections to the feature itself, though