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

# T-lang meeting agenda

* Meeting date: 2021-04-27
* [Watch the recording](https://youtu.be/StnbDE_2wO0)

## Attendance

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

## Meeting roles

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

## Scheduled meetings
-  "New ABI: "wasm"" [lang-team#90](https://github.com/rust-lang/lang-team/issues/90)
    - had the meeting!
    - notes to be pushed 
-  "Generators planning" [lang-team#92](https://github.com/rust-lang/lang-team/issues/92)
    - maybe no doc?

## 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 hopes to summarize

### "MCP: Change path attribute behavior of modules." lang-team#89

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

* FCP to close, no significant discussion afterwards.
* One comment, pointing out there might be reasons to use paths around platform independence (which we did touch on in meeting itself)

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

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

* looks like it can be merged
* who has permissions to merge?
* simulacrum: need to approve, then anyone from this team *should* have merge-capability
* pnkfelix takes action item to merge

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

* There is a PR and I (niko?) prepared an alternative fix

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

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

* Has a pending PR, under review

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

* [Stablization Report](https://github.com/rust-lang/rust/issues/51999#issuecomment-826346762)
    * I would prefer this to be accompanied by a stabilization PR, or at least in its own issue, shall we move it? -Niko
* lang team members should take action items to review this

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

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

* [cramertj summarized old conversation](https://github.com/rust-lang/rust/pull/81789#issuecomment-827756314)
* no responses yet
* nothing to do here at this time
* lang team members should take action items to review cramertj's comment
* general impression: no consensus among team about going forward; little confidence in PR as written, but generally positive about doing *something* to try to improve things here

### "parser: Remove support for inner attributes on non-block expressions" rust#83312

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

* In FCP now
* [Aaron1011 left a comment](https://github.com/rust-lang/rust/pull/83312#issuecomment-825113447) 
* (comment just says compiler has addressed some of the problems, but there is still value in removing them)
* cramertj: is this actually a breaking change, when you consider when these might fall under a cfg'ed section of code? (Or more generally, a part of the code that is dropped e.g. via macro expansion)

```rust=
macro_rules! foo {
    ($foo:expr) => { }
}

fn main() {
    foo!((#![foo] 22));
}
```

* notably, the above (with a `(#![foo] 22)` being passed into a macro that takes a `$foo:expr`) compiles today on stable and we are pretty sure it will stop compiling after this change.
* simulacrum: For what its worth, `rustfmt` "eats" the inner attribute in that context. (So it won't even be preserved via `rustfmt`'s transformation.)

4 unique legitimate regressions:
- `match port { #![allow(clippy::cast_ptr_alignment)] ... }`
- ``match self.color { //! The `format!()` [macro] lets us create a `String` with a pattern, ... }``
- `match *self { #![allow(unknown_lints,match_same_arms)] ... }`
- `match mdid { #![allow(clippy::unreadable_literal)] }`

* Based on above comment from petrochenkov (which we believe is referring to code snippets that compile today on stable rust), it sounds like we don't need to go through a macro to observe the breaking change here.

* This compiles on stable, with a warning that the `#[doc]` attribute is unused: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b6f83b33ead1fcc59d4ea4a48fd5fea1
```rust=
fn main() {
    let color = 4;
    match color {
        //! The `format!()` [macro] lets us create a `String` with a pattern, ...
        _ => (),
    }
}
```

* simulacrum: if this helps compiler performance on 99% of the code, and it doesn't have a meaningful interpretation today
* nikomatsakis/cramertj: it has a meaningful interpretation to me...
* simulacrum: well in any case, it seems like it might be worth it?
* nikomatsakis: Is the motivation here performance? I had thought maybe it was something else, i.e. that it wasn't correctly implemented today?
* nikomatsakis: I'm going to leave a concern noting that I am not clear on motivation
* scottmcm: how bad would it be to accept these but ignore them and emit a diagnostic saying that they have no meaning?
* various: why not just support them then?


Example: this works (lint is suppressed)

```rust=
fn main() {
    let x = Some(22);
    match x {
        #![allow(unused_variables)]
        Some(y) => { }
        None => { }
    }
}
```

### "Stabilize extended_key_value_attributes" rust#83366

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

* question about arbitrary expressions. PR stabilizes lexing arbitrary expressions in that position.
* nikomatsakis: why is that a concern for lang team? perhaps hygiene?
* nikomatsakis: generally feel like it should be okay to allow arbitrary expressions
* cramertj: should we worry that these macro invocations *look* like things that are expanded eagerly?
* cramertj: but `doc = ...` and `path = ...` "just work" via compiler-magic.
* nikomatsakis: right, they are not macros. (Though maybe they could become macros in the future.)
* cramertj: just concerned that someone might think they can use some macros here and think that they will be expanded eagerly.
* cramertj; Having this feature and *not* having eager expansion just feels funny to me.
* nikomatsakis: (do procedural macros accept that form?)
* cramertj: (yes. I think. E.g. parsing equals of attributes attached to fields)
* nikomatsakis: but what about the macro invocation itself?
* cramertj: oh I don't think those would work in a procedural macro (today).

```rust=
#[derive(StructOpt)]
struct Foo {
    #[data = include_str!(...)]
    field: u32
}
```

* but this example *would* work because string is only needed at runtime
    * what would not work is if the string is needed at *compile time*
* scottmcm: does this allow, say, `#[foo = +(3)]` since that could tokenize fine but isn't an expression?
    * Should it be `tt*` or actually `expr`?
    * niko's "theory": arbitrary tokens will lex, but not parse, but let's discuss it in thread
* nikomatsakis: seems like it parses the expression
* mara: the `StructOpt` example above does not actually work today

### "Stabilize `:pat_param` but leave `:pat2021` gated" rust#83386

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

* settled on "pat_param" as a name, but still deciding about whether to provide "pat2021"
* mara: point of keyword literals is to enable people to write expected keywords without waiting for an edition, not about adding it after the edition is available.
* joshtriplett: providing a pat2021 is motivated by wanting to allow future editions to make further changes to what `pat` means, and since we do not know what those changes are today, the only thing we can call it is `pat2021`
* mara: that sounds like an argument for not having `pat2021` at all
* joshtriplett: it is an argument if you want to write references to `pat2021` in 2015 or 2018 edition code.
* nikomatsakis: felix has often argued for always having a *way* to specify what you want, even if you rarely use it
* scottmcm: does it suffice to say "we give you a way, but only in the latest edition"?
* (debate followed)
* mara: Note that `$($_:pat_param)|+` works in all editions

* Agreed:
    * pat_param -- pat without `|`
    * pat -- pat without `|` <=2018, pat with `|` 2021+
* Question: 
    * do we have pat2021 that is 'pat with `|`' in all editions
* Reason to do so:
    * It is nice if older editions can access newer semantics, albeit with a more confusing way
* Reasons not to do so:
    * (a) they can acccess the newer semantics by doing `$($p:pat)|+` (or by upgrading to the newer edition)
        * But: this is significant more complex and they may well make a subtle mistake
            * But: macros do this today
        * But: why not adopt newer edition? probably because want support for old compiler
    * (b) newer editions have no use for this because it's just the same as `pat`
    * (c) if we add a new variant of pat, we can give it a meaningful name like `pat_param` at that time
    * (d) cruft, YAGNI
        * It would be a shame if we ended up with a big list of `pat2021`, `pat2027`, ...
* Precedent:
    * we tend to give years for 'old names that are deprecated but retained for backwards compat'

### "`#[repr(align(8))]` is not accepted for arrays" rust#83595

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

* putting `#[repr(align)]` on a field was accepted but did nothing
* now rejected
* scott thinks we agreed to this breakage before, so does mark
* action item: scott to leave comment

breakage discussion: https://github.com/rust-lang/rust/pull/80920#issuecomment-771901110

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

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

### "Deny float matches" rust#84045

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

### "exploration: ignoring arrays in method dispatch" rust#84133

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

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