Triage meeting 2021-12-07

--- title: Triage meeting 2021-12-07 tags: triage-meeting --- # T-lang meeting agenda * Meeting date: 2021-12-07 ## Attendance * Team members: nikomatsakis, pnkfelix, scottmcm * Others: Mark, Lokathor ## Meeting roles * Action item scribe: Mark * Note-taker: pnkfelix ## Scheduled meetings - December 8 -- Unstable feature backlog bonanza - December 15 -- [lang-team#128](https://github.com/rust-lang/lang-team/issues/128) check-in -- lang team private - December 22 -- Either feature discussion from an initiative, or else backlog bonanza, to be decided on or by Dec 15 - Let's skip December 29 (mid-holiday for many) ## Announcements or custom items * Nothing here ## Action item review * [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A) ## Pending lang team project proposals ### "negative impls integrated into coherence" lang-team#96 **Link:** https://github.com/rust-lang/lang-team/issues/96 https://rust-lang.github.io/negative-impls-initiative/ created, need to close the issue, got a bit stuck trying to decide how to model it. --Niko Rough plan: * Use tracking issues on rust-lang/rust like all other features * Link to repo and include other metadata in a "machine extractable" structure * Label like T-lang-active-initiative ### "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 * needs to be accepted ### "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 * pnkfelix to be liaison, estebank as owner ### "Support platforms with size_t != uintptr_t" lang-team#125 **Link:** https://github.com/rust-lang/lang-team/issues/125 * Ongoing discussion that hasn't totally settled. Not ready for liaison yet. ### "Positional Associated Types" lang-team#126 **Link:** https://github.com/rust-lang/lang-team/issues/126 * Ongoing discussion that hasn't totally settled. Josh has volunteered as liaison but it's not obvious what the next process step is. * Mark: Maybe we should close the issues and suggest re-opening once the discussion reaches a point? The idea is that the proposal is not ready "as stated" for immediate decision. The issue exists to track a particular decision. * Josh: Where closing doesn't mean "we don't care" but "defer" * Mark: Maybe even more neutral, not making a determination yet. * Josh: We might still want to address the problem? * Niko: That makes sense to me, I do like that the issues don't hang around. * Josh: One question we could ask "what would it take to feel comfortable saying this problem sounds good to explore in an initiative even if we don't feel we are close to a right solution". * Lokathor: That should be an easy default-- admitting that there's a problem but "this solution doesn't seem right yet" is a fine way to be. * Felix: How do we track the existence of the problem? * Niko: I'm not convinced we need to track that. * Josh: Could also have an issue on the repo, but separate out "tracking issues". * Niko: I want to push back because there are an infinite number of problems that could be solved in the future. * Mark: We have a well structured process -- design notes -- for "I have some idea I'd like to write notes on". The bar for accepting those is low. * Niko: I agree with that. If you take the time to write up a note, I'm all for it, but an issue with discussion that accumulates over years is not adding a lot of value. * Josh: The concept of "there's a problem but not sure about the solution" fits one of these (lang-team#125) but not necessarily this one (lang-team#126). lang-team#125 clearly has a problem that we can't support some architectures or we have to break code. But lang-team#126 could just be "nothing happens". * Niko: The bar for me is that we need an active and eager liaison who will keep up and report things back, we're not doing that well. I do think we've not had successful status reports and things so we're clearly not quite keeping up with the work we have. * Josh: I could be a liaison. * Niko: I feel like you and I are both liaisons for many things but we've not managed to have updates on a regular basis, so I'm not sure if you really have time, but in any case I wouldn't be opposed to exploration. I have doubts but that's the point of exploration. ### "Heap allocations in constants" lang-team#129 **Link:** https://github.com/rust-lang/lang-team/issues/129 * Lokathor: this is interesting and people should look at it! * scottmcm: is const etc still active? * josh: can wg-const-eval kind of take ownership? is this *from* them? * nikomatsakis: we should ping oli and ralf. * lokathor: big problem is that `String` implies it's from the runtime global allocator; so doing `String::new` in a const would be tricky, as it couldn't be freed. Maybe we can ensure that it doesn't get dropped. Touches on Rust's general "allocator" problem; allocator wg seems kind of stalled due to lack of bandwidth. * scottmcm: can we make `String::leak` and `Vec::leak` work as a stepping stone? * lokathor: probably? it would produce a static slice or str value... maybe the compiler can figure that out and put it in the const data. * josh: another approach might be for a constant to own its heap allocation and not permit ownership to be moved out. * cramertj: seems like a bit of an open problem how to know which allocated regions of constant memory need to be "stored" for later use by references. Maybe we wind up doing some sort of pointer following at the end? But what about pointer-to-int casts? * lokathor: with ownership moving: currently the way a const works, when you say a const, it puts that bit pattern into that position, which is part of the problem. If you start duplicating a vec they'll all point to the same heap. * cramertj: that's fine if we require they're not drop; but I'm saying if you have a `String` coming out from `String::leak` you have to know that the buffer should be kept around, which is not totally trivial. You can write your own custom allocating containers, make references into the middle, etc * lokathor: the compiler handles that already; you can include bytes into a struct that is "overaligned". Move it into a thing, make a reference to it. Somehow it's tracking lifetimes? * cramertj: that's not just storing all data in constant memory? * lokathor: it works, anyway. * josh: design meeting as the right venue? * josh: didn't we have dec 22 as an open option? maybe this would be good? * niko: I'll ping oli, no objection. ## PRs on the lang-team repo None. ## RFCs waiting to be merged ### "Static async fn in traits" rfcs#3185 **Link:** https://github.com/rust-lang/rfcs/pull/3185 Merged! ## Proposed FCPs **Check your boxes!** ### "Change location of where clause on GATs" rust#90076 **Link:** https://github.com/rust-lang/rust/pull/90076 Blocked on a blocker! ### "Relax priv-in-pub lint on generic bounds and where clauses of trait impls." rust#90586 **Link:** https://github.com/rust-lang/rust/pull/90586 Blocked on nothing! Needs some check boxes! Has those check boxes now! ## Active FCPs ### "Stabilise `feature(const_generics_defaults)`" rust#90207 **Link:** https://github.com/rust-lang/rust/pull/90207 ### "negative impls integrated into coherence" lang-team#96 **Link:** https://github.com/rust-lang/lang-team/issues/96 ### "Positional Associated Types" lang-team#126 **Link:** https://github.com/rust-lang/lang-team/issues/126 ## P-critical issues None. ## Discussed RFCs, PRs, and issues ### "Tracking issue for RFC 2115: In-band lifetime bindings" rust#44524 **Link:** https://github.com/rust-lang/rust/issues/44524 * scottmcm: petrochenkov raised the question of "how we feel about this", should we just get rid of it? * scottmcm: Niko, I know you were fond of it in the past? * nikomatsakis: I would be ok removing it; I'm in between on it, but I'd be ok to take another stab in the future and see where we land. * cramertj: my understanding was that it was expected to be substantially more useful once we have implied bounds, but we never had those, which makes it less useful. * nikomatsakis: I don't remember the interaction? * cramertj: in particular in cases where you'd have a lifetime bound listed. There are times where you have to state a bunch of redundant facts. The ergonomics of that get much better with in-band lifetimes *plus* implicit bounds. If you don't have implicit bounds, you often can't use in-band lifetimes, because it's not as simple. * scottmcm: I thought you could always use them; you might not be able to use underscores, but for in-band I think it was ok. * nikomatsakis: I still feel like there are ergonomic challenges here, but I still have mixed feelings about this particular solution. * cramertj: I find myself much more bothered by having to repeat types in the impl that are already listed on the struct * nikomatsakis: yes, that plus where clauses (implied bounds) * scottmcm: I made a basic PR for one of the many compiler crates using in-band lifetimes. The place the update felt the least useful was adding a lifetime member to an impl block. * nikomatsakis: for the compiler I think I'd like to have tcx go on the module, but I don't want to open that can of worms right now. * pnkfelix: we might need to go bigger here, agreed. This feels like a "bandaid" to me and it might be better to reapproach with a broader lens. * scottmcm: We still have some lints open that woud be nice too: https://github.com/rust-lang/rust/issues/44752#issuecomment-986438348 * josh: to be sure, all the parts of this involving `'_` are implemented, so the only thing that's left is "you're allowed to use a lifetime without pre-declaring it". * nikomatsakis: at least that's the bit I'm talking about. * scottmcm: we spun out several subparts that we then stabilized. * josh: whatever did happen to the proposal of letting you have an implicit lifetime based on the name of the parameter? e.g., `'param_name` in the return type? * scottmcm: some people are nervous about it, lots of comments. * nikomatsakis: I'd want to see that alternative discussed when we revisit this question. * scottmcm: other proposals too, e.g. `'return` in the argument position. nobody is actively working on this, tracking issue has had no progress since Rust 2018. * nikomatsakis: I move to fcp and remove from compiler, but I'm curious about the lints? * scottmcm: see my comment above * nikomatsakis: I am still in favor of those lints, I know that some were controversial, but at *least* a lint that says "use `'_` if your return type is borrowed from an argument" would be good. * scottmcm: there are like 22 crates using this in the compiler * nikomatsakis: I think mark did that work. Sorry mark :) * scottmcm: Having the experience was really useful for making the conversation concrete. It had a surprising number of cases that could be `'_` now. * scottmcm -- action item to move to close and create issues for the lints ```rust fn foo(x: Ref<T>) -> &u32 // better written: fn foo(x: Ref<'_, T>) -> &u32 fn foo(x: Ref<T>); // <-- controversial to require fn foo(x: &Ref<T>); // <-- particularly controversial, as the "inner" lifetime in `&Ref<'_, T>` might be less important. ``` ### "Make specifying repr optional for fieldless enums" rust#88203 **Link:** https://github.com/rust-lang/rust/pull/88203 * pnkfelix: I have to leave very soon, but jswrenn expressed some concern about this. Potential "big picture" mistakes. * pnkfelix: I recommended to him that he propose a design meeting. https://github.com/rust-lang/rust/issues/60553#issuecomment-984290718 * pnkfelix: I remember jswrenn pointed me at a specific post that outlined a mental model that was complicated. * nikomatsakis: My memory is that we've been delaying because we don't understand the "larger story" these small-bore decisions fit into, so it'd be super useful to get that kind of feedback. * nikomatsakis: Design meeting would be good if we can get the other stakeholders involved. I feel like this whole discussion could be settled in 30min to an hour if we could get concentrated discussion. * josh: some of these issues are very complex to implement in the compiler. e.g. the issue about automatically implementing `AsRef` on enums #81642 -- feels like that needs a compiler team person to review. Is this a case of no team knows who has best responsibility? * mark: lack of review bandwidth leading to large PRs moving slwoly may be the problem here. * josh: pnkfelix, can you follow up with jswrenn? * pnkfelix: yes. *and then he suddenly disappears before we can give him more work* ### "Simple postfix macros" rfcs#2442 **Link:** https://github.com/rust-lang/rfcs/pull/2442 * Josh: * Previous meeting had a discussion that it'd be ok to experiment * New thing that came up: completely broken if you call it on a field you can't move out of, like `foo.bar.baz!()`. Doesn't participate in auto-ref, so you can't do "borrows vs ownership". * Did an attempt to write that in a way that "sort of kind of" autorefs. Doesn't actually do the right thing. Would appreciate some help in sorting this out. * That seems like a good area to do experimentation on nightly, but it'd be good to have a reasonable idea for how it *could* work. * scottmcm: * we have no way to forward a place under a new name. * i.e., you can't take something to put it in a variable -- if it's a place, matching it doesn't forward the "placeness" the same way, necessarily? * Feels like it wants the "auto-inference" that moving in closures does. * nikomatsakis: * I'd have to review the RFC, but in closure desugaring we rewrite `foo` to something like `*self.foo`, depending on capture mode inference. Definitely some kind of missing feature here where you can't "give a name" to a place as a variable and then use it in all the ways you originally could. You can borrow it, but then it's borrowed. * Josh: * scottmcm, could you help sort out a draft asynchronously via Zulip? * scottmcm: * I've placed some comments, something like an owning reference might work. * Josh: * but owning references seems like too much of a pre-req. * scottmcm: * if niko were going to pop up and say "we have those"... * nikomatsakis: * I'll have to review it. I imagined this was kind of the "obvious macro input" but I gather that it tries to do something smarter. ### "Allow using $:literal containing integer to index into a tuple" rust#91166 **Link:** https://github.com/rust-lang/rust/pull/91166 * lokathor: Most recent comments seem to indicate that there's some confusion about how to handle `.0.0`. Right now you can't say the field of a "tuple or tuple struct", since you can't accept `0` as an `:ident`. * niko: you could do it with tt, but that accepts too much? * lokathor: right. and right now if you have `.0.0` it becomes a `. float`, which isn't right * niko: Iirc when we added these we initially decided not to alter the lexer but then later fixed that? * simulacrum: seems like we should wait for petrochenkov and dtolnay to discuss this a bit more before "weighing in". ## Nominated RFCs, PRs, and issues ### "Relax priv-in-pub lint on generic bounds and where clauses of trait impls." rust#90586 **Link:** https://github.com/rust-lang/rust/pull/90586 ### "remove pref_align_of intrinsic" rust#90877 **Link:** https://github.com/rust-lang/rust/pull/90877 * josh/scott: we don't expose "preferred align of" apart from this intrinsic, but somebody relies on it, should we keep it around? * niko: is this somehow specific to LLVM? * scottmcm: I think that gcc has an attribute for this, which is why the c2rust package is using it. * josh: right, apparently the align-of builtin returns "preferred alignment" rather than ABI, which is why c2rust is translating it to use "preferred align of". * niko: why would we remove it? just because it's confusing? Ralf's main argument seemed to be "it's kind of confusing", right? * scottmcm: no plan to make it stable, not useful enough * niko: but we have a concrete use case, matching C behavior, that seems valid enough to me? * josh: I don't think we should be stabilizing it any time soon, but keeping it as an unstable intrinsic... * niko: why not stabilize it? * josh: We haven't fully decided what it means. The threshold for stable seems much higher. * scott: is this an LLVM intrinsic? * lokathor: it's part of LLVM's description of a target ([llvm docs](https://llvm.org/docs/LangRef.html#data-layout)) * scott: I thought we computed it in our layout code * josh: do we have a list of when the two differ? * e.g. on which targets, and with which types * simulacrum: I don't think there's a list, but there are tests that are being updated by this PR * u64 on x86 has pref=8, min=4 * https://github.com/rust-lang/rust/blob/0b6f079e4987ded15c13a15b734e7cfb8176839f/src/test/ui/intrinsics/intrinsic-alignment.rs * lokathor: probably only different when a type is bigger than the machine register size, in general * josh: how do these interact with `repr(align(...))` * josh: doesn't sound like we're going to resolve it but we should discuss it again * niko: I can leave a comment. ### "New declarative macros, functions and fields not being recognized" rust#91249 **Link:** https://github.com/rust-lang/rust/issues/91249 ### "Unreachable code is not borrow-checked" rust#91377 **Link:** https://github.com/rust-lang/rust/issues/91377 ### "Mark defaulted `PartialEq`/`PartialOrd` methods as const" rust#91439 **Link:** https://github.com/rust-lang/rust/pull/91439

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.