---
# System prepended metadata

title: Triage meeting 2022-12-06
tags: [triage-meeting]

---

---
title: Triage meeting 2022-12-06
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-12-06

## Attendance

* Team members: Josh, Felix, Niko, Tyler
* Others: Mark, y86-dev

## Meeting roles

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

## Scheduled meetings

- Tomorrow: "Contracts and Automated Reasoning for Rust" [lang-team#181](https://github.com/rust-lang/lang-team/issues/181) 

## Announcements or custom items

### Comment thread / technical discussion

pnkfelix: Compiler team has a bot that links threads to Zulip. The meeting issue for lang-team#181 had a fair bit of technical discussion. Should we consider doing something similar?

joshtriplett: I thought we did link threads to Zulip

nikomatsakis: I think not for meeting proposals

joshtriplett: as a general rule, Zulip seems preferable, but there's a certain overhead of weirdness to "don't talk here". Makes some sense for things where large quantities of discussion are expected. For meeting proposals, mean/median case has been approximately no discussion, in which case GH seems fine.

pnkfelix: I'd prefer to think about constraints that are appropriate. For RFCs, it's a feature that we invite communication from arbitrary people, so we deliberately make RFC comment thread accessible. 

joshtriplett: True, and we've also observed it sometimes is low value, but I appreciate point you're making. Zulip trade offs convenience of platform/reading/interacting and is less accessible to a broader audience.

pnkfelix: I guess point is which space is appropriate to a lang team meeting proposal.

tmandry: just for consistency, let's argue for that?

joshtriplett: sure, but can automated message have a clear exception for "scheduling discussions" (i.e., what time is the meeting). Let's make sure people feel those messages can still go to GH, not just to Zulip.

nikomatsakis: we should encourage that GH thread to be a summary of key details, so e.g. link to hackmd and scheduling data.
 
Action Item: Felix will look into enabling the bot to do the posting 

## Action item review

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

## Pending lang team project proposals

None.

## PRs on the lang-team repo

None.




## RFCs waiting to be merged
### "Support upcasting of `dyn Trait` values" rfcs#3324

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

nikomatsakis: oh bother. I said I would do this last week. Will try to do it this week.

Action item: Niko to do it.

## Proposed FCPs

**Check your boxes!**
### "Create an Operational Semantics Team" rfcs#3346

- **Link:** https://github.com/rust-lang/rfcs/pull/3346
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3346#issuecomment-1337560322): 
	> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
	> 
	> * [x] @compiler-errors
	> * [x] @cramertj
	> * [x] @jackh726
	> * [ ] @joshtriplett
	> * [x] @lcnr
	> * [x] @nikomatsakis
	> * [x] @oli-obk
	> * [ ] @pnkfelix
	> * [ ] @scottmcm
	> * [ ] @spastorino
	> 
	> No concerns currently listed.
	> 
	> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
	> 
	> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3346#issuecomment-1337560286): 
	> @rfcbot merge
	> 
	> This has been under discussion for some time! I am excited about seeing this team get started.


### "Tracking issue for the "efiapi" calling convention" rust#65815

- **Link:** https://github.com/rust-lang/rust/issues/65815
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/65815#issuecomment-1331449645): 
	> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
	> 
	> * [x] @cramertj
	> * [x] @joshtriplett
	> * [ ] @nikomatsakis
	> * [ ] @pnkfelix
	> * [ ] @scottmcm
	> 
	> No concerns currently listed.
	> 
	> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
	> 
	> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/65815#issuecomment-1331449631): 
	> Shall we stabilieze the `extern "efiapi"` calling convention?
	> 
	> @rfcbot merge


### "Stabilize `#![feature(target_feature_11)]`" rust#99767

- **Link:** https://github.com/rust-lang/rust/pull/99767
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/99767#issuecomment-1320937299): 
	> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
	> 
	> * [x] @cramertj
	> * [x] @joshtriplett
	> * [ ] @nikomatsakis
	> * [ ] @pnkfelix
	> * [ ] @scottmcm
	> 
	> No concerns currently listed.
	> 
	> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
	> 
	> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/99767#issuecomment-1320937292): 
	> @rfcbot merge




## Active FCPs
### "RFC: `c"..."` string literals" rfcs#3348

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

### "Remove const eval limit and implement an exponential backoff lint instead" rust#103877

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

## P-critical issues

None.




## Nominated RFCs, PRs and issues discussed this meeting

### "Stop promoting all the things" rust#105085

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

motivating example:

```rust
fn main() {
    let _ = &&(NoisyDrop("drop!"), 0).1;
    // NosiyDrop is not dropped ...
}
```

Breaks 1 crate (and that crate makes heavy use of nightly)

nikomatsakis: I agree with Oli's assessment:

> This is obviously a bug, as the user did not ask for promotion and we should not silently promote away side effects like dropping.

pnkfelix: yeah.

tmandry: seems like something we should fix, any idea when it was added?

nikomatsakis: I would guess a long time, promotion code has been getting more conservative over time.

joshtriplett: FCP?

nikomatsakis: +1, DO IT

### "Stabilize default_alloc_error_handler" rust#102318

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

joshtriplett: This was FCP'd 2 years ago, so do we need a new one? 

pnkfelix: Are you sure previous FCP was t-lang, not t-compiler?

simulacrum: My perspective on FCPs is that we are capturing state of the world at that point. It seems like state of the world has changed in the past 2 years. 

joshtriplett: Valid. If anybody would rather do another FCP we can, but arguably the case we made a decision on was the semantic change to the language, and that hasn't meaningfully changed, there was a quality of impl problem. But quite happy to start an FCP.

simulacrum: I'm saying lang has changed, though I doubt it affects decision in this case

nikomatsakis: I agree with Mark, decisions from 2 years ago that never took place shouldn't be presumed to hold, though I don't see any change in this instance that matters (and maybe )

tmandry: what is behavior without attribute?

joshtriplett: previously it would abort, but now it panics, which means if you're careful, you can potentially catch it

tmandry: this would affect most Rust programs today

joshtriplett: In practice, no... on linux, you'll not see this because it overallocates. Might see it on Windows, not sure about Mac.

simulacrum: tracking issue suggests behavior with std is not changed. If std is linked in, the allocator handler exists, and it aborts, as it always did.

joshtriplett: Oh? I had impression that wasn't true.

simulacrum: If not, we should not FCP, and rather update docs.

joshtriplett: Ah, I see...

*rapid typing by pnkfelix to confirm whether allocation handler still exists for std today*

joshtriplett: It does! Programs that lnk std would not change. Separate question of whether std should change its own error handler.

pnkfelix: right, main goal is enabling nostd+liballoc to run on stable.

### "RFC: Field projection" rfcs#3318

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

y86dev: Has been nominated for quite a while. I still think it needs some time cooking. Current proposal is complicated but haven't found a simpler one. Consensus is it needs to bre improved, but is there any general guidance for what direction? Projection in my current view should be as general as possible. Does everybody know what projection is?

joshtriplett: I nominated this to get a "direction check".

y86dev: to me it seemed useful for pin-projection, cell types (which currently requires unsafe ptr manipulation). Operation is actually safe, since if you have a Cell around a type, each field is also essentially in a Cell.

nikomatsakis: design meeting discussion?

tmandry: we read this in the async WG. I can share a link to the notes. Does require some time to steep in the RFC text.

y86dev: For pin, we also need to handle pin-drop issue, if you're familiar with pin-project, you can't implement Drop on a projectable struct, because in the drop method you have access to `&mut self`, unsound  if you're pinned. We'd have to have some workaround. I also wanted to support general unwrapping, so if you have `Pin` around a struct type, and a field which is not structurally pinned, you can directly access the field, removes the wrapper -- to add that in a general way often requires an elaborate API around it.

tmandry: reminds me of another proposal, coming out of the C++ interop use case, generalization of deref to allow things like raw pointers. Essentially to do autoderef for method invocation. Allow them to be self types. Let me try to find it. 

pnkfelix: note that the RFC was rewritten after the async WG meeting.

...

joshtriplett: sounds like we want to de-nominate for now and it sounds like people should take a look and get an idea of what they think of it. 

tmandry: Link for Receiver trait [proposal](https://gist.github.com/adetaylor/28cb49a866ce4e03ee749f264b0fc1cb), [discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Receiver.20trait.20with.20Target)

y86dev: Seems orthogonal from projection concerns.

### "Implement a lint for implicit autoref of raw pointer dereference " rust#103735

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

nikomatsakis: [Comment after last week](https://github.com/rust-lang/rust/pull/103735#issuecomment-1331291281) -- unclear if this should still be nominated, seems like no?

Conclusion: remove nomination and request re-nomination if there is some specific question.

Action Item: pnkfelix to do that

### "PhantomData: fix documentation wrt interaction with dropck" rust#103413

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

nikomatsakis: This seems right to me. Procedural step? Actually no, I think the correct rules are:

* If the value's type has drop glue (needs proper definition) and a generic parameter T:
    * It is considered to drop a value of type T if...
        * the struct has a field which owns a T
        * there is phantom-data of type T
        * or the struct implements Drop
* Note that phantom-data byitself does not have drop-glue, so when dropped it is a no-op to borrow check

Another way to put it:

* The behavior of the DROP GLUE knows what gets dropped
    * but it also considers `PhantomData` values to be dropped

Action Item: Niko and Felix to follow-up and determine who will leave comment (and who will do experimental analysis, who will consolidate the findings/theories fo comment thread, etc)

### "impl DispatchFromDyn for Cell and UnsafeCell" rust#97373

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

briefly reviewed and verified there is a test, removed nomination

tmandry: should we have a `Cell<Seld>` test?

### "More deriving on packed structs" rust#104429

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

comment:

https://github.com/rust-lang/rust/pull/104429#issuecomment-1319499278

joshtriplett: These traits are not unsafe to derive, wouldn't let you write these impls without an unsafe block normally, but that's not fundamentally a problem. 

pnkfelix: Right, as we control the impl.

joshtriplett: Another proposal going around for unsafe attributes, idea being that to apply certain attributes, must write unsafe in the attribute.

nikomatsakis: maybe but it feels like declared the packed unsafe, still seems valuable to have to vet uses of the fields

some cases that work today will no longer work:

> If you have a packed struct that derives builtin traits, and it contains fields that aren't Copy, and none of its fields are unaligned, then that would work with the old approach and not work with the new approach. Note that in such a struct the packed attribute is not actually changing the layout. (This is the "pretty strange" case mentioned earlier.)

Comment: https://github.com/rust-lang/rust/pull/104429#issuecomment-1319499278

```rust
#[repr(packed)]
#[derive(Eq, PartialEq)]
pub struct FlexZeroSlice {
    width: u8,
    data: [u8],
}
```

[ralf has another comment](https://github.com/rust-lang/rust/pull/104429#issuecomment-1319643988)

Ralf's dear Rust-lang latter: https://github.com/rust-lang/rust/pull/104429#issuecomment-1320909245

nikomatsakis: special-casing `u8/[u8]` seems like an ok special case to me to avoid breakage

joshtriplett: if we just look for u8 and there is some type shadowing u8 in scope...

nikomatsakis: ...good point, we don't have name resolution results. That means you could get bad compilation errors. Example:

```rust=
#[repr(packed)]
#[derive(Eq, PartialEq)]
pub struct FlexZeroSlice {
    width: u8,
    data: [u32],
}

fn main() {}
```

...fails to compile today.

joshtriplett: but even with that case, this will still break some code?

simulacrum: I think the argument is that icu4x is widely used, whereas the others are not.

nikomatsakis: this seems like something we should do over an edition.

joshtriplett: doesn't seem like something where new feature is so eagerly needed, it can't wait 

nikomatsakis: would love to see this over an edition with some eager opt-in you can do today

tmandry: I think that would be fine; icu4x isn't *that* widely used, they just realized 1.0 recently, 58K downloads?

simulacrum: fair, but more widely used than a random crate

pnkfelix: comment thread did say something about how the icu4x case-- what they really want is an assertion that it's *packable*, want to make sure it doesn't have padding injected, they want a layout assertion

## Nominated RFCs, PRs and issues NOT discussed this meeting

### "Panic on invalid usages of `MaybeUninit::uninit().assume_init()`" rust#100423

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

### "always check alignment during CTFE" rust#104616

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

### "Clearly specify the `instruction_set` inlining restrictions" reference#1307

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


