---
title: Triage meeting 2023-01-03
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2023-01-03

## Attendance

* Team members: nikomatsakis, pnkfelix, joshtriplett
* Others: simulacrum, David

## Meeting roles

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

## Scheduled meetings
- "Contracts and Automated Reasoning for Rust" [lang-team#181](https://github.com/rust-lang/lang-team/issues/181)
- Had this meeting, need to have a follow-up.

## Announcements or custom items

### Happy new year


### Roadmap update

joshtriplett: Would be good to follow-up on last year's roadmap post. Not so much "new items" but more of a "status update" on last year's roadmap.

nikomatsakis: maybe a good way forward would be to plan for a design meeting?

joshtriplett: yeah, a working design meeting -- i.e., start with previous roadmap doc, read it over, talk about current state of things. By end of it we should have ability to put a blog post together.

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

None.

## 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
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @spastorino
>
> Concerns:
>
> * process-for-adding-members (https://github.com/rust-lang/rfcs/pull/3346#issuecomment-1349567620)
>
> 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 RFC 2515, "Permit impl Trait in type aliases"" rust#63063

- **Link:** https://github.com/rust-lang/rust/issues/63063
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/63063#issuecomment-1360043090):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * ~~~~ resolved by https://github.com/rust-lang/rust/issues/63063#issuecomment-1361432898
> * docs (https://github.com/rust-lang/rust/issues/63063#issuecomment-1364525286)
>
> 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/63063#issuecomment-1360043060):
> @rfcbot fcp merge
>
> This has been a long-time coming. Let's Do This!
>
> [Stabilization report in this comment.](https://github.com/rust-lang/rust/issues/63063#issuecomment-1354392317)

pnkfelix: do you think it's just a matter of taking the text that's already been written and figuring out how to adapt it to the reference? e.g. the discussion about coherence.

nikomatsakis: I don't think that what's there is sufficiently specific. That particular example of coherence is interesting because I think the rule is coming about by updating how coherence deals with associated types more generally, and isn't specific to opaque types.

### "Tracking Issue for "C-unwind ABI", RFC 2945" rust#74990

- **Link:** https://github.com/rust-lang/rust/issues/74990
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/74990#issuecomment-1363474839):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * docs (https://github.com/rust-lang/rust/issues/74990#issuecomment-1364528477)
>
> 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/74990#issuecomment-1363474832):
> Shall we stabilize the `extern "C-unwind"` and other `-unwind` calling conventions? This change will leave `extern "C"` unchanged for now, but have the existing feature gate continue to opt into the new behavior on nightly. We'll do a separate change later to make `extern "C"` and similar not permit unwinding.
>
> @rfcbot merge

joshtriplett: not on this specific stabilization, but in general, an issue arose that we didn't notice right away. The feature gate was used as a semantic change to the program such that if you opted in to the feature gate, you also got behavior changes (extern "C" stopped allowing unwinding). That made it harder to stabilize this, we ended up having to stick with that behavior for stabilization. In general, we've argued the precedent that feature gates shouldn't have semantic effect, and if you want a semantic effect, you should have to write a directive of some kind, e.g., "opt-in to this feature gate and use this directive that it enables". I still think that's better than having the feature gate itself serve as the opt-in. Can we document that?

nikomatsakis: I think we've done this in other places, e.g., never type fallback.

joshtriplett: we've talked about not wanting to do it, but been inconsistent about it.

pnkfelix: what kind of directive do you envision in this specific case?

joshtriplett: a feature gate for opting in to "C" unwind, and a separate (nightly only) directive for opting in to the new C behavior. When stabilizing, we'd have ditched the directive.

pnkfelix: policy would still be to change the default behavior.

joshtriplett: no problem with changing the default, but if you tie it to a feature gate, it's very hard to partially stabilize it. If you're fully stabilizing a feature, tying semantics to it doesn't necessarily cause a problem. Partially stabilizing requires some juggling to separate out the changes to semantics.

simulacrum: that feels like motivation for having fine-grained features, not clear to me that it would have helped to have an unstable attribute we never want to add. If we had started out with C-unwind and C-unwind-behavior-change, we'd be in a better position, sure.

joshtriplett: can't predict in advance.

simulacrum: yes.

joshtriplett: in general I think we should prefer to have a directive, not a hard-and-fast rule.

nikomatsakis: rustc-dev-guide seems the obvious place to put that note, maybe a compiler-team MCP to get attention to it.

pnkfelix: I think I understand both sides, what simulacrum raised vs josh. Main motivation I can see for directive vs feature gate is that code reviewers will have expectations about what feature gates denote. This business about making a feature gate cause semantic changes in behavior is not expected.

nikomatsakis: I think that's the case, but I think that it will encourage some splitting.

simulacrum: maybe we don't need two mechanisms, just encourage people to have a separate feature gate whenever there's a semantic change in behavior.

pnkfelix: maybe a naming convention?

joshtriplett: I think there's value in saying "if there's any chance these things might be separate, maybe have two feature gates, it's not like they cost much, other than having to write two things instead of one". Annoying.

nikomatsakis: Test coverage implication, have to think about what it means to have one part of the feature but not another.

joshtriplett: separate from whether a feature gate should be semantic. Some value in separating semantic changes from feature gates. Just have the semantic change be attached to some manner of directive. We can discuss the consensus when we have a PR for dev-guide.

### "Stabilise inline_const" rust#104087

- **Link:** https://github.com/rust-lang/rust/pull/104087
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/104087#issuecomment-1350231887):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [ ] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @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/104087#issuecomment-1350231871):
> Restarting the FCP from https://github.com/rust-lang/rust/pull/104087#issuecomment-1315946122
>
> @rfcbot fcp merge

## Active FCPs

None.

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "Tracking Issue for "C-unwind ABI", RFC 2945" rust#74990

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

joshtriplett: Can be un-nominated now that we have an FCP. Removing nomination.

### "Tracking issue for RFC 2515, "Permit impl Trait in type aliases"" rust#63063

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

nikomatsakis: same.

### "Experimental feature gate proposal `interoperable_abi`" rust#105586

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

joshtriplett: same.

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

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

nikomatsakis: SoniEx2 was commenting about whether this behavior is desirable, but the purpose of this PR was to document what the behavior *is*.

joshtriplett: yes, it's true that adding to docs has semantic weight.

nikomatsakis: I think in this case it's not a bug. The behavior is what it is.

joshtriplett: who is expert here?

nikomatsakis: types team, I guess, but between Ralf and I it's been looked at pretty closely.

simulacrum: I think I will leave a few comments on the PR.

nikomatsakis: clarifications?

simualcrum: probably?

joshtriplett: shall we unnominate and say we're fine?

nikomatsakis: yes, let's say we're fine, and any further approvals should come from types.

*simulacrum to write comment*

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

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

nikomatsakis: Did an FCP, it passed, don't know if this needs to be nominated.

[Comment](https://github.com/rust-lang/rust/pull/104429#issuecomment-1360077895)

joshtriplett: Removing nomination, adding relnotes.

### "make &mut !Unpin not dereferenceable, and Box<!Unpin> not noalias" rust#106180

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

nikomatsakis: I think this is related to the stacked borrows bug where you create

Related:

* https://github.com/rust-lang/rust/issues/63818
* https://github.com/rust-lang/unsafe-code-guidelines/issues/381

joshtriplett: should we nominate this for types team?

nikomatsakis: I think it's more opsem team, but yes, it's at this level of detail.

nikomatsakis: is there any other alternative sol'n besides what's described in this PR?

simulacrum: if LLVM is causing unsoundness here, shouldn't we fix that first, and then consider whether to add them back? esp. if there's low cost to doing so?

nikomatsakis: I think that's right, and in particular I think the heuristic ralf is proposing is essentially saying "if this causes problems for miri, then it also means that LLVM would potentially do unsound optimizations".

pnkfelix: I feel like all the UB is coming from miri + SB?

joshtriplett: top comment suggests comex found an instance of LLVM using this for optimization -- I don't think it's a no-op for LLVM.

pnkfelix: Ah, I didn't read that linked LLVM conversation. Good point.

nikomatsakis: I guess it depends on whether this is meant to be a "final decision" on some parts of the usnafe code guidelines, or a pragmatic change to prevent UB for now. For the latter I don't think we need an FCP here, but nominating for lang team is good.

simulacrum: Even if it was the former, I think it would be better to move that final decision to an issue and land the PR.

pnkfelix: Reading the PR text, I don't know why `PtrKind` is removing the shared mutable variant...?

Consensus:

* We would like to remove UB
* We don't interpret this as a final decision on pointer aliasing models
* We think this is a good example of something opsem team would take lead on

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

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

pnkfelix: can you ever get an error?

nikomatsakis: what is the invariant we are trying to capture? it is that the function will be in the documented instruction set?

simulacrum: we don't define what inlining / not inlining *means*, so I'm not sure if this.

nikomatsakis: can we just add a caveat that it's not normative?

joshtriplett: "We don't precisely specify inlining but in general this affects inlining in the following" fashion?

nikomatsakis: pnkfelix follow-up to see if it can be made non-normative?

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

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

https://github.com/rust-lang/rust/pull/103735#issuecomment-1331291281

nikomatsakis: not sure how to deal with this scenario, where some motion was made (e.g., some comments), but not at the level I wanted (an actionable spec).

simulacrum: almost feels like the low-level details falls into opsem, and then the question of "with these semantics, which do we want to lint on" might be lang. Until we have the lower-level semantics, not sure a productive discussion can happen.

nikomatsakis: is there something in doubt, I can't remember?

simulacrum: lint is meant to suggest "hey you're taking a reference which might cause UB indirectly by retagging" but you don't have to take the ref, because there's a method defined on raw pointers. Nuance of "if we didn't have the retagging, maybe you don't need this lint at all, but if you do have it, there are subtle unsafe code bits about where to draw the line".

nikomatsakis: it's true the rules aren't finalized, also true they will almost certainly have some aspect of this.

simulacrum: if we had opsem, I'd probably say, opsem should discuss and say "we want to lint on these patterns", rather than any pointer deref, here's why we think they're dangerous, we believe that any model we will end up with will make them UB, so it makes sense to start moving users away from them regardless of exact semantics.

pnkfelix: can we wait until opsem team exists?

*simulacrum to leave comment, not touch nomination*

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

### "RFC: Start working on a Rust specification" rfcs#3355

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