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

# T-lang meeting agenda

* Meeting date: 2021-02-23

## Attendance

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

## Meeting roles

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

## Action item review

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

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

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

* [proposed charter](https://github.com/rust-lang/lang-team/pull/78) is now scoped to stdlib types
* niko is ok to merge, who will serve as liaison? Scott will!
* Action item: nikomatsakis to fcp merge

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

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

[oli nominated](https://github.com/rust-lang/rfcs/pull/3016#issuecomment-780567912):

> Yes, the RFC has mostly undergone wording changes and has been unchanged for 3 months.
>
> I have implemented the prerequisite for this PR: MIR for `const fn` is duplicated so we get an unoptimized MIR for const eval purposes. This allows us to catch much more UB (as optimizations don't destroy it) during const evaluation than previous plans for unsafe code in Rust had in mind. With this implemented, the RFC requires no changes to the compiler or libraries, but once ratified will allow us to stabilize `const fn` in the standard library, even if said functions use unsafe code. Additionally merging this RFC will allow us to move forward with permitting things like `transmute` and `union` field access or other unsafe things in `const fn` that users write. Any such changes need to be signed off by the lang team, but we can't do these without first getting the general notion of "we permit unsafe code in user-written const fn" out the door, which this RFC does.

- nikomatsakis: seems like it's in steady state, some impl work has been done. FCP merge?
- Action items: read it! (nikomatsakis, pnkfelix, cramertj)

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

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

* Previously we asked for solution to recursive macro problem
* [Ryan posted some updates](https://github.com/rust-lang/rfcs/pull/3067#issuecomment-781302216)
* There was an [alternative proposal](https://github.com/rust-lang/rfcs/pull/3067#issuecomment-780755050) for how to manage
* Also a recent comment on Zulip points out that there is another problem

mod bar {
  macro_rules! foo {
    () => {
        foo!(...)
    }
  }
}

bar::foo!() // expands to `foo!` which is not visible in this scope

* Might indicate that we want to wait for "new" `macro` macros
* Still need a solution to the recursive case and define-macro-in-macro case
* `$self` could help, but we already discussed this and decided not to do it until macros 2.0 since we want `$<path>`, not just special cases.
* Also `$self` is a breaking change with substantial impact for existing `macro_rules`.
* `$self` could expand to the path that the top-level macro is called through.
* How much of this design work will be thrown away with path hygiene in macros 2.0? Probably all of it. In that world, macros can recurse easily.
* We want this feature. Macros 2.0 feels like the way to do it, but no one is actively working on that, whereas this feature is maybe more tractable.
* josh: opting-in via `pub` or `pub(self)` could make it easier to introduce the new feature without immediately having a solution to all these corner cases.

* macros
* macro-export (cross-crate): use `pub` <-- solve this problem with `pub` opt-in (have to name yourself via an absolute path that is publicly nameable, but that path exists)
* modulo re-exporting? what happens in the example below <-- Ryan to summarize
* crate-local (`#[macro_use]` a module) <-- sort-of solved (have to name yourself via `crate::` path)
* module-local <-- not so bad today, can't define macro after its use

// What happens here?

// crate A
pub mod foo {
  pub macro_rules! m { $crate::foo::m!() }
}

// crate B
pub use crate_a::foo::m;

// crate C
crate_b::m();

* Action item: Ryan to clarify re-exporting question.

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

* Josh posted our position that repr(C) matches C.
* Follow-up comments identified a few possible extensions
* warnings about zero-sized types and repr(C)
* possible use cases for repr(stable) (e.g., GPU)
* `PhantomData` and `PhantomPinned` people expect to be able to use without affecting layout, even in `repr(C)` types
* But `PhantomData` and `PhantomPinned` are not themselves `repr(C)`. `repr(Rust)` zero-sized and `align(1)` types in `repr(C)` structures should not affect the layout of the `repr(C)` type.
* `repr(Rust)` values in `repr(C)` types in general do not offer layout guarantees.
* Is `[u32; 4]` a `repr(C)` type? Is `[u32; 0]`?
* [Prior art](https://rust-lang.github.io/unsafe-code-guidelines/layout/structs-and-tuples.html#c-compatible-layout-repr-c), ought to reconcile with the conclusion of this
* Action item: Josh to investigate these questions further.

## Nominated PRs and issues on rust-lang/rust

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

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

* In FCP, no need to discuss.

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

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

* Changes behavior of `super` for items in functions
* Backwards incompatible
* petrochenkov is [negative](https://github.com/rust-lang/rust/pull/79309#issuecomment-734406868)
* Embedding modules inside functions is how doctests are evaluated. Without this fix, that transformation breaks `super::` usage in modules-in-doctests.
* Some overlap with "weird nesting of items" issue
* Current module's `self` should match inner module's `super`. Today this is consistent, this PR would change that.
* Current `self`-in-function points to the module, ideally it would point to the function?
* nikomatsakis: the motivation seems insufficient for a backwards-incompatible change. If doctests are the only "good use" of this, we should find another solution.

[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f9843140ff42157541e87d89b56fc1b9)

fn foo() -> u32 {
    const T: u32 = 22;
    
    self::T // error today
}

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

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

* [Scottmcm left a comment](https://github.com/rust-lang/rust/pull/80080#issuecomment-780063540)
* But Ryan is looking for lang input on one question.
* Allows e.g. constructing associated type struct through associated path:

impl Trait for MyType {
    type Assoc = Foo;
    fn bar() -> Self::Assoc {
        Self::Assoc { ... }
    }
}

* Josh: We'd like to allow this in both patterns and expressions
* Tuple structs are an issue because they're members of both type and value namespaces (separately). e.g. `struct Foo(u32)` is `type Foo(u32)` and `fn Foo(_: u32) -> Foo { ... }`. Annoyingly, this means that tuple structs would work in *patterns* but not construction. This asymmetry is annoying.

fn main() {
    let <WithStructStruct as Trait>::AssociatedType { a } = <WithStructStruct as Trait>::AssociatedType { a: 0 };
    let <WithTupleStruct as Trait>::AssociatedType(a) = <WithTupleStruct as Trait>::AssociatedType(0);
                                                     // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is the only thing that currently parses 
    let s = StructStruct { a : 0 };
    match s {
       <WithStructStruct as Trait>::AssociatedType { a } => a,
    };

    let s = TupleStruct(0);
    match s {
       <WithTupleStruct as Trait>::AssociatedType(a) => a,
    };
}

struct StructStruct {
    a: usize
}

struct TupleStruct(usize);

trait Trait {
    type AssociatedType;
}

struct WithStructStruct;

impl Trait for WithStructStruct {
    type AssociatedType = StructStruct;
}

struct WithTupleStruct;

impl Trait for WithTupleStruct {
    type AssociatedType = TupleStruct;
}

Niko's expectation, weird as it is

* In expression position:
* `<T0 as Trait>::Type { }` -- works no matter what sort of struct `Type` is but the fields may be named `0: ...`
* `<T0 as Trait>::Type(x)` -- invokes a fn named `Type`, not the associated type `Type`
* `foo.bar(baz)` -- invoke method `bar` and not call the function `foo.bar` (which is `(foo.bar)(baz)`)
* In patterns, unclear, maybe both work as above.

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

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

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

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

### "[Edition vNext] Consider deprecating weird nesting of items" rust#65516

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

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

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

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

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