Triage meeting 2022-06-14

--- title: Triage meeting 2022-06-14 tags: triage-meeting --- # T-lang meeting agenda * Meeting date: 2022-06-14 ## Attendance * Team members: nikomatsakis, Scott, Josh, pnkfelix * Others: simulacrum, David Barsky ## Meeting roles * Action item scribe: * Note-taker: nikomatsakis ## 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) - "Return Position impl Trait in dyn Trait ("RPITIDT")" [lang-team#144](https://github.com/rust-lang/lang-team/issues/144) ## Announcements or custom items (Meeting attendees, feel free to add items here!) ### Sealed traits? Josh: There is a [discussion on internals][16797] about having native sealed trait support. Initial proposal was `#[sealed]` but an alternative syntax proposal was `pub(impl in self)`, which seems kind of appealing. [16797]: https://internals.rust-lang.org/t/sealed-traits/16797 Scott: Most interesting part to me was a conversation about what sealed means from a backwards compatibility perspective. Can you remove sealed and have it be a non-breaking change? But it depends a lot on the details. Josh: Right, if it's allowed to effect coherence, and people can rely on it, it becomes a breaking change. So we'd have to decide whether we ever want this to affect coherence, or not. Personally I'd say "no", but that's a question we have to settle prior to stabilizing the initial feature. ## 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 * Lots of discussion on Zulip about what this means. * There needs to be some work to figure out exactly what is being proposed. Niko: Who would serve as liaison? Josh: me, possibly, if it is in line with what I want to support (interoperability on safe languages). I'm interested in a 3-4 page document talking how to specify some safe types over C ABI. They seem to be looking to specify C ABI in a broader way, but that doesn't seem like a Rust project. If they want to do, "slap C ABI on things to make it work" and a document that gives the details for the compiler, I'd like to do that (e.g., how to pass a slice between languages that understand a type-safe slice). Niko: So scope is beyond Rust having a stable ABI to include interoperability between Rust and other languages with similar concepts? Josh: Write, there are two things, one thing is that we can support the calling convention between versions of Rust. That would allow things like Rust dynamically linked libraries. That's separate from a much easier, simpler problem, like passing a string between Python and Rust. Why do you have to drop to C? Niko: Regarding stable ABI, the hard part seems to be not adding fields to hashmap or not inlining anything (or address that concern in some other way). Is that being discussed? Josh: I think you would say that the stable ABI doesn't permit you to know how big it is. Niko: You'd have to box it or something. Josh: Exactly. If the stable ABI meant that a lot of things have to be boxed etc. Josh: The main goal I had was to draw attention to the discussion. ## 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 Josh: Just proposed, needs review. Looks like a good topic. Who has bandwidth to sign off and approve? Niko: I'll see if I can do it. No promises! ## 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 - [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3245#issuecomment-1116370994): > Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members: > > * [x] @cramertj > * [ ] @joshtriplett > * [x] @nikomatsakis > * [x] @pnkfelix > * [ ] @scottmcm > > Concerns: > > * unresolved-question-for-next-edition (https://github.com/rust-lang/rfcs/pull/3245#issuecomment-1116371336) > > 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/rfcs/pull/3245#issuecomment-1116370985): > @rfcbot fcp merge > > I think we've got consensus on most of this here -- the main question is whether, in the next edition, `#[refine]` ought to be required in order to see the effects of the change or optional (perhaps with a lint). I'm going to separate propose a concern to move this to an unresolved question, I dont' see why it should block this RFC from going forward now. ### "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 Niko: I'm working with Ding Xiang Fei on this, it's progressing. No blockers. Have to refactor some things in the compiler -- we're moving the desugaring to the THIR phase, and some refactoring is needed. ### "make const_err show up in future breakage reports" rust#97743 - **Link:** https://github.com/rust-lang/rust/pull/97743 - [**Tracking Comment**](https://github.com/rust-lang/rust/pull/97743#issuecomment-1153228444): > 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 > * [x] @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/rust/pull/97743#issuecomment-1153228432): > @rfcbot merge ### "allow unions with mutable references and tuples of allowed types" rust#97995 - **Link:** https://github.com/rust-lang/rust/pull/97995 - [**Tracking Comment**](https://github.com/rust-lang/rust/pull/97995#issuecomment-1153592831): > 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!vbp0o-------------------------------------------------------------sd > > 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/97995#issuecomment-1153592808): > @rfcbot merge Scott: Why tuples? Why not `ManuallyDrop`? Josh: annoying, given that you can make a struct. Scott: You'd have to use `ManuallyDrop` for a struct too. Josh: Only if it's `Drop`. Niko: Why not make the struct copy? I don't quite get the concern about tuples. You mentioned arrays too? general discussion that arrays are a bit more complex because they have length, etc Scott: I just feel like a non-zero-length tuple is different from a zero-length. I don't have any opposite to tuples, just trying to figure out... what's the general rule for something that we would add here? Josh: Probably worth getting Ralf's comment on why arrays are considering tricky -- what is it that makes them? Niko: My general rule would be "if we permit structs, we should permit tuples", they're basically the same thing. Mark: We don't permit structs? Niko: We do if they are copy. Example that tuples & arrays are already allowed if `Copy`: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3007c7953e572994884a6241fc625d16 Mark: I think what's different is that `(&mut u32,)` will never have drop. Niko: Yeah, I think that copy is more a proxy for "doesn't do anything on drop" than desirable in and of itself. Scott: Is the rule in the future "if you have promised never to implement Drop", and when we get `negative-impls` we can do that more precisely. Scott: I guess when I see arrays, I think, why can't I do that? Mark: It does seem theoretically true `[&mut u32; N]` Niko: I feel like having a rule is good but we can treat some elements as a FIXME. Scott: I think we can figure out arrays -- i.e., if the length is known to be X, why not? Looking at the diff, my brain thinks "why not just add the case"? Niko: Yeah, but it seems like if Ralf didn't write the code, that's ok, we can leave it for later-- still, I think we can ignore the array length entirely, that's a good point (could always add zero-length arrays later). ```rust= ty::Array(element_ty, _len) => allowed_union_field(tcx, param_env, element_ty) ``` ### "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 Scott: What precisely is the FCP deciding here? Is it asking if we're adding a stable option? Switch the default? Josh: Specific proposal is not removing support for panic=unwind, nor is it about stabilization, the only proposal is "do we want to switch the default behavior to abort on panic in drop"? Scott: I think it's really hard to decide that without deciding other things. Niko: I feel we need an RFC. This feels like a notable language change. I would like to see a link to a document that explains the tradeoffs etc, tell you what has been considered, etc. Josh: This has been discussed in like 5 places, some of them are a lot noisier than ever, this seemed like a useful channel for having the discussion. I'm not sure if RFC is the correct documentation format, but something akin to a stabilization report. Niko: My concern is -- if this goes into effect, and people's behavior is affected, I don't want to say "we made the decision in an issue on the lang-tem repo". I want to point them at an RFC with considerations outlined and a discussion thread, so that the decision was made in an up-front way. Josh: can you post a comment about it, and/or a blocking concern? Scott: Reminds me a lot of the unwinding through extern C -- i.e., we can make whatever decision we want, but if we break a lot of people's code without an alternative, we're going to have a problem. Josh: It's true that we're not offering a "do it this way instead" option. Proposal long-term is just dropping this functionality, because we get a lot of the benefit by doing that. It would be hard to offer a stable "opt-out" if that stable opt-out might not continue existing forever, but also hard to put people on stable in a situation where they can't opt-out. Niko: Good example of why I'd like to see a doc -- e.g., you might think, oh, we can add a `#[may_unwind]` tag on a particular impl, but that would remove a key benefit to me, because I've found that in unsafe code it is too hard to reason about potential unwinding from destructors. ## Active FCPs ### "Tracking issue for RFC 2514, "Union initialization and Drop"" rust#55149 **Link:** https://github.com/rust-lang/rust/issues/55149 ### "make cenum_impl_drop_cast deny-by-default" rust#97652 **Link:** https://github.com/rust-lang/rust/pull/97652 ### "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 discussed this meeting (none yet, move things from the section below as they are discussed) ### "nested RPIT and HRTB: unclear semantics and future incompatibility" rust#96194 **Link:** https://github.com/rust-lang/rust/issues/96194 We can't figure out what this is nominated about. Mark to unnominate and post a comment requesting ### "Change enum->int casts to not go through MIR casts." rust#96862 **Link:** https://github.com/rust-lang/rust/pull/96862 Josh: I feel likwe we dsicussed this? [Ralf nominated it](https://github.com/rust-lang/rust/pull/96862#issuecomment-1123376867) and cited two things: > Are we okay with changing dtor behavior when casting C-like enums with Drop to int again? We warn against these casts for quite a while already (Tracking Issue for forbidding cast of C-like enum implementing Drop #73333) and have changed behavior in the past so I hope the answer is yes. Josh: we have an FCP of this in [97652](https://github.com/rust-lang/rust/pull/97652). This made is so that you can't cast an enum to its int repr if it is an enum with drop. Ralf said there "are we ok with changing this behavior" and we FCP'd that yes we are ok with it. I think we've settled this question. I'll post a quick comment. ### "Should `repr(transparent)` require *inhabited* 1-ZSTs?" rust#96921 **Link:** https://github.com/rust-lang/rust/issues/96921 This is currently accepted: ```rust enum Never {} #[repr(transparent)] struct Foo(u32, Never); ``` Seems obviously wrong, you shouldn't be able to get that out from an FFI. Niko: what's the harm? Josh: You can construct it with a safe API call. Niko: Can I not do that without `#[repr(transparent)]`? Felix: Is repr-transparent enabling passing something across the C ABI boundary you wouldn't be able to pass? Josh: repr-transparent permits you to build the type with what is *effectively* a transmute. The field given in the example is a u32. So you can write that what you got back is actually this. Makes sense for inhabited types, but not for never. Mark: but interacting with FFI is always unsafe? Josh: isnt' there some way to make a "trusted" FFI that's not safe to call? Niko: don't think so, but even if there is, that itself is unsafe-- but is there a valid use case for this? Niko: Ralf says this... > (This might even be a soundness issue, if there are macros that rely on repr(transparent) as indication of a UB-free transmute.) ...indeed, if that is a property that we intended to provide with repr(transparent), we are violating it. Niko: I thought it was limited to "the ABI interacts with it" Josh: if you can return a `u32` from some C function, and label it as returning `struct Foo(u32, Never)`, you are doing insta-UB and there is no way that can be correct. Niko: conceivably, like any uninhabited type, it might mean that the fn should never return. Josh: Interesting point, you can write an FFI function that returns never, which means no return. I would think that if the fn is not allowed to return that really should be "returns never"... Felix: it could maybe come from a macro expansion or something Josh: Maybe but ... in the absence of someone saying it Scott: I was thinking about safe transmute rules Scott: Seems like we can add a warning Niko: I agree, at minimum a warning, and perhaps an error. Felix: We could go straight to future compat warning to try and get feedback. Josh: We could also do a crater run. Niko: Good point, I'd be up for that. Felix: The hyper example isn't enough? Josh: I don't undersatnd it, the issue seems to be closed? ## Nominated RFCs, PRs and issues NOT discussed this meeting Niko: Is there any way we can identify time-sensitive things? Answer: P-critical, but we had the section above. ### "clarify how Rust atomics correspond to C++ atomics" rust#97516 **Link:** https://github.com/rust-lang/rust/pull/97516 ### "Always create elided lifetime parameters for functions" rust#97720 **Link:** https://github.com/rust-lang/rust/pull/97720 ### "allow unions with mutable references and tuples of allowed types" rust#97995 **Link:** https://github.com/rust-lang/rust/pull/97995 ### "Document the effect of main's return value?" reference#1196 **Link:** https://github.com/rust-lang/reference/issues/1196 ### "Specify what happens when casting fat pointers more specifically" reference#1206 **Link:** https://github.com/rust-lang/reference/pull/1206

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.