---
# System prepended metadata

title: Triage meeting 2021-03-09
tags: [triage-meeting]

---

---
title: Triage meeting 2021-03-09
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2021-03-09
* [Watch the recording](https://youtu.be/HTkAKULqQME)

## Attendance

* Team members: Josh, Niko, Felix, Taylor
* Others: Mark

## Meeting roles

* Action item scribe: Mark
* Note-taker: Josh

## Scheduled meetings
- Mar 17 "RFC backlog bonanza recap" [lang-team#84](https://github.com/rust-lang/lang-team/issues/84)
- Mar 24 "lang team reorg: shepherds 4.0, triage update" [lang-team#85](https://github.com/rust-lang/lang-team/issues/85)
- Mar 31 "How to dismantle an `&Atomic` bomb." [lang-team#82](https://github.com/rust-lang/lang-team/issues/82)

## Action item review

* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)

## Pending proposals
### "MCP: Deref Patterns" lang-team#77

**Link:** https://github.com/rust-lang/lang-team/issues/77

* Niko created [lang-team#88](https://github.com/rust-lang/lang-team/issues/88), but we need a liaison
* Niko: Scott and Josh were interested?
* Josh: Interested but do not have available bandwidth
* Action item: Niko to followup on Zulip about finding a deref patterns liaision

### "MCP: Allowing the compiler to eagerly drop values" lang-team#86

**Link:** https://github.com/rust-lang/lang-team/issues/86

* Discussed around async/await time
* Discussions turned up various cases that would benefit from it
* Discussions on Zulip showed that whichever way we went, some cases would want the opposite behavior
* Eager drop might require borrow checking to determine when a variable is no longer needed
    * Niko: There are alternatives to that; we could handle temporaries differently so that you never need the borrow checker to determine when to drop something
* Taylor: Would this be global or something else?
    * Josh: Discussions include global (and what that would take) and type-level opt-in (`EarlyDrop`)

## Nominated RFCs
### "add const-ub RFC" rfcs#3016

**Link:** https://github.com/rust-lang/rfcs/pull/3016

* Taylor expressed some concerns
    * Could we add a flag to the compiler that doesn't do these checks, if desired for performance?
        * RFC has clarified this to make it clear this is allowed
    * Should this be part of the language, or just a compiler improvement?
* Josh: We should state that these things aren't allowed in const evaluation, and we should state that the compiler should catch these things whenever possible, but I agree that we shouldn't make a hard requirement for such checks.
* Josh: We don't catch these things at runtime, because we can't efficiently do so; we're detecting more things at const-eval time than runtime.
* Niko: I found the parity argument (parity with runtime) persuasive. If we did some of the same optimizations on const-eval or other compile-time code, that would mean we couldn't catch these things.
* Felix: Would this mean that if we change optimization options in the future, people's code that worked before may stop working, and they'll complain? (Their code was using UB, but it'd still be breakage.)
* Taylor: Concerned about cases where someone relies on UB-detection in the style of a static assert; Ralf said this shouldn't be supported.
* Niko: The RFC should clarify how it applies, and that compilation errors are "allowed and encouraged but not required"
* Mark: Would there be cases where code was correct at const-eval time but if you remove `const` it becomes runtime-UB? For instance, alignment issues?
    * in particular, if you move a call from const context to runtime context, then the code must now worry about more UB, which feels dangerous.
* Josh: There's a parallel in overflow checking: the language-level statement is "This is important, we would always check it if it were free, because it isn't free we don't always do it, but we still consider it important"
* Niko: Would be great to have a way to run a program through something like valgrind to detect more UB.
* Action Items (individual): comment on the RFC, conveying key positions from the above

### "Change visibility scoping rules for macro_rules macros" rfcs#3067

**Link:** https://github.com/rust-lang/rfcs/pull/3067

* We decided not to do this through the edition.
* Pending postpone
* Action Item (Niko): Ping Ryan about continuing work and just not tying it to the edition

### "RFC: Declarative macro metavariable expressions" rfcs#3086

**Link:** https://github.com/rust-lang/rfcs/pull/3086

* Pending fcp merge, scottmcm left some comments
* Some small updates are pending
* Action Item (Josh): Ping libs team to take a look. (Not gated on libs, but libs ought to look at (for instance) naming.)
* Taylor: Is `index` a clear name for what it does? (Willing to go along if everyone else finds it clear.)
    * Consensus from others that `index` seems like the right name.
* Scott: Could these be built-in macros defined inside the compiler for performance?
    * Not all of these could be macros, even built-in macros; for instance, index.
* We should have a policy about when to add more of these.

## P-high issues on rust-lang/rust
### "repr(C) is unsound on MSVC targets" rust#81996

**Link:** https://github.com/rust-lang/rust/issues/81996

* Active discussion (and tensions high)
* Debating if it is possible to change repr(C) to match compilers without breaking existing code
    * Or is it sufficiently widely used with the current behavior that we need a `repr(really_c)` or equivalent.
    * Something that would match compiler's exactly
    * This would require changing zero-sized types; there is code that uses zero-sized types and which may have expectations
        * bindgen in particular generates code that uses ZST for alignment
        * most common request is:
            * on msvc
            * `repr(C)` ZSTs that have a specified alignment should not have size zero on MSVC

## Nominated PRs and issues on rust-lang/reference
No nominated items this time.



## Nominated PRs and issues on rust-lang/rust

### Never type

* simulacrum did some triaging of the crater report
* seems like "key question" for deciding on a path is:
  * Do we expect this to work without annotations?

```rust=
trait Bar {}
impl Bar for () {}
impl Bar for u32 {}

fn foo<R: Bar, F: Fn() -> R>(f: F) {}

fn main() {
    foo(|| panic!());
}
```

* currently, works because R will fallback to ()
* with the never type work currently implemented by Niko, needs explicit edit to show closure returns () (e.g., `foo(|| -> () { panic!(); });`)
* fallback here is sort of unfortunate, but libraries are not uncommonly written with impls for () in similar cases to this
    * unclear whether the impl is sort of "intentional" to capture ! or just for the () return case
    * unclear if we could support this fallback if desired, possibly feasible impl wise
* cases other than this one are much less prevalent, so depending on what behavior we want here we have some different options
* action item: mark to schedule meeting with Niko to pre-discuss a bit

### "[Edition vNext] Consider deprecating weird nesting of items" rust#65516

**Link:** https://github.com/rust-lang/rust/issues/65516

* Pending fcp close from pnkfelix
* Is there a place to put things for 2024?

### "Invalid `field is never read: ` lint warning" rust#81658

**Link:** https://github.com/rust-lang/rust/issues/81658

* Niko proposes an action item to someone to summarize concisely what the exact examples are and create a proposal :)
* I think the two things are:
    * a field that will only be read by some FFI code
    * a field that is useful to store to because it will get dropped later (`a.foo = bar`)
* Options:
    * encourage folks to use `_` names, or allow the lint (wontfix)
* cramertj: taking a borrow that becomes a raw pointer requires checking all containing things to get it really right
* allowing this would allow so much that the code is kind of useless on `repr(C)`
* ensure that diagnostic suggests putting `_`
* Action item:
    * scottmcm to write comment 

### "Deny WHERE_CLAUSE_OBJECT_SAFETY in Rust 2021" rust#81992

**Link:** https://github.com/rust-lang/rust/pull/81992

### "Include adjustments to allow unsizing coercions for raw slice pointers in receiver position" rust#82190

**Link:** https://github.com/rust-lang/rust/pull/82190

### "make unaligned_references future-incompat lint warn-by-default" rust#82525

**Link:** https://github.com/rust-lang/rust/pull/82525

### "Document panicking cases for integer division and remainder" rust#82683

**Link:** https://github.com/rust-lang/rust/pull/82683

### "Turn old edition lint (anonymous-parameters) into warn-by-default on 2015" rust#82918

**Link:** https://github.com/rust-lang/rust/pull/82918


