---
# System prepended metadata

title: Triage meeting 2021-04-06
tags: [triage-meeting]

---

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

# T-lang meeting agenda

* Meeting date: 2021-04-06

## Attendance

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

## Meeting roles

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

## Scheduled meetings

Planning meeting tomorrow!

* Open issues for possible design meetings
    * there are a few open already
* Status updates for open projects etc

## 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
- Still waiting for summary, no action needed
- Inclined to close for now, take action item to make sure summary happens

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

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

- Change behavior of `#[path]` when you are inside a module `m` and `m` was declared with a `#[path]` attribute
- This would have to be tied to an edition, for compatibility reasons
- Too late for Rust 2021 -- deadline for decisions has passed, and it's not very urgent
- There are also a few options to consider, so don't want to rush into it
- Summary:
    - when using `#[path]` to specify a relative path for a module...
    - ...this result is affected by whether the current module is a `mod.rs` (or `lib.rs`) pattern...
    - versus a `foo.rs` file.
    - This MCP tries to tweak those rules.
- Scott: General idea of matching the `foo.rs` and `lib.rs/mod.rs` pattern seems reasonable
    - ...but so does having `path` work only like normal filesystem stuff, so who knows
- Defer detailed discussion for now till a future meeting or async.
- Question for today: push on 2021 Edition?
    - Felix: I fear the pattern that of not taking things for Rust 2021 but then not thinking about it again until just before next edition ships
    - Josh: Agree! I think we should still talk this over very soon, but not target Rust 2021.
- Meeting consensus
    - Do not target Rust 2021
    - But do continue discussing as a possible item for a future edition (and do not wait until right up until the deadline)

## Nominated RFCs
### "RFC: Supertrait item shadowing" rfcs#2845

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

- Unable to define a subtrait that inherits from a supertrait where both define the same method and to deal with it unambiguously
- Scott nominated: 1 check box away from FCP, what do we think?
- [Niko's comment](https://github.com/rust-lang/rfcs/pull/2845#issuecomment-724304466)
- Conclusion:
    - Niko and Felix to take action itms to review
    - May need a change to the RFC to reflect the request for an ambiguity error when invoked from inside the trait

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

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

- Been discussed in numerous previous meetings
- Ralf rewrote the RFC along the lines we suggested in previous meeting:
    - Concluded that, at least for now, we do not want to *mandate* UB detection but to leave it as implementation guidance
- Niko proposed fresh FCP
- Action items for folks to read and check their boxes

### "Raw Keywords" rfcs#3098

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

- Currently in FCP
- There have been some concerns raised on the thread
- We may want to pause the FCP. Some reasons:
    - this would allow someone to do an implementation PR and do a crater run to decide if we can use `k#` in every edition
    - to give due time for consideration from some recent comments (e.g., [1](https://github.com/rust-lang/rfcs/pull/3098#issuecomment-812953977) and [2](https://github.com/rust-lang/rfcs/pull/3098#discussion_r607317577))
- Major concern raised is basically
    - "would we wind up taking long enough to process the non-keyword part of any change that the keyword can just take the next edition"
    - but also "user experience is substantially worse"
- Eric raised the question of opting in with feature to using the new keyword
    - The argument against features we made before is that we don't want the combinatorial explosion of "dialects of Rust"
        - e.g., this project uses feature A but not feature B
- Felix feels the wording is misleading about the word `ident`
- Meeting consensus
    - Cancel the FCP
    - Note in the OP the following next steps:
        - Prioritize 3101 to secure the necessary edition space
        - Want the results of a crater run to deterine whether `k#foo` can be used across all editions
        - 

### "RFC: Reserved prefixes in the 2021 edition" rfcs#3101

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

- Reserves token space without defining semantics for anything in that token space
- Effect of current RFC is to forbid the following from being tokenized (in all cases, with no whitespace):
    - Reserves `ident#ident`
    - Reserves `ident"..."`
    - `ident'...'`
    - `ident#[0-9]+`
- It's weird right now that `a"xyz"` is three tokens but `b"xyz"` is one token, which this RFC would resolve.
- Some debate about the right time to issue an error:
    - Tokenization time?
    - Pass on through and make it usable in a macro?
        - If we allow passing on to macros, you can implement prototypes of new syntax
        - But you can implement macros that use this space in ways that could conflict with our reservation!
        - Also, if you are going to prototype, you might as well just use the actual keyword, not `k#foo`, right?
- RFC had proposed that we "don't worry" about breaking things that conflict, but it's better if we don't have to make that judgement call
- Cross edition compatibility:
    - Rust 2021 code can use older macros with whitespace; macro-rules macros cannot observe this
    - Only concern might be a procedural macro that was comparing spans to tell if two tokens were *truly* adjacent
- Tokenization error is forwards compatible with all future options
    - Also compatible with tokenizing differently from a single token, should we want that, or being handled in special ways
- Concerns with FCP merge?
    - Mark: General concern with speed, but no concrete concerns
    - Scott: major impact would be if people are using this in macros already (e.g., `f"foo"`)
- Josh to start an FCP
- Edition decision:
    - Can do in Rust 2021
    - If no impact, Rust 2018 and 2015 as well


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

* Previous consensus:
    * Want to prohibit function types that return unsized types
* estebank has opened [PR #83915](https://github.com/rust-lang/rust/pull/83915) to do that
    * some discussion about whether it's sufficient, as the PR doesn't cover `impl Trait`
* now up for compiler team 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

* Discussion centers around what language to use regarding provenance, and whether it is preserved
* Long Zulip thread without a concise summary
* The reference PR itself doesn't summarize advantages or disadvantages, simply states that provenance is lost
* Niko: This is wading into stacked borrows territory, why would we want to say this specific thing?
* Seems clear we won't be able to reach a conclusion in this meeting
* Need a good summary of tradeoffs etc, perhaps a design meeting
    * Need Ralf in that design meeting
* Better topic might be "let's plan the things to address and in what order" than to decide on this specific PR
    * Question is: is this question something we can do incrementally or only as part of a larger effort?
* Action item: 
    * Niko to summarize that we want to have the above discussion first and that we would prefer not to make this decision in a PR on the reference but rather an RFC etc

## Nominated PRs and issues on rust-lang/rust
### "Implement new lint for detecting buggy pointer-to-int casts" rust#81789

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

### "Use const generics for stdarch intrinsics" rust#83167

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

* Decision that needs making: do we want to **require** const generics for the intrinsics
* No updates, seems like we are unsure what the right next steps would be
* Have passed on that we would like feedback from actual users
* No further consideration required at this time, un-nominate
* Note that we are up against the Rust 2021 deadline, but then again we have to keep it for Rust 2018; nobody is too worried about having to delay until next edition.
* Historical note:
    * How did this get stabilize without langs being invoked? 
        * Was overlooked as a procedural "misstep", essentially.
* Ordinarily lang doesn't give a lot of scrutiny to rustc attributes, but in this case it becomes part of the public interface
* Proposed rule:
    * `rustc_` should not be used for things that affect the public API
* Action item: Mark to leave a summary comment and un-nominate (for lang)

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

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

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

### "Stabilize extended_key_value_attributes" rust#83366

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

### "Stabilize pat2015 but leave :pat2021 gated" rust#83386

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

- Niko wants people to look at this. But we did not discuss in meeting.

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

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

- This is actually about putting the attribute on a *field*, which AFAIK has never actually done anything.
- I think this is by design?  IIRC we talked about this one in some meeting when the PR went it to check it...

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

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


