History of the question: The Drop Check (dropck) algorithm was introduced to close a soundness hole in early Rust versions where generic destructors could access data that had already been deallocated. Before dropck, one could construct a struct holding a reference to stack-allocated data, implement Drop to dereference it, and have the referenced data dropped before the container, leading to use-after-free. This issue became critical with generic collections that might contain borrowed data, necessitating a conservative analysis to ensure destructor safety.
The problem:
When a generic type Container<T> implements Drop, the compiler must ensure that T strictly outlives the container to prevent the destructor from accessing invalid memory. For types using raw pointers (e.g., *const T), the compiler lacks lifetime information because raw pointers are untracked by the borrow checker. Without explicit lifetime markers, the compiler cannot verify whether the destructor might dereference a pointer to data owned by the current scope that could be freed first.
The solution:
PhantomData acts as a zero-sized marker that simulates ownership or borrowing of a type T or lifetime 'a. By including PhantomData<&'a T> in a struct holding a raw pointer, you inform the compiler that the struct logically holds a reference bound to lifetime 'a. The Drop Check algorithm uses this to enforce that the struct cannot outlive 'a. If the struct implements Drop and could potentially outlive its referent, compilation fails, preventing undefined behavior.
You are building a zero-copy network protocol parser that wraps a byte buffer. You define Packet<'a> containing a raw pointer *const u8 into a temporary Vec<u8> received from the network stack. You attempt to implement Drop for Packet to update parsing statistics by reading through the raw pointer. The danger is that the Vec<u8> is dropped when the receive function exits, but Packet might be stored in a queue for later processing, leading to a use-after-free when Drop runs.
First, you consider using a reference &'a [u8] instead of a raw pointer. This leverages the borrow checker to ensure the buffer lives long enough. However, this restricts the API significantly because you cannot move the packet freely or store it in collections that require 'static bounds, and it prevents self-referential patterns common in parsers.
Second, you consider using Rc<Vec<u8>> to share ownership of the buffer. This ensures the data remains valid as long as any packet exists. The drawback is the performance cost of reference counting and heap allocation, which violates the zero-copy, zero-overhead requirements of high-throughput network processing.
Third, you consider adding PhantomData<&'a ()> to mark the lifetime dependency while keeping the raw pointer for performance. However, this reveals that implementing Drop is fundamentally unsafe here because the compiler cannot guarantee the buffer outlives the packet. You choose to remove the Drop implementation and instead use a manual cleanup method called before the buffer is freed, or switch to Cow<'a, [u8]> to support both borrowed and owned data.
You select the Cow<'a, [u8]> approach, which eliminates raw pointers and the need for unsafe Drop logic. The result is a parser that compiles successfully with strict lifetime guarantees, ensuring that no packet can outlive its underlying buffer while maintaining performance for the borrowed case.
Why does the compiler allow implementing Drop for a struct containing PhantomData<&'static T>, but reject it for PhantomData<&'a T> where 'a is non-static?
When the lifetime is 'static, the referenced data lives for the entire program execution, so there is no possibility of deallocation before the destructor runs. When 'a is a local lifetime, the data could be dropped while the struct still exists, creating a dangling reference access in Drop. The compiler rejects the local lifetime case because it cannot prove the destructor won't access the data after it's freed, whereas 'static provides this guarantee inherently.
How does PhantomData<T> (owning semantics) differ from PhantomData<&'a T> (borrowing semantics) in the context of dropck, and why does the former not prevent the struct from escaping its scope?
PhantomData<T> indicates that the struct acts as if it owns a T, which affects variance and drop check by assuming the struct may drop a T, but it does not tie the struct's lifetime to a specific borrowed lifetime 'a. Therefore, the compiler assumes the struct could outlive any local data unless T itself contains lifetimes. In contrast, PhantomData<&'a T> explicitly constrains the struct to lifetime 'a, ensuring it cannot outlive the borrow and thus preventing use-after-free in destructors.
What was the purpose of the may_dangle attribute (unstable/deprecated) in relation to dropck, and how did it apply to types like Vec<T>?
The #[may_dangle] attribute allowed unsafe code to inform the compiler that a type's Drop implementation would not access the contents of a generic parameter T, even if T were not strictly outliving the container. This was crucial for collections like Vec<T>, which own their buffer but do not need to read the T values during drop (they just deallocate memory). Candidates often miss that Drop Check is conservative by default, assuming Drop might access everything, and that may_dangle was the mechanism to opt-out of this assumption for flexibility in collections, though it required unsafe code and strict invariants to prevent accessing dangling data.