---
title: Triage meeting 2021-03-02
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2021-03-02

## Attendance

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

## Meeting roles

* Action item scribe: simulacrum
* Note-taker: nikomatsakis (whoops...)

## Action item review

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

## Pending proposals
### "MCP: Deref Patterns" lang-team#77

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

* FCP is pending.
* Action item: Niko to open zulip stream etc once FCP is complete.

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

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

* [Pending FCP](https://github.com/rust-lang/rfcs/pull/3016#issuecomment-786868457)
* cramertj added a concern about the motivation
* Do we really want to guarantee UB detection?
* Answer: C++ does and it would look bad if we did less
* Request answers to these questions:
* What can you do or not do, as a user, as a result of this RFC?
* What can you *not do* as a result of the "authors cannot rely on this" part of this RFC?
* What can the *lang team* not do as a result of this RFC?
* e.g., what future paths do we close out by making this guarantee?
* Action item: Mark to post comment from meeting with those 3 questions
* Proposed action items to review / check boxes:
* pnkfelix
* josh
* cramertj
* scottmcm

### "Change visibility scoping rules for macro_rules macros" rfcs#3067

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

* rylev: Not since yesterday. We're at an inflection point. Do we want to introduce a special token like `$self` in order to more easily facilitate crate local recursive macros? If not, is this feature useful enough?
* Looked at common patterns folks use in macros and tried to apply new scoping rules
* Recursive macros (which call themselves) are difficult in the new scheme
* Macro definition needs to use a full known path to call itself
* This works across crates (even when renamed)
* `$crate` refers hygenically and there must be some path that other crates can use
* Crate-local macros may not have a canonical path that everybody else can use
* This applies to macros referencing all other kinds of items today.
* But it might be encountered more often because it's common for macros to have to recurse.
* Local helper macros that leverage shadowing at the other use case that we don't have a good pattern for, but it's less common
* This is a potential blocker for people switching, and thus for us switching how macros work (such as in an edition)
* Problematic case:
* People define a macro `foo!` that invokes itself like `foo!`
* If you `use some_module::foo` this macro, that's fine
* But if you do `some_module::foo!` it breaks
* The solution:
* `foo!` needs to refer to itself as `$crate::some_module::foo`
* which implies this path must be valid anywhere that `foo` may be used
* incompatible with the pattern of "private impl modules"
* An option, introduce `$self` which refers to the module where `foo` is defined
* Problem is that this breaks a lot of things in the ecosystem
* Could use a different syntax
* Not required, could always use `$crate::path::foo!`
* Which of these needs solving in order to introduce `pub macro_rules!`
* Which of these needs solving to change `macro_rules!` mean `pub(self) macro_rules!`
* Mark: We don't want to end up with a partial new system that doesn't solve these issues, and thus two systems in active use (and then potentially three systems once we finish macros 2.0).
* Emerging consensus: encourage ongoing design work to solve the above issues, then re-evaluate
* AI: Mark to write summary, work with lang member to propose FCP

### "RFC: Declarative macro metavariable expressions" rfcs#3086

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

* Output from Declarative macro repetition counts project
* There was a counter proposal for how the `count!` could be done efficiently, but some benchmarks found that it is still slower in many cases
* petrochenkov wanted a complete examination of the [possible syntactic space](https://github.com/rust-lang/rfcs/pull/3086#discussion_r583166840)
* Niko and Josh seem positive
* Mara: Looks good, makes complicated things less complicated
* Proposal:
* rfcbot fcp merge
* pnkfelix, cramertj, scottmcm to take action items to review
* AI: Josh to summarize and propose FCP merge (done)

Key bit:

The following metavariable expressions are available:

| Expression | Meaning |
|----------------------------|------------|
| `${count(ident)}` | The number of times `$ident` repeats in total. |
| `${count(ident, depth)}` | The number of times `$ident` repeats at up to `depth` nested repetition depths. |
| `${index()}` | The current index of the inner-most repetition. |
| `${index(depth)}` | The current index of the nested repetition at `depth` steps out. |
| `${length()}` | The length of the inner-most repetition. |
| `${length(depth)}` | The length of the nested repetition at `depth` steps out. |
| `${ignore(ident)}` | Binds `$ident` for repetition, but expands to nothing. |
| `$$` | Expands to a single `$`, for removing ambiguity in recursive macro definitions. |

## P-high issues on rust-lang/rust
### "repr(C\) is unsound on MSVC targets" rust#81996

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

* Updates
* Ongoing discussion about what changes should be made, and what changes are possible without breaking existing code.
* We stated that `repr(C)` should match the target C ABI. There's debate about whether that means "standard C" or "C including extensions in the target C compiler". We intended the latter, but that may be an issue.
* People use zero-length arrays today in both `repr(C)` and `repr(Rust)` for alignment:

#[repr(C)]
pub struct AlignedTo<Aligner, T> {
    _align: [Aligner; 0],
    pub value: T,
}

## Nominated PRs and issues on rust-lang/rust
### "[Edition vNext] Consider deprecating weird nesting of items" rust#65516

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

* Decision time:
* If there is nobody willing to champion this, Niko proposes we do nothing
* We can soft deprecate at any time if we wish
* AI Felix: summarize and fcp close

### "Stabilize `unsafe_op_in_unsafe_fn` lint" rust#79208

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

* FCP complete, will be merged.

### "resolve: allow super in module in block to refer to block items" rust#79309

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

* [petrochenkov posted a comment](https://github.com/rust-lang/rust/pull/79309#issuecomment-787479396), summary:
* privacy, paths, all work at module granularity
* supporting relative paths like `super::foo` but no absolute path like `a::b::c` is inconsistent
* crater run queued
* proposal: wait until crater is done
* Mark: Not a fan of complicating name resolution
* Feels like a "patchwork" solution
* Summary: we probably want a different solution here if we want to solve this at all
* AI: Josh to summarize and suggest discussion of alternative solutions on IRLO/Zulip

### "Allow qualified paths in struct construction (both expressions and patterns)" rust#80080

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

* [Discussed last week in some depth](https://github.com/rust-lang/lang-team/blob/master/minutes/2021-02-23.md#allow-qualified-paths-in-struct-construction-both-expressions-and-patterns-rust80080)
* It seems like we didn't note down a clear resolution, but there were some notes about what expectations were
* rylev: The action item was to try to get all uses of qualified path struct construction and pattern implemented. This is still WIP
* Next steps?

### "Update BARE_TRAIT_OBJECTS lint to deny in 2021 edition" rust#81244

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

* Defer, rylev + scottmcm will discuss lints today and put out a complete proposal
* Discussion happening [here](https://rust-lang.zulipchat.com/#narrow/stream/268952-edition-2021/topic/lint.20promotions)

### "Invalid `field is never read: ` lint warning" rust#81658

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

* Question is: what is considered a read?
* e.g., [does a destructor that frees memory count as a read](https://github.com/rust-lang/rust/issues/81658#issuecomment-771611093)?
* tmiasko points out that `_name` [may be appropriate there](https://github.com/rust-lang/rust/issues/81658#issuecomment-771661388)
* what about reads that occur in FFI?
* we can't possibly know the full set of those, right?
* [example playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=1d909fac79d42a5c028387642c48d7ca)

### "Deny WHERE_CLAUSE_OBJECT_SAFETY in Rust 2021" rust#81992

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

* Defer, rylev + scottmcm will discuss lints today and put out a complete proposal

### "Include adjustments to allow unsizing coercions for raw slice pointers in receiver position" rust#82190

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

* Complicated
* Proposal: assign to Niko to review and prepare a write-up

### "make unaligned_references future-incompat lint warn-by-default" rust#82525

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

Ralfjung [writes](https://github.com/rust-lang/rust/pull/82525):

> `std::ptr::addr_of!` has hit beta now and will hit stable in a month, so I propose we start fixing https://github.com/rust-lang/rust/issues/27060 for real: creating a reference to a field of a packed struct needs to eventually become a hard error; this PR makes it a warn-by-default future-incompat lint. (The lint already existed, this just raises its default level.) At the same time I removed the corresponding code from unsafety checking; really there's no reason an `unsafe` block should make any difference here.
>
> For references to packed fields outside `unsafe` blocks, this means `unaligned_refereces` replaces the previous `safe_packed_borrows` warning with a link to https://github.com/rust-lang/rust/issues/82523 (and no more talk about unsafe blocks making any difference). So behavior barely changes, the warning is just worded differently. For references to packed fields inside `unsafe` blocks, this PR shows a new future-incompat warning.

and [later on](https://github.com/rust-lang/rust/pull/82525#issuecomment-786487488):

> FWIW, I don't know what our policy is wrt how long we wait before shipping such things -- std::ptr::addr_of! is available on beta and nightly, but not yet on stable. So maybe we want to wait until it hits stable to ensure that people can properly fix this warning while remaining stable-compatible. But in case there need to be FCPs or so I wanted to already get the ball rolling here.

petrochenkov [writes](https://github.com/rust-lang/rust/pull/82525#issuecomment-787475069):

> I think it's useful to land this even if `std::ptr::addr_of` is not yet stable, since the most common correct fix is to copy the field rather than to take a raw reference to it.
The old lint is not good, I've personally seen people wrongly silencing the warning by adding an `unsafe` block instead of copying the value.

Ralf [writes](https://github.com/rust-lang/rust/pull/82525#issuecomment-787868780):

> My concern here is that people will silence the lint if they cannot fix the error because addr_of is not yet stable.

### "Document panicking cases for integer division and remainder" rust#82683

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

> This PR documents the cases when integer division and remainder operations panic. These operations panic in two cases: division by zero and overflow.
>
> It's surprising that these operations always panic on overflow, unlike most other arithmetic operations, which panic on overflow only when `debug_assertions` is enabled. The panic on overflow for the remainder is also surprising because a return value of `0` would be reasonable in this case. ("Overflow" occurs only for `MIN % -1`.) Since the panics on overflow are somewhat surprising, they should be documented.
>
> I guess it's worth asking: is panic on overflow (even when `debug_assertions` is disabled) the intended behavior? If not, what's the best way forward?

Niko wrote:

> [RFC 560](https://github.com/rust-lang/rfcs/blob/master/text/0560-integer-overflow.md) states:
>
> > The operations `/`, `%` for the arguments `INT_MIN` and `-1` will unconditionally panic. This is unconditional for legacy reasons.
>
> Exactly what legacy reasons I had in mind I'm not sure, that sentence kind of amuses me now. =) Nonetheless, I'd say it is clearly intentional, and I imagine that any change here would have to be done over an edition.