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