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

# T-lang meeting agenda

* Meeting date: 2021-04-20

## Attendance

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

## Meeting roles

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

## Scheduled meetings
- 2021-04-21: "New ABI: "wasm"" [lang-team#90](https://github.com/rust-lang/lang-team/issues/90)
- [Notes available](https://hackmd.io/Xrgc68kDRtmNnG8g8CzA6Q)
- 2021-04-28: "Generators planning" [lang-team#92](https://github.com/rust-lang/lang-team/issues/92)

## Action item review

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

Two items from backlog bonanza:

- [ ] [2021-03-17]: Taylor to close RFC 2375 https://github.com/rust-lang/rfcs/pull/2375
- cramertj: Is close what we actually wanted?
- It seems like the RFC could be updated with edits from the thread.
- [Libs wants this](https://github.com/rust-lang/rfcs/pull/2375#issuecomment-820773071)
- Question though: would we want to lint on trait imports that are only used to access inherent methods?
- Warn by default: Keeps you compatible with the newest version
- Allow: Helps you retain compatibility with older versions of Rust
- The remaining problems seem small, the RFC seems "close enough", needs some work
- Consensus:
- We would like to see edits to the RFC made
- Leave a comment outlining the remaining answers we want addressed
- Specifically resolving the ambiguity when new methods are added to the trait in favor of "true inherent" methods written in the impl
- Request person who opened RFC to follow up or see if anybody else wants to pick up the torch; revisit next week.
- [ ] [2021-03-17]: Taylor to discuss with Scott and potentially propose fcp merge RFC 2316 https://github.com/rust-lang/rfcs/pull/2316
- [Discussed in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Omitting.20.60unsafe.60.20in.20trait.20impls.20RFC/near/232534935)
- Question is how this interacts with `const`, as it seems analogous
- cramertj: currently I think `const` is limited to the impl, but I would be surprised not to see that qualifier used on methods
- pnkfelix: not obvious that these are analogous to me (niko: nor I)

scott: I feel like it would be useful to be able to do the following in an analogous way

trait Foo {
    fn bar();
}

impl Foo for MyType {
    const fn bar() { } // allowed to specify *more*
}

* Do we block this rfc on discussing that?
* Reason to do so: it would create an inconsistency
- (scott) Any concern I'd have about it is in ordering, I think -- I'd like to have `impl const Default` first, to avoid a whole bunch of churn that we don't want, from people doing `impl Default for Foo { const fn default() -> Self { ... } }` and then needing to change to `impl const Default for Foo { ... }` shortly thereafter.

* const also has complexity because we want to be able to write impls that are conditionally const, and have `const` bounds
* [RFC 2632] (Calling methods on generic parameters of const fns) addresses this

* Taylor to FCP merge the `unsafe` RFC
* Followups later to handle `const` and discuss interaction with [RFC 2632]

[RFC 2632]: https://github.com/rust-lang/rfcs/pull/2632
[2021-03-17]: https://paper.dropbox.com/doc/Backlog-bonanza--BHGVAEjqOQKYdC3YswBSdq2YAg-2IcACiM0KX1up1thIeiWh

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

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

- [ ] [2021-04-06]: Niko to make sure we have a lang team design note on eagerly drop https://github.com/rust-lang/lang-team/issues/86

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

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

* Pitch: Handle explicit module paths more intuitively
* Leveraging editions (not 2021)
* General agreement that the current state is confusing
* Ability to use `#[path]` within an inline module
* Currently: path is based on "where this would be if it were a file"
* Proposed: path is based on the file system
* An alternative: Could have an option on the attribute, or introduce a new attribute that is always relative to the file system
* Consensus that we should do something here?
* Not really, many of us want more evidence that people are getting confused.
* path is relatively rare.
* The risk is relatively low: the path has to exist, so the chance you get this wrong in a way that sort of works...
* ...and the error message tells you specifically where it was looking for the file.
* ...and maybe if there are multiple files that potentially match under a different interpretation then that would be a good lint, suggesting that the file be renamed.
* Another approach:
* Look at the cases where folks are using path and find a way to make that easier.
* One common case is conditional compilation; maybe we could target that pattern more specifically.
* Meeting consensus:
* Not inclined to make this change without:
* more evidence that people are feeling confused
* evidence that there are patterns where you must use path without other alternatives

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

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

* In FCP, not much more to say
* side note: we might want to tweak this threshold for our team
* In general, I think requiring a supermajority, not just a majority, would be good ~ scott
* Filed https://github.com/rust-lang/rfcbot-rs/issues/293

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

* PR is up for review

## Nominated PRs and issues on rust-lang/reference
### "Document raw pointer <-> usize casts." reference#970

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

- [ ] [2021-04-06]: Niko to leave a summary comment, suggesting to close, https://github.com/rust-lang/reference/pull/970

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

* Proposal to stabilize: [Niko suggested we need a stabilization report](https://github.com/rust-lang/rust/issues/51999#issuecomment-818925156)
* Remove nominated label; assuming it works as designed, we want it
* Mark to leave comment saying that we are positive and would like a stabilization report

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

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

- [Discussed on 2021-03-30](https://github.com/rust-lang/lang-team/blob/master/minutes/2021-03-30.md#implement-new-lint-for-detecting-buggy-pointer-to-int-casts-rust81789) in depth
- Our consensus seemed to be lost, but we didn't have much follow-up on the issue
- [ ] [2021-03-30]: Taylor to write up a summary of the ptr cast discussion
- Pending crater run as well, which may inform the discussion

### "Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021" rust#83213

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

- Blocked on impl issues, no discussion required, removing nomination

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

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

* [FCP Report](https://github.com/rust-lang/rust/pull/83312#issuecomment-812880800) by petrochenkov:
* "I propose removing support for inner attributes on tuple, parentheses, array, struct and match expressions from the language."
* "Such attributes are not used in practice and pose challenges to token collection performed during parsing for various macros to work correctly"
* "The RFC, however says "Inner attributes can be placed at the top of blocks (and other structure incorporating a block) and apply to that block, which doesn't apply to any cases removed in this PR."
* Niko did an fcp merge

fn attrs() {
    (#![print_target_and_args(fifth)] 1, 2) + 5;
    ((#![print_target_and_args(fifth)] 1), 2) + 5;

    [#![print_target_and_args(sixth)] 1 , 2];
    [#![print_target_and_args(seventh)] true ; 5];


    match 0 {
        #![print_target_and_args(eighth)]
        _ => {}
    }

    MyStruct { #![print_target_and_args(ninth)] field: true };
}

* Reasons to keep inline attributes on blocks:

if foo {
    #![likely]
} else {

}

match foo {
    22 => {
        #![likely]
    }
    
    44 => {
    
    }
}

### "Stabilize extended_key_value_attributes" rust#83366

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

* Stabilize `#[foo = bar!(...)]`
* This is already possible via `macro_rules!` (!), due to expr interpolation
* Subsumes some other features, such as out of line documentation
* Note expansion order:
* The `bar!` is expanded after procedural macros (decorators), [similar to a macro expression that appears in the fn body](https://github.com/rust-lang/rust/pull/83366#issuecomment-822783680)
* Pending FCP

#[macro_attr1]
#[doc = mac!()] // "inert"
#[macro_attr2]
#[derive(MacroDerive1, MacroDerive2)]
struct S;

#[macro_attr1]
fn foo() {
    mac!();
}

// this works on stable for whatever reason
// and is commonly used "in std and elsewhere" (--simulacrum):
macro_rules! foo {
    ($x:expr) => {
        #[macro_attr1]
        #[doc = $x] // "inert"
        #[macro_attr2]
        #[derive(MacroDerive1, MacroDerive2)]
        struct S;
    }
}
foo!(mac!());

bar!();

* Question petrochenkov asked:
* [Do we want to enable arbitrary expressions in this position?](https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738)
* "This stabilizes using macro expansion in key-value attributes, like so:" -- jyn514
* But the PR appears to stabilize both

* What complications arise from accepting arbitrary expressions that do not arise from this?

#[foo = mac!(arbitrary_expr_here)]

* What complications arise from that, anyway?
* Only thing that the rustdoc team actually needs is `include_str` and friends
* What about stabilization -- is this arbitrary token trees?
* For example, can you put `try { 4 }` in here on stable?
* When does macro fragment parsing occur, presumably "after", at the time of macro invocation?
* ~~Niko~~ Felix to register concern about semantics of expressions here and summarize other questions

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

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

* In FCP, no discussion required

### "Revert "Rollup merge of #82296 - spastorino:pubrules, r=nikomatsakis"" rust#83713

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

* Niko would like to see this revert happen
* Current code doesn't work across crates and not worth the effort to fix it without an active design effort
* We can always re-land it if/when this effort restarts

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

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

* [PR #84147](https://github.com/rust-lang/rust/pull/84147) is already in FCP
* No discussion needed, but cc pnkfelix

----------
Items not reached in triage meeting:

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

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

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

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