PhantomData<T> no longer dropck?

Consider this code:

use std::marker::PhantomData;

struct Pending<T> {
    phantom: PhantomData<T>,
}

fn pending<T>(value: T) -> Pending<T> {
    Pending {
        phantom: PhantomData,
    }
}

struct Inspector<'a> {
    value: &'a String,
}

impl Drop for Inspector<'_> {
    fn drop(&mut self) {
        eprintln!("drop inspector {}", self.value)
    }
}

fn main() {
    let p: Pending<Inspector>;
    let s = "hello".to_string();
    p = pending(Inspector { value: &s });
}

Playground

I believe it should not compile (by failing dropcheck). It, however, compiles and runs on 1.42 and 1.31. On 1.24 it indeed fails as I expect.

The equivalent code, where PhantomData<T> is replaced with T rightfully fails to compiles: Playground. So, dropchk somehow observes the difference between T and PhantomData<T>?

Either I misunderstand how PhantomData<T> is supposed to work, or this is a stable-to-stable regression and a soundless hole.

It, however, compiles and runs on 1.42 and 1.31.

It fails to compile with the 2015 edition on 1.31, so it's probably caused by NLL.

I suspect the issue is something like: PhantomData never "needs drop", so your struct also doesn't, so no Drop terminator is created that could access the borrowed value.

Adding an unrelated field that has a destructor makes the error appear again

Regression from 1.36: https://rust.godbolt.org/z/hnEi6A

@matthewjasper

cc @matthewjasper

Assigning P-high to this bug and leaving the nomination, this could have been P-critical too. This was discussed as part of our pre-triage meeting in Zulip.

@danielhenrymantilla

@danielhenrymantilla Yeah, something like that is what I was imagining... though your code still has #[may_dangle] drop on the same type RemoteDrop that also has the PhantomData. I think I was imagining putting the function pointer and drop impl down into another type, so that #[may_dangle] and PhantomData are on two different types.

I am not sure why RawOption would be needed?

@RalfJung

@RalfJung I'm still confused about:

This is unsound because of the lack of PhantomData, no matter whether the drop impl is may_dangle or not.

From my understanding of dropck, considering MyBox<T> impl no #[may_dangle] Drop:

If it construct

without PhantomData<T>, the dropck would be:

dropck(MyBox<T>, 'scope) := T: 'scope (strictly)
with PhantomData<T>:

dropck(MyBox<T>, 'scope) := T: 'scope & dropck(T, 'scope) where dropck(PhantomData<T>, 'scope) := dropck(T, 'scope)

If you want to construct a ub from the former, it is equivalent to finding a T that satisfies T: 'scope but not dropck(T, 'scope), and causes ub when it destructs.

But I tried to construct such a T and failed. I can't even find a counterexample for T:' scope - > dropck(T, 'scope).

And I'm not sure how this violates dropck:

I still have an idea for a counterexample but it's getting tricky: a type not having T in its parameters at all (some kind oft type erasure going on) would have to still drop a T. The T would be remembered by an outer wrapper type that however does not have a destructor.

Wow this is an ancient thread, and I lost all context. Could you link to the context where I said that? Also I recently opened #103413, does that help?

@pnkfelix

Re-reading the thread above, it seems to be about the same fundamental question as #102810. Curious.

My PR fixes the documentation paragraph that @pnkfelix quoted above

Adding a field of type PhantomData indicates that your type owns data of type T. This in turn implies that when your type is dropped, it may drop one or more instances of the type T. This has bearing on the Rust compiler's drop check analysis.

They also wrote

I do worry a little bit about the user's mental model for this case, however. The claim "PhantomData is just like a T" doesn't quite hold up. (not that it ever did ...)

which is still true and would require pretty fundamental changes to NLL at this point.

I know PhatomData only works on needs_drop types dropping.

I'm just curious how the following code causes ub, and how it violates dropck rules:

For example:
struct MyBox<T>(NonNull<T>);
// Mirror `Box` API, including `Drop`.
This is unsound because of the lack of PhantomData, no matter whether the drop impl is may_dangle or not.

#70841 (comment)

Ah, you mean here. A link would have been helpful. :)
Note that I go on saying

Hm... okay things don't work entirely as I thought they would.

#103413 clarifies the misunderstanding me and many others had -- PhantomData is never needed for Drop unless you use may_dangle.

Oh, I will note that :D.

PhantomData is never needed for Drop unless you use may_dangle

But as the example in #103413 (comment), PhantomData still works for "normal" dropping.(without #[may_dangle])

Yeah I read that thread after this one.^^ The summary is "it's complicated, hopefully we'll figure it out in #103413". Let's not re-post everything in two spots. :)

Auto merge of rust-lang#103413 - RalfJung:phantom-dropck, r=lcnr

Auto merge of #103413 - RalfJung:phantom-dropck, r=lcnr

Navigation Menu

Repository navigation

PhantomData<T> no longer dropck? #70841

21 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

PhantomData<T> no longer dropck? #70841

Description

Activity

jonas-schievink commented on Apr 6, 2020

jonas-schievink commented on Apr 6, 2020

tesuji commented on Apr 7, 2020

jonas-schievink commented on Apr 7, 2020

spastorino commented on Apr 8, 2020

21 remaining items

RalfJung commented on May 1, 2020

TOETOE55 commented on Nov 23, 2022

RalfJung commented on Nov 23, 2022

RalfJung commented on Nov 23, 2022

TOETOE55 commented on Nov 23, 2022

RalfJung commented on Nov 23, 2022

TOETOE55 commented on Nov 23, 2022

RalfJung commented on Nov 23, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions