---
title: "ITE meeting 2024-02-15"
tags: ["impl-trait-everywhere", "triage-meeting", "minutes"]
date: 2024-02-15
discussion: https://rust-lang.zulipchat.com/#narrow/stream/315482-t-compiler.2Fetc.2Fopaque-types/topic/ITE.20triage.20meeting.202024-02-15
url: https://hackmd.io/f6-M4RdHTv-aeZXVPsALrA
---

# ITE meeting agenda

- Meeting date: 2024-02-15

## Attendance

- People: TC, CE, Oli, tmandry

## Meeting roles

- Minutes: TC

## Announcements or custom items

(Meeting attendees, feel free to add items here!)

### ATPIT stabilization

https://hackmd.io/f6-M4RdHTv-aeZXVPsALrA

TC: How do we want to approach the open items and concerns?

1. do a crater run: forbid using opaqaues in `dyn for<'a> Trait<impl Trait>` (or even nested RPITs), only with binders, empty binders are fine, just to see how bad it is. if bad, stop capturing higher ranked lifetimes in RPIT, and start erroring on HRL in all other opaques
2. forbid higher ranked lifetimes in opaques in mir borrowck opaque collection, unblocking https://github.com/rust-lang/rust/pull/116935
3. rebase https://github.com/rust-lang/rust/pull/116935 and get it landed
4. to resolve must-define-before-use blocker: go through all uses of ty::Opaque in typeck and check for eager special cases similar to method resolution. It's actually fine :tm: we just need to know what's there and write some new solver tests

### `must-define-before-use`

Oli: `must-define-before-use` is not a blocker now.

Oli: So the resolution to the concern is to build a list of the situations, e.g., in a HackMD, then we'll link to that in the issue to resolve the concern.

Oli: Changing this would be a breaking change, and it breaks things that are desirable to have work.

Oli; The new solver is more eager in registering inference variables, and we can't do method selection on inference variables.

Oli: We don't check unresolved obligations for trait bounds that could allow a method call to succeed. This is something that we could do. This would become more common under the new solver.

CE: Might want to file a separate concern for this.

Oli: I'll do that.

### `rust-analyzer` support

tmandry: I just filed a concern echoing Westley Wiser's concern about this, mostly just on his behalf.

CE: Is anyone on the RA side actually going to implement this? We shouldn't block on it otherwise.

tmandry: This does seem like a T-lang policy question.

Oli: If we want this kind of policy, we probably need funding for RA, because we're not going to get acceptable deadlines otherwise.

CE: This should be brought up in a T-lang meeting.

CE: When we did this for T-style, note that we didn't block stabilizations on implementation in `rustfmt`, for this reason.

tmandry: We should indeed discuss this in the lang call next week.

TC: What surprised me is that I haven't seen RA previously make this request on other issues.

Oli: They could probably just avoid touching `impl Trait` in general.

TC: Last I checked, RA doesn't support RPIT correctly either. It infers types incorrectly.

Oli: On that basis, we should probably just resolve that concern.

Oli: The best thing is if they just focus on ignoring it.

### Add `Projection`/`NormalizesTo` goals for opaque types

https://github.com/rust-lang/rust/issues/105787#issuecomment-1750112388

Oli: The expectation here is that we'll land new trait solver coherence before we stabilize ATPIT.

Oli: This is already happening for projections, so this isn't making the situation worse.

CE: There's probably also a way to hack around this also in the old solver coherence.

### Rejecting opaques nested in HRTB that capture those HR lifetimes across the board

Oli: We'll be rejecting, e.g.:

for<'a> Tr: Trait<Item = impl Trait>

TC: Is this related to what alliemjay asked about related to the lifetime capture rules 2024?

Oli: Yes. He has a solution proposed for this, and we're working through it.

TC: Can we construct RPIT examples for this?

Oli: Yes, probably useless ones.

TC: So it's a breaking change, technically.

Oli: Yes, though we could carve out a corner case for this.

CE: Specifically, we need to reject "opaques nested in HRTB that capture those HR lifetimes".

Oli: Actually, we reject it whenever the lifetime is in scope.

TC: So this difference would only come up under the pre-Rust 2024 rules, since under the 2024 rules, we'd always capture the in-scope lifetime.

CE: I'm concerned about cases where there are two ATPIT... it's difficult to explain.

(The meeting ended here.)

## Project board issues

### "AFIT: impl can't add extra lifetime restrictions, unlike non-async" #104689

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

### "Weird interaction between specialization and RPITITs" #108309

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

### "RPITIT with Send trait marker breaks borrow checker" #111105

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

### "`Failed to normalize` `async_fn_in_trait` ICE for indirect recursion of async trait method calls" #112047

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

### "Exponential compile times for chained RPITIT" #102527

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

### "Mysterious "higher-ranked lifetime error" with async fn in trait and return-type notation" #110963

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

### "AFIT: strange errors on circular impls" #112626

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

### "hrtb + infer types break auto traits with return type notation " #109924

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

### "`async_fn_in_trait` and `return_type_notation` cause awkward awaits" #112569

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

## Pending PRs on the impl-trait-initiative repo

None.

## Open PRs

### "stricter hidden type wf-check" rust#115008

- **Link:** https://github.com/rust-lang/rust/pull/115008
- **Labels:** S-waiting-on-review, A-impl-trait, disposition-merge, finished-final-comment-period, T-types, WG-trait-system-refactor

### "rework opaque type region inference" rust#116891

- **Link:** https://github.com/rust-lang/rust/pull/116891
- **Labels:** S-waiting-on-review, needs-fcp, F-type_alias_impl_trait, T-types

### "Prevent opaque types being instantiated twice with different regions within the same function" rust#116935

- **Link:** https://github.com/rust-lang/rust/pull/116935
- **Labels:** T-lang, S-waiting-on-author, A-impl-trait, proposed-final-comment-period, disposition-merge, F-type_alias_impl_trait, T-types

### "Stabilize associated type position impl Trait (ATPIT)" rust#120700

- **Link:** https://github.com/rust-lang/rust/pull/120700
- **Labels:** T-lang, S-waiting-on-review, A-impl-trait, proposed-final-comment-period, disposition-merge, I-lang-nominated, T-types, F-impl_trait_in_assoc_type