Document auto-generated drop glue

[RalfJung]

There should be a section in the reference which document how the compiler-generated drop glue behaves. It should answer questions like this one: rust-lang/unsafe-code-guidelines#225.

[ehuss]

Can you clarify more details on what is currently missing? Comparing that issue to https://doc.rust-lang.org/nightly/reference/destructors.html, it seems like the current docs are fairly clear which values have explicit drop code generated. Based on your comment at rust-lang/unsafe-code-guidelines#225 (comment), I also conclude that since a enum discriminant is not listed as needing a destructor, that there aren't any special requirements for "dropping" it.

[RalfJung]

I mostly forwarded this issue from rust-lang/unsafe-code-guidelines#225, so @joshlf would be good if you could answer the question above. :)

[elichai]

Not sure if the reference is the right place for that, but I'd be curious to learn how the drop glue is implemented (ie the exact logic, and also what the generated code looks like)

[joshlf]

@ehuss

Can you clarify more details on what is currently missing?

In the original issue, I had code like the following:

fn do_thing<T, E>(res: &mut Result<T, E>) {
    match res {
        Ok(...) => ...,
        Err(x) => {
            unsafe {
                let y = ptr::read(x);
                let new = // compute on y
                ptr::write(res, new);
            }
        }
    }
}

The question was whether the ptr::write(res, new) operation was sound, seeing as it overwrites not only the storage for x, butt also the enum's discriminant. By analogy, imagine we did something like this:

let mut b = Box::new(0);
ptr::write(&mut b, Box::new(1));

While this wouldn't be UB, the act of overwriting the bits of b would effectively mem::forget the original contents of b, which would have the side effect of leaking memory.

The question in the original case is: does the act of overwriting the discriminant of an enum have any side effect? Or, to put it another way, does the act of mem::forget-ing the discriminant of an enum have any side effect?

If we wanted to be more formal, and phrase this in terms that make reference only to well-defined concepts in the Rust reference, we might rephrase this as something like: Let E be an enum type, and e: E. If it is the case that e does not contain any values, v, such that dropping v would have observable effects, is it necessarily also the case that dropping e does not have any observable effects?

Note: I phrase it in this convoluted manner since it's possible that some other variant of E besides the variant that e currently takes on might contain values whose dropping would have side effects.

[Havvy]

@elichai Perhaps ask in the compiler channel on Zulip?

[Havvy]

@joshlf I don't think the discriminant matters much there. Once it's checked in the match and you are inside it, you're no longer accessing it. You are accessing x still though, so I'm not sure there. The discriminant doesn't do anything special with how it is dropped itself except for having it tell drop glue what fields to drop when the drop happens.

I think the answer to your question is a "yes".

[bjorn3]

The question was whether the ptr::write(res, new) operation was sound, seeing as it overwrites not only the storage for x, butt also the enum's discriminant.

It is not sound. x is a reference that is only valid for a field, but you overwrite the discriminant too.

[QuineDot]

Comparing that issue to https://doc.rust-lang.org/nightly/reference/destructors.html, it seems like the current docs are fairly clear which values have explicit drop code generated.

The interaction between NLL, Drop implementers, and scope isn't clear (to me anyway) from that document. Is it documented somewhere? (Apologies in advance if this is too off topic.)

N.b. I arrived here after looking for documentation to reference in a URLO thread.

[bjorn3]

NLL doesn't affect the location of drops. Instead drop types still behave as if they have lexical lifetimes if they are not explicitly moved or dropped.

[joshlf]

@bjorn3

It is not sound. x is a reference that is only valid for a field, but you overwrite the discriminant too.

Yes, but we don't use the reference x after the ptr::read call. As to whether overwriting the discriminant makes this unsound, that's the question for this issue :) I've been lead to believe that it's sound because the discriminant is, to abuse an existing phrase, plain old data.

[RalfJung]

It's invalid for entirely unrelated reasons -- when you do &struct.field, that reference (and the pointers derived from it) cannot be used to access anything outside that field. Also see rust-lang/unsafe-code-guidelines#243, rust-lang/unsafe-code-guidelines#256.

EDIT: Looking at the code again, I don't actually see you doing that... you are writing into res. I am not sure how to interpret @bjorn3's comment.

[RalfJung]

Enum discriminants certainly do not have any drop glue themselves, they just guide the drop glue by determining which variant to call the fields' drop glue for.

However, overwriting with ptr::write doesn't cause any drop glue to be called, so I fail to see how your code even has anything to do with drop glue, @joshlf. There seems to be no drop glue being executed there?

[joshlf]

However, overwriting with ptr::write doesn't cause any drop glue to be called, so I fail to see how your code even has anything to do with drop glue, @joshlf. There seems to be no drop glue being executed there?

In some cases, not executing drop glue can have observable effects. E.g., mem::forget(Box::new(0)) has the effect of leaking memory.