---
# System prepended metadata

title: Triage meeting 2021-02-16
tags: [triage-meeting]

---

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

# T-lang meeting agenda

* Meeting date: 2021-02-16

## Attendance

* Team members: nikomatsakis, joshtriplett, scottmcm, cramertj, pnkfelix
* Others: simulacrum, mara, connor horman

## Meeting roles

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

## Action item review

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

## Ad-hoc project updates

* Declarative macro repetition counts [draft RFC available](https://github.com/markbt/lang-team/blob/metavar_expr_rfc/projects/declarative-macro-repetition-counts/0000-draft-rfc.md) -- Niko
    * Action item: Niko to suggest posting on the RFC repository
    * Think the impl work is already done (draft)
* Inline assembly -- Josh
    * not quite ready for stabilization, but almost
    * https://github.com/rust-lang/rust/issues/72016#issuecomment-761616910
        * this comment has the "must haves" and "nice to haves" before it's time for stabilization
* Idiom lints -- Ryan, Niko, and Scott
    * [Preparing a document](https://hackmd.io/HETreGqPSRezlN109vgCnQ) with the following info about each lint
        * Tracking issue
        * Code example that triggers the lint
        * Code example that fixes it
        * Migration supported
        * Current state
        * Rationale in a nutshell
        * Concerns folks have raised
        * Proposed resolution
    * Confusion about the term:
        * FCW (as Niko intends it) is specific to soundness or bugs, and is not something we should tie to an edition
        * But people use the term FCW more broadly, e.g. for deprecation
        * What's a better name, broading

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

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

* [Charter](https://github.com/rust-lang/lang-team/pull/78) is pending
* Last time we discussed pursuing a variant that excludes `DerefPure`
* How do we feel about special-casing `Box` and/or std pointer types?
    * Note that borrow checker already special cases box
    * Also box already has an (unstable) pattern
    * Some precedent for special casing Rc, Arc:
        * CoerceUnsized, `self: Rc<T>`
        * other examples: `Vec<T>`
    * Alernatives:
        * Limit to Box -- this is basically the `box` pattern, though less good (because `box` has deref-move)
        * Some form of perma-unstable (until rfc'd) `DerefPure` trait or attribute or something used by std library types
            * has notable precedence
            * Other crates in the ecosystem have good reason to want this stabilized, but at the same time, there's value in having this for std types even if we can't have it for all types right away.
    * Question:
        * What about types that don't implement `DerefPure`?
            * They would be require an `_` pattern since they cannot be known to be exhaustive.
            * This would introduce 'random code running during pattern matching'.
    * Proposal:
        * Include:
            * Deref-based pattern matching for appropriate things in the standard library
                * Job of group is not necessarily to find complete set of appropriate types, just to propose a reasonable starter set
        * Exclude (for now):
            * Stability path for `DerefPure` or attribute
            * DerefMove
            * Types that aren't pure
    * Other concerns:
        * Figuring out how this interacts with binding modes
            * e.g. `match Rc::new(Some(5)) { box Some(x) => ... }`?
    * Action item: nikomatsakis to write up the proposal

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

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

* Why is this nominated? Revisit it next week.
* Action item: pnkfelix to request a summary of why this is nominated on thread. =)

### "try_trait_v2: A new design for the ? desugaring" rfcs#3058

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

* Action item: nikomatsakis to read it
* Action item: pnkfelix to read it
* Action item: cramertj to read it
* scottmcm will likely update the names based on libs feedback from Wednesday's meeting (2021-02-17).

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

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

* Considered "probably ready"
* Summary:
    * Add `pub` (including `pub(self)` etc) into all editions, applied to macro-rules
        * this makes them behave like regular items
    * Change the default behavior in edition N such that `macro_rules!` with no pub is a private item (like a regular item) equivalent to `pub(self) macro_rules!`
        * Requires migration
* Open question:
    * What is edition N?
    * How well does the migration work?
    * Do we have/need a workaround for the "recursive macro" pattern?
        * Niko's opinion is this doesn't necessarily have to be automatic
* Mark: Would be happy if we had a pattern that works
    * could even be some attribute to opt back in to the old behavior
* Action item: Niko to post summary of the above and encourage folks to come up with a good answer

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

* Summary of what's going on:
    * C compilers on Windows inconsistent rules for structs/unions/enums. 
        * e.g., msvc vs gnu, msvc vs clang
        * don't agree on all the details
        * josh: I believe gcc, clang can be made to agree with msvc using an attribute ("msvc struct")
    * Whose fault is this?
    * If the target triple is "msvc", shouldn't we just match msvc and the bug is then using gnu/clang ...? -Niko
* Is this compiler or lang?
* Josh: Lang needs to state what we intend the behavior of `repr(C)` to be.
        * Is `repr(C)` a defined layout that "applies everywhere"?
        * Or is it defined to be "compatible with the C compiler for the target"?
    * Josh believes the latter, but reference suggests the former
    * Scott -- there are stable stdlib APIs that describe `repr(C)` as being "repr(stable)"
        * e.g., https://doc.rust-lang.org/nightly/std/alloc/struct.Layout.html#method.extend for documentation describing `repr(C)` as being a stable layout, not punting to C compilers.
    * There is also the behavior defined by the *C standard* and then the behavior for things that go beyond the C standard (e.g., zero sized types)
        * I think the problem here is that the issue is for things where the C standard does *not* describe the behaviour.  For "normal" (no ZSTs, no packed types, etc) structs the distinction doesn't come up.
* Second issue: enum sizes
    * How much space we allocate for an enum that is declared `repr(C)` could vary by platform (C-like enum).
    * Some compilers error or overflow, or issue warnings.
* If we say "defined to match the default C ABI for the platform"...
    * For each target, a link to that default C ABI or perhaps the "reference compiler" we're trying to match
        * Reasonable question: who decides which one..?
    * Do we need a clang target?
* Action item: Josh to write up a comment stating that:
    * `repr(C)` is intended to match the default C ABI
    * we'd like to see documentation stating the ABI for each target triple
* Implication:
    * This is a bug (we're not matching the default)
    * And there is a feature request for a new repr to stray from the default
        * e.g., some kind of "naive" or "stable" repr that just lays out fields in order/size/alignment? that would be a good project proposal, we can discuss the best way to address the use cases.

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

* Expectation is that this won't happen for this edition, too many details to figure out
* But we could add potentially a warning at any point, would want to decide how to manage patterns that people *do* use which are useful
* Suggestion:
    * Someone can propose a specific lint that proposes various heuristics, and we can discuss

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

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

* Now in FCP. No action item.

### "Unsafe checking skips pointer dereferences in unused places" rust#80059

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

* No action item, just un-nominate.

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

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

* Fixes: Parsable associated enum constructor #79658 
* [Summary here](https://github.com/rust-lang/rust/pull/80080#issuecomment-760271825)
* Action item: scottmcm to fcp merge

### "Allow specifying alignment for functions" rust#81234

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

* Action item: Josh to fcp merge and check boxes for felix, scott, nikomatsakis

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

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

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

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

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

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


