Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle partial initialization correctly in generators #63616

Open
tmandry opened this issue Aug 15, 2019 · 2 comments
Open

Handle partial initialization correctly in generators #63616

tmandry opened this issue Aug 15, 2019 · 2 comments

Comments

@tmandry
Copy link
Contributor

@tmandry tmandry commented Aug 15, 2019

Problem: consider something like the following,

let gen = || {
  let _x = (yield 5; panic!());
};

This can result in a local saved in our generator of type ((), !), which is partially initialized across the yield. In the layout code we claim that fields are all fully initialized across yields. (This is still a problem even if the second field is not of type !, but is particularly egregious in that case.)

Today this doesn't result in any miscompilations. MIR generation is quite conservative, and never seems to do partial initialization of aggregates across blocks. That might change in the future, and the layouts we create for generators do not take this into account.

The simplest correct thing we can do is to wrap all saved Generator locals in MaybeUninit. This means we need to project through the union in the generator MIR transform, which makes it different from the way we wrap with MaybeUninit "internally" today, to avoid propagating uninhabitedness (see #63035).

The only downside of wrapping everything is that we lose information that might be useful for optimizations and in miri. We can do better than this by only wrapping fields of an aggregate type, or maybe even restricting to fields which contain a field projection in the generator code.

#63230 was a naive attempt at avoiding issues like this, but avoiding partial initialization in surface Rust is not enough to prevent it in MIR.

@RalfJung

This comment has been minimized.

Copy link
Member

@RalfJung RalfJung commented Aug 16, 2019

Cc @eddyb

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

@nikomatsakis nikomatsakis commented Jan 7, 2020

It seems like we have a few options here:

  • We never assume that the fields of a generator are initialized
  • We disable MIR optimizations on generators, or we wait to perform them until things are desugared

Specifically, I don't think we can actually optimize MIR construction to eliminate aggregates, or at least doing so would mean we also have to rework the drop elaboration and so forth.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.