Here's the recent MCP:

https://github.com/rust-lang/compiler-team/issues/727

Discussion

Attendance

• People: TC, vincenzo, petrochenkov, Daria

Meeting roles

• Minutes, driver: TC

Hard problems on default bounds for new auto traits

TC: Starting on the default bounds item, what are some of the hard problems, and how is this approaching them?

petrochenkov: One hard problem is cycles in the trait solver. The solution here is to wait for the new trait solver.

The other is compile times. With the new bounds, it's about twice as slow. We need some fast path. The solution may help for Sized bounds also, as those are added in nearly all places also.

Hard problems on the Forgettable trait

TC: As above, what are some of the hard problems, and how is this approaching them?

petrochenkov: The current approach being implemented isn't the full proposal. Currently it's a bit of a hack. We're currently doing these as post-mono errors.

Say that we have some root function (i.e. ManuallyDrop::new) that forgets things. What we do is that after monomorphization, after all of the type arguments are substituted, we then check whether the types passed to it are Forgettable. This should be checked earlier during typechecking, but this should work for now.

Old unsafe code easily breaks post mono Forgettable

Daria: !Forgettable types introduce new object semantics which old unsafe code does not uphold, even without any function calls by type punning, effectivelly requiring us to restrict pointer casts. Thus old unsafe code should not automatically get ability to work with !Forgettable.

Let's say we have an object that we copy into some byte buffer, which is allowed, and then we forget the actual value. If we don't restrict those values to passed into old unsafe functions. They would assume the leak semantics that we have today. And then do nasty stuff if a function like mem::forget is called.

The ?Forgettable version is actually backward compatible, I believe. So that's good news. At least, until I'm proven otherwise.

Undroppable types could emit post mono error as a variant

Daria: We have a Destruct trait in mind if a type is forbidden to be dropped synchronously. It is actually possible to return an error if we try to instantiate drop glue for that type. This is limited in cases of synchronous code. But for asynchronous code, if we have some object that can only be destructed by asynchronous destructors, we would not need to instantiate drop glue for that type. We would only instantiate asynchronous drop glue. So that is a positive.

Organizational news

petrochenkov: We have a project to work on this through the end of April. I'm not sure we can continue working on it beyond that.

We think that the async drop glue will be mergable by the end of April.

Current status on async drop glue and async drop trait implementation (WIP?)

Daria: Wrote this today:

https://github.com/zetanumbers/posts/blob/main/async-drop-design.md

Effect composition problem

Daria: I'm planning to continue working on the effect composition problem.

Progress on the async drop glue

TC: Oli has a comment about the limits of what…

https://github.com/rust-lang/rust/pull/121801

…does. What do we think about that?

petrochenkov: That's right. We split this work up between two people. There's a branch for the other work but no PR yet:

https://github.com/azhogin/rust/tree/azhogin/async-drop

(The meeting ended here.)