Try   HackMD

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
    Image Not Showing Possible Reasons
    • The image file may be corrupted
    • The server hosting the image is unavailable
    • The image path is incorrect
    • The image format is not supported
    Learn More →
    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

"Weird interaction between specialization and RPITITs" #108309

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

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

"Exponential compile times for chained RPITIT" #102527

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

"AFIT: strange errors on circular impls" #112626

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

"async_fn_in_trait and return_type_notation cause awkward awaits" #112569

Pending PRs on the impl-trait-initiative repo

None.

Open PRs

"stricter hidden type wf-check" rust#115008

"rework opaque type region inference" rust#116891

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

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

Last changed by 
 
Impl Trait Everywhere Initiative
uwu
0
103

Read more

ITE design meeting 2024-02-22: AsyncIterator

People:

Feb 22, 2024
Stabilize associated type position `impl Trait` (ATPIT / ITIAT)

We propose to stabilize #![feature(impl_trait_in_assoc_type)], commonly called either "associated type position impl Trait" (ATPIT) or "impl Trait in associated type" (ITIAT).

Feb 7, 2024
ITE meeting 2024-01-05

Meeting date: 2024-01-05

Jan 6, 2024
ITE meeting 2023-12-14

Meeting date: 2023-12-14

Dec 15, 2023
Read more from Impl Trait Everywhere Initiative
Published on HackMD