---
title: Triage meeting 2021-05-04
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2021-05-04

## Attendance

* Team members: Niko, Josh, Scott, Taylor, Felix
* Others: simulacrum

## Meeting roles

* Action item scribe: simulacrum
* Note-taker: nikomatsakis

## Scheduled meetings

- No pending proposals this time.
- Planning meeting tomorrow

## Action item review

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

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

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

* No progress, Niko still planning to do a bit of a write-up. Probably won't happen for a week or two.

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

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

* Existing action item reminder: Felix to merge const-ub RFC https://github.com/rust-lang/rfcs/pull/3016

## P-high issues on rust-lang/rust

### "`fn() -> Out` is a valid type for unsized types `Out`, and it implements `FnOnce<(), Output = Out>`" rust#82633

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

* Niko: need to follow up here!
* Niko to schedule a time to chat about this and decide what to do

### "Closures are unsound: 'static closures with non-'static return types." rust#84366

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

* Niko: Have a PR to review with a fix.

### "Functions, closures, and HRTB-trait-objects can implement traits such that validity of associated types is never checked." rust#84533

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

* Niko have to decide how to assess prioritization of this overall.

### "HRTBs are unsound: HRTB on subtrait provides HTRB on supertrait with weaker implied bounds." rust#84591

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

* Niko have to decide how to assess prioritization of this overall.

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

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

### "Tracking issue for RFC 2345, "Allow panicking in constants"" rust#51999

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

Unchecked action items:

* 2021-04-27: ALL to review panic in consts stabilization https://github.com/rust-lang/rust/issues/51999
* 2021-04-27: Niko to move panic in consts stabilization to its own thread https://github.com/rust-lang/rust/issues/51999

* [Stabilization report](https://github.com/rust-lang/rust/issues/51999#issuecomment-826346762)
* Nobody has looked closely into it yet
* Action item: scottmcm to read into it and propose FCP if it seems appropriate

### "Stabilize "RangeFrom" patterns" rust#83918

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

* We requested this
* [Stabilization writeup](https://github.com/rust-lang/rust/pull/83918#issue-609576583)
* scottmcm proposed fcp merge
* Action item for folks: check your boxes

### "stabilize member constraints" rust#84701

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

* Niko: I plan to fcp merge here

fn foo<'a, 'b>(...) -> impl Trait<'a, 'b> { .. }

Complication, the solver will still have trouble with `impl Trait` in let binding position (but that's true regardless of what we do here):

trait Foo<'_> { }
impl Foo<'_> for &u32 { }

fn bar() {
  let x: impl Foo<'_> = &44; // let's call the region variable for `'_` `'1`
}

Clarification:

* the `R member of ['a, 'b]` constraint is an internal thing and not syntax users can write

// if you consider `impl Trait<'a, 'b>` as shorthand for
type FooReturn<'a, 'b> = ...; // <-- you want something you could type here

* Question (josh): Does this help us with `impl Trait` in traits (and thus `async fn` in traits)?
* Niko: Yes, that's why I'm doing it.
* [project board tracking the steps for `async fn` in traits](https://github.com/rust-lang/wg-traits/projects/4)
* note that the columns here represent 'milestones' and the contents are things that block those milestones

### "Uplift the invalid_atomic_ordering lint from clippy to rustc" rust#84039

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

* Context: we have requested that we get a chance to review uplift of clippy lints to rustc.
* Lint flags when you use the wrong ordering constant for particular atomic operations.
* Would be nice if this were a hard error! But in lieu of that, a lint is good.
* scottmcm: it'd be nice if there were some kind of attribute so that we could drive this lint more generically
* if this was some kind of language feature...
* Example: dedicated lint for Iterator::step_by to prevent passing 0
* mark: maybe if these functions were const fn...?
* niko: seems related to simd, formal verification preconditions
* Josh FCP'd, so check your boxes
* Josh: it'd be nice to have ability to break out a 'prefix' (with the panic checks etc) that can be inlined and potentially eliminated; similar to generic functions that are only generic so they can invoke `let x = x.into()` and similar.

### "Deny float matches" rust#84045

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

* Proposes to upgrade the warning on float literals in patterns to deny
* Motivation for the warning: NaN and the general question of what constants in matches mean
* This is in the future-compatibility: the future-incompat work in cargo has not made progress yet, but we were blocking on that
* Josh: I feel this could be deny, but I'd hesitate to make it a hard error in the future (which future-incompat implies?)
* Niko: I would like to settle the story around structural equality.
* Scott: I feel like this should stay a warning until we have a plan
* Niko: I generally agree, I do think that we'll wind up with a place where matching on constants just isn't equivalent to `==` at this point
* Josh: But even if we don't know our plan, do we know enough to know how floats should behave?
* Niko: the main question was what to do with structs; this is a leaf case, so we can ultimately define it either way, and right now the stable behavior is compatible with `==`
* Scott: What happens with range patterns?
* Answer: warning
* Josh: Wouldn't range patterns be (more often) the kind of code you want to write?
* Scott: Depends, the exactness of the boundary can still be an issue
* Josh: can we summarize the open questions on the issue, and in particular the question of range patterns and the ultimate path going forward?
* In particular, we don't need answers to *all* the questions but we may need the answers to some to move forward.
* The author of the PR felt that range patterns are equally risky, since the edge-points of the range are equally fuzzy.
* Niko: volunteers to write up a proposal and run it by const generics working group to double check his reasoning

[Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ff887d1032a4ff0ee7d093dfea0b5116):

// Test case: outputs b
fn main() {
    let x = std::f64::NAN;
    
    match x {
        std::f64::NAN => println!("a"),
        _ => println!("b"),
    }
}

// Generates a warning:
fn main() {
    let x = 1.5;
    
    match x {
        1.0 ..= 2.0 => println!("a"),
        _ => println!("b"),
    }
}

warning: floating-point types cannot be used in patterns
 --> src/main.rs:5:9
  |
5 |         1.0 ..= 2.0 => println!("a"),
  |         ^^^
  |
  = note: `#[warn(illegal_floating_point_literal_pattern)]` on by default
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #41620 <https://github.com/rust-lang/rust/issues/41620>

### "Allow unused variables with todo!" rust#79850

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

* Makes the use of the `todo!` macro suppress unused variable warnings
* Josh would not want this unless `todo!` itself generates some warning, Scott seconds
* Niko: I do feel there's a problem with rustc warning a lot as you prototype code, but this narrow take on the problem doesn't seem like enough to me. For example, dead-code lint is much more common for me.
* Scott: Yeah, I'll often `#![cfg_attr(test, allow(dead_code))]` or something because of this.
* Mark: what annoys me the most is that I have to scroll up to find the error because of walls of warnings.
* Josh: I tend to like that early stage, "code till all the warnings are gone"
* Niko: Remember `#[expect]`? whatever happened to that. This is what I usually want: a way to say "I know this is wrong but I want to know if I accidentally fix it"
* Niko to find expect and then FCP close with that suggestion
* [link](https://rust-lang.github.io/rfcs/2383-lint-reasons.html#expect-lint-attribute)

### "Implement new lint for detecting buggy pointer-to-int casts" rust#81789

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

* Have discussed numerous times, [latest summary](https://github.com/rust-lang/rust/pull/81789#issuecomment-827756314)
* Precise behavior of PR:
* The `invalid_ptr_to_int_cast` lint triggers if a pointer is cast to any integer type other than `usize` or `u64`, since doing so is often a bug.
* Question at hand:
* Pr aims to address "I accidentally wrote non-portable code by casting a pointer to u32. Example: ptr as u32 when I wanted to store pointers in an integer, possibly ptr as u64."
* Doesn't necessarily address the original issue, but potentially makes sense.
* Primary concern: portability?
* False warnings: 32-bit (or less) targets
* False allows: >64-bit targets
* Niko's assertion:
* This does't really solve the "casting function to integer" problem except in some cases (doesn't work for `usize::max()`)
* But seems useful regardless
* Scott: can we do the lint but remove the 'fixes', so that we can tune it as necessary?
* Niko: we do try to encourage portability by default (e.g., across OSs), this would mean that people targeting 32 bit platforms would have to allow it
* Mark: or they could write code more carefully, e.g., using `usize`
* Also, the crater run has the following false warning:

[INFO] [stdout] error: casting pointer to `isize`
[INFO] [stdout]    --> ndarray-sprrowlii/src/data_traits.rs:331:14
[INFO] [stdout]     |
[INFO] [stdout] 331 |             (ptr.as_ptr() as isize - other.as_ptr() as isize) / mem::size_of::<A>() as isize
[INFO] [stdout]     |              ^^^^^^^^^^^^^^^^^^^^^ help: to cast to `isize`, cast to `usize` first: `ptr.as_ptr() as usize as isize`
[INFO] [stdout]     |
[INFO] [stdout]     = help: pointers should only be cast to `usize` or `u64`

* Josh: reasonable if you are going to subtract it
* Scott: you've not lost information
* Josh: Proposed meeting consensus...
* remove the Fixes label
* do not warn for `isize` and `i64` either
* ...but cramertj is not here.
* Scott (at least) would like an add'l lint (not part of this PR) that would more aggressively lint on casting *function items* to any integral type, to target the original issue more squarely
* recommended path: cast the fn item to a `fn()` type first
* `i64::max as u64` <-- lint on this, suggesting `i64::max as fn(_)->_ as u64`.

### "Add `expr202x` macro pattern" rust#84364

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

> This makes it possible to use `inline_const` (#76001) and `let_chains`
(#53667) inside macros' `expr` patterns in a future edition by
bifurcating the `expr` nonterminal in a similar way to `pat2021` to
remove some backwards compatibility exceptions that disallow
`const`/`let` at the beginning of an `expr` match.

* [More detailed writeup](https://github.com/rust-lang/rust/pull/84364#issuecomment-823537483)
* TL;DR: The full set of expressions have diverged somewhat

### "Allow struct and enum to contain inner attrs" rust#84414

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

* Proposal by dtolnay to support

struct Foo {
    #![bar]
}

### "add back support for inner attributes on non-block expressions?" rust#84879

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