---
# System prepended metadata

title: Triage meeting 2021-05-11
tags: [triage-meeting]

---

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

# T-lang meeting agenda

* Meeting date: 2021-05-11

## Attendance

* Team members: nikomatsakis, Josh, cramertj, scottmcm
* Others: simulacrum, Mara

## Meeting roles

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

## Scheduled meetings
-  **Tomorrow:** "Generators planning" [lang-team#92](https://github.com/rust-lang/lang-team/issues/92)
    -  Need doc from Esteban!
-  **May 19:** "May updates" [lang-team#93](https://github.com/rust-lang/lang-team/issues/93)
    -  Action item: Niko to ping groups =)
-  **May 26:** "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 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

No nominated RFCs this time.

* https://github.com/rust-lang/rfcs/pull/2316
* not an rfc, but another FCP: https://github.com/rust-lang/rust/pull/84988 (allow safe `target_feature`)

## 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

* Esteban, Felix, and Niko spent time digging into this.
* We decided that we don't like Niko's branch and would prefer Esteban's general approach, but want to dig into what kind of problems arose.
* More work is needed.

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

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

* Niko to review the PR again.

### "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

### "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

### "A `Pin` unsoundness involving an `impl DerefMut for Pin<&dyn LocalTrait>`" rust#85099

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

* Another wacky Pin unsoundness; Niko doesn't understand well enough to summarize yet.
* Related and similar to [#68015](https://github.com/rust-lang/rust/issues/68015).

## 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

### "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
* Proposal:
    * Move this to an issue linked from the two tracking issues
    * Desire a clear summary of grammar changes required
        * what does expr match now that it did not before
        * assess what impact of this change might be
        * (crater run might be desired)
    * Edition migration that would be required
    * Is there actual ambiguity required here? Can we get an example of something that changes behavior?
* Action item: 
    * Felix to write the above, link issue, and remove nomination

### "Tracking issue for unsizing casts in const fns" rust#64992

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

* Ralf proposed stabilization and prepared a [stabilization report](https://github.com/rust-lang/rust/issues/64992#issuecomment-835387521)

Example:

```rust=
const fn test() {
    let _x = NonNull::<[i32; 0]>::dangling() as NonNull<[i32]>;
}
```

* Already stable in const item bodies
* Somebody to fcp merge -- on the [PR #85078](https://github.com/rust-lang/rust/pull/85078)

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

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

* Pending action item:
    * [ ] [2021-05-04]: Niko to track down expect RFC and point people at it https://github.com/rust-lang/rust/pull/79850
* No discussion this week, will remove nomination.

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

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

* Proposal last week:
    * don't claim to fix the original problem but still land this warning
* Question now:
    * How valuable is this lint on its own?
* cramertj: If you are casting a pointer to a `u32`, you'r probably trying to do something. What case are we actually trying to fix?
* Niko: it would be nice to have an actual bug
* scottmcm: we're generally eliminating cases... u64, usize, isize...
* josh: I've written a lot of low level bit manipulation code in Rust which required a lot of as casts. It's not hard for me to imagine accidentally stuffing a pointer instead of what I wanted. Ironically C would give me more cross-checks via compiler warnings here, since C generally warns about casting from a pointer to a "smaller than integer" size for the current platform.
* Niko: I remember having a bug where I was casting a fat pointer to a usize and somehow getting it cast back with a junk vtable, it was one of the worst bugs I ever had to track down. I could see this catching a mistake in that vein.
* Scott: Should we consider lints being aware of the current target? Fewer false warnings in exchange for "less portability".
* Mark: that can be a real pain -- e.g., on rust ci whenever something is specific to one configuration, it's very confusing.
    * Niko: +1, I'd rather we have some evidence that this is really important
* Felix: Consider a lint group?
    * Niko: I would like to have `#![allow(nonportable_32_bit)]`
* Josh: could start at allow and allow opt-in
* Scott: if there was an explicit method for casting, like `to_bits` and `from_bits`, wouldn't that be a better situation?
    * then we could disallow these `as` casts altogether 
    * josh: e.g, a `truncate` method that only took integer to small integer...?
* Mara: what about the fat pointer situation?
    * Josh: maybe disallow it on fat pointers, only permit it on thin pointers
    * Niko: yes you can say if you want the data pointer
* Niko: I'm in favor of introducing better alternatives to `as` and deprecating its usage
* Josh: I am doing a lot of 64-bit indexing, interconversion between usize and u64 is pretty annoying
    * it'd be nice to have a method that interconverts from usize to just u64 (or u32) depending on target - size *must* match for that one
    * scott: I'd rather we could just index by all the unsigned types
* Action items:
    * Josh, Mara to start thread on T-libs to discuss those methods
        * cc PR author, t-lang
    * Summary on issue (Mark)
        * we would like to have methods to point people to, and a simpler lint

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

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

* Turns out that some internal tool (rustfmt) relies on this, came up on internals
* Related: https://github.com/rust-lang/rust/pull/84414

```rust=
struct S {
    #![doc = ""]
}

enum E {
    #![doc = ""]
}

union U {
    #![doc = ""]
}
```

* Niko: Seems similar-ish to match patterns
* Inner attributes: how useful?
    * Top-level on a module
    * Some tricks with attributes in macros
    * Tagging bodies of match arms or if expressions
        * `match foo { 33 => { #![likely] ... } }` -- still allowed after this PR
    * Resolving ambiguity `(`
        * `#[likely] if foo { ...} else { }` // how do you even tag the else
        * `(#![foo] 3 + 2)` -- disallowed by ths PR
        * What about `if some_intrinsic::likely(foo) { ... } else { ... }`
            * there are a bunch of arguments here -- see https://github.com/rust-lang/rust/issues/26179
* Does anyone have an active argument in favor of keeping inner attributes in these positions?
    * Mark: It did break 4 crates https://github.com/rust-lang/rust/pull/83312#issuecomment-809599116
    * Niko: if we add support in structs, I'd expect it to work in matches, they look very similar
* Origin of the performance concern?
    * Procedural macros have to carry some baggage? (at least we think that's related)
        * ["Custom inner attributes in expressions are banned,"](https://github.com/rust-lang/rust/pull/83312#issuecomment-825113447)
* Josh: there was a procedural failure in that we failed to register a concern
    * so we have to choose between "make a decision really fast" and "discuss and decide at our leisure"
        * felix: might that not mean more crates appear?
            * Should we lint?
* Josh: what about a warning period?
    * [policy](https://rustc-dev-guide.rust-lang.org/bug-fix-procedure.html#is-it-ever-acceptable-to-go-directly-to-issuing-errors)
* Summary:
    * Niko: Ask about implications of reverting for match 

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

**Link:** https://github.com/rust-lang/rust/pull/84414
- Related to the above

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

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

From previous meeting:

* 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


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

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

* Josh FCP'd, so check your boxes


### "Deny float matches" rust#84045

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

Last meeting:

> Niko: volunteers to write up a proposal and run it by const generics working group to double check his reasoning


### "stabilize member constraints" rust#84701

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

* FCP