--- title: Triage meeting 2021-05-25 tags: triage-meeting --- # T-lang meeting agenda * Meeting date: 2021-05-25 ## Attendance * Team members: Niko, Josh, Taylor, Felix * Others: simulacrum, Mara ## Meeting roles * Action item scribe: simulacrum * Note-taker: nikomatsakis ## Scheduled meetings - Done: "Generators planning" [lang-team#92](https://github.com/rust-lang/lang-team/issues/92) - Done: "May updates" [lang-team#93](https://github.com/rust-lang/lang-team/issues/93) - Tomorrow: "Rust language "guiding principles"" [lang-team#91](https://github.com/rust-lang/lang-team/issues/91) ## Action item review * [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A) ## Pending lang team project proposals ### "MCP: Allowing the compiler to eagerly drop values" lang-team#86 **Link:** https://github.com/rust-lang/lang-team/issues/86 - Pending action item: Niko to make sure we have a lang team design note on eagerly drop https://github.com/rust-lang/lang-team/issues/86 - Niko: started working on this. Will be done soon. - No discussion needed. ## PRs on the lang-team repo ### Draft design notes #### "Initial draft of copy ergonomics design note" lang-team#62 **Link:** https://github.com/rust-lang/lang-team/pull/62 #### "Autoref/autoderef for operators" lang-team#63 **Link:** https://github.com/rust-lang/lang-team/pull/63 #### "Auto trait design note" lang-team#69 **Link:** https://github.com/rust-lang/lang-team/pull/69 #### "Add design notes for function-type `Default` implementation discussion" lang-team#71 **Link:** https://github.com/rust-lang/lang-team/pull/71 #### "Add draft of variadic notes" lang-team#76 **Link:** https://github.com/rust-lang/lang-team/pull/76 ## Proposed FCPs **Check your boxes!** * Mark deleted several from here - the ones needing discussion are nominated, so will be below. Several have outstanding action items (mostly on Niko). ### "RFC: Add `target` configuration" rfcs#2991 **Link:** https://github.com/rust-lang/rfcs/pull/2991 * Blocked on consideration of more ergonomic target configuration as outlined [here](https://github.com/rust-lang/rfcs/pull/2991#discussion_r496090143) * would be an alternative to permitting specification of explicit target, potentially seen as avoiding negative effects of overly-specific cfgs. ## Active FCPs ### "rustc: Allow safe #[target_feature] on wasm" rust#84988 **Link:** https://github.com/rust-lang/rust/pull/84988 * Trailing comment by Ralf: We should ask for clarification of the LLVM spec that this is not UB at the LLVM level. Could end up like other LLVM UB but not Rust UB bugs; Ralf thinks this is likely a reasonable tradeoff to make. ## P-critical issues ### "ICE when reifying function pointers to copy / copy_nonoverlapping using an if" rust#84297 **Link:** https://github.com/rust-lang/rust/issues/84297 * With some intrinsics, the way they are implemented, you can't get an actual function pointer * That can cause breakage when something becomes an intrinsic where it used to be a wrapper * We can fix this by always making things wrappers around intrinsics, but this impacts codegen etc * Or we can make the compiler generate shims automatically Example: ```rust= fn main() { let _unused = if true { core::ptr::copy::<i32> } else { core::ptr::copy_nonoverlapping::<i32> }; } ``` * Niko: I think we should just get rid of intrinsics as a concept and have lang items, and then use eddyb's trick to generate shims (direct calls are special indirect calls make a function pointer): ```rust= #[lang(likely)] fn likely(...) { likely(...) } ``` * There's a distinction that some functions (e.g., `copy`) make sense to invoke by pointer and some don't (e.g., `likely`). * It doesn't make much sense to invoke `likely` by pointer, but then it doesn't hurt, right? * Meeting summary: * Lang would prefer that functions act like functions, and hence that the compiler can generate wrappers. * Not our purview for whether this is fixed in the compiler or not. * Question: Can all intrinsics be represented with a fn pointer -- notably not sure about SIMD? * Mark to leave comment ## Nominated RFCs, PRs and issues ### "RFC: Overconstraining and omitting `unsafe` in impls of `unsafe` trait methods" rfcs#2316 **Link:** https://github.com/rust-lang/rfcs/pull/2316 * [matklad requested real world examples](https://github.com/rust-lang/rfcs/pull/2316#issuecomment-823507045) * originally motivated by the future trait, but Pin made that unnecessary * Primarily blocked on concerns about learnability * (but also ~no checkboxes ticked) * Proposal to shift to trusted/unsafe model, perhaps. * Meaning of unsafe is very context dependent. * But this RFC in some sense codifies the relationship more clearly * It makes them *unsafe to call* and not *unsafe to implement* * How does this combine with requiring an unsafe block inside the method? * You can put an unsafe block inside the function but not have an unsafe on the impl * That will compile * But is this different from any other unsafe function? * cramertj: I find it weird to have to write unsafe when there is not specific condition to write * Niko: I'm fairly convinced this is not making the space worse, though I'm also convinced trusted could be useful * scott: +1 to the idea of splitting up the keywords better here. Would be nice even just to make it easier to say out loud without the confusion. And with `try`/`?` and `async`/`await` it seems quite reasonable to have `unsafe`/`trusted` or similar for introduce and discharge. (Though `unsafe` isn't "carried" so it's not a perfect parallel.) ### "Calling methods on generic parameters of const fns" rfcs#2632 **Link:** https://github.com/rust-lang/rfcs/pull/2632 * Sort of not-clearly blocked. Really old pending FCP (since April 2019) - https://github.com/rust-lang/rfcs/issues/2632#issuecomment-481395097 * May make sense to close this RFC, in favor of a fresh one given all the changes since then, at least to start a fresh thread. ### "Tracking issue for RFC 2523, `#[cfg(version(..))]`" rust#64796 **Link:** https://github.com/rust-lang/rust/issues/64796 * Ongoing discussion of cfg(version(...)) stabilizing before cfg(accessible(...)) * https://github.com/rust-lang/rust/issues/64796#issuecomment-844173493 * One possibility: implementing a subset of cfg(accessible) that requires the accessibility item be in std/core/alloc * cramertj: stdlib + rustc? * josh: it'd be nice if we had feature detection for the language, but right now cfg(version) is the only thing we have for that * we could use the names of feature gates but we dropped that from the earlier proposals due to opposition * I'd still like to see it, but less concerned about blocking cfg(version) on that * utility of cfg for language features is much lower because of the fact that we have to be able to parse the item body * mara: you can avoid it with an identity macro though * mara: people use versioning to check for const -- that's not possible with cfg(accessible), right? * josh: that doesn't work now, is that an important use case? * mara: a lot of scripts use versioning for that (I can make myself const if my callees are const) * taylor: Feel like we should stabilize -- already immediately useful. Crates can't use cfg(version) until it's in their MSRV window as is. * niko: +1, given that build.rs versioning is in active use, the utility of delaying seems low to me ### "Stabilize "RangeFrom" patterns" rust#83918 **Link:** https://github.com/rust-lang/rust/pull/83918 ### "Uplift the invalid_atomic_ordering lint from clippy to rustc" rust#84039 **Link:** https://github.com/rust-lang/rust/pull/84039 ### "Deny float matches" rust#84045 **Link:** https://github.com/rust-lang/rust/pull/84045 ### "ICE when reifying function pointers to copy / copy_nonoverlapping using an if" rust#84297 **Link:** https://github.com/rust-lang/rust/issues/84297 ### "Add `expr202x` macro pattern" rust#84364 **Link:** https://github.com/rust-lang/rust/pull/84364 ### "Allow struct and enum to contain inner attrs" rust#84414 **Link:** https://github.com/rust-lang/rust/pull/84414 ### "stabilize member constraints" rust#84701 **Link:** https://github.com/rust-lang/rust/pull/84701 * r+'d ### "implement `Default` for all arrays" rust#84838 **Link:** https://github.com/rust-lang/rust/pull/84838 ### "add back support for inner attributes on non-block expressions?" rust#84879 **Link:** https://github.com/rust-lang/rust/issues/84879 ### "rustc: Allow safe #[target_feature] on wasm" rust#84988 **Link:** https://github.com/rust-lang/rust/pull/84988 ### "Re-add support for parsing (and pretty-printing) inner-attributes in match body" rust#85193 **Link:** https://github.com/rust-lang/rust/pull/85193 ### "Stabilize RFC 2345: Allow panicking in constants" rust#85194 **Link:** https://github.com/rust-lang/rust/issues/85194 ### "Ignore derived Clone and Debug implementations during dead code analysis" rust#85200 **Link:** https://github.com/rust-lang/rust/pull/85200 ### "Check for union field accesses in THIR unsafeck" rust#85263 **Link:** https://github.com/rust-lang/rust/pull/85263