owned this note
owned this note
Published
Linked with GitHub
---
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