Storia della domanda: L'algoritmo Drop Check (dropck) è stato introdotto per chiudere una falla di correttezza nelle prime versioni di Rust in cui i distruttori generici potevano accedere a dati già deallocati. Prima di dropck, si poteva costruire una struttura che contiene un riferimento ai dati allocati nello stack, implementare Drop per dereferenziarlo, e avere i dati referenziati rimossi prima del contenitore, portando a usi dopo la liberazione (use-after-free). Questo problema è diventato critico con collezioni generiche che potrebbero contenere dati presi in prestito, necessitando di un'analisi conservativa per garantire la sicurezza del distruttore.
Il problema:
Quando un tipo generico Container<T> implementa Drop, il compilatore deve assicurarsi che T viva strettamente più a lungo del contenitore per evitare che il distruttore acceda a memoria non valida. Per i tipi che utilizzano puntatori grezzi (ad es., *const T), il compilatore manca di informazioni sui tempi di vita perché i puntatori grezzi non sono tracciati dal controllore dei prestiti. Senza marcatori di tempo di vita espliciti, il compilatore non può verificare se il distruttore potrebbe dereferenziarsi a un puntatore a dati posseduti dall'ambito corrente che potrebbero essere liberati per primi.
La soluzione:
PhantomData agisce come un marcatore a dimensione zero che simula la proprietà o il prestito di un tipo T o di una durata 'a. Includendo PhantomData<&'a T> in una struttura che contiene un puntatore grezzo, informi il compilatore che la struttura possiede logicamente un riferimento legato alla durata 'a. L'algoritmo Drop Check utilizza questo per garantire che la struttura non possa vivere più a lungo di 'a. Se la struttura implementa Drop e potrebbe potenzialmente vivere più a lungo del suo referente, la compilazione fallirà, prevenendo comportamenti indefiniti.
Stai costruendo un parser per protocolli di rete zero-copy che avvolge un buffer di byte. Definisci Packet<'a> contenente un puntatore grezzo *const u8 in un temporaneo Vec<u8> ricevuto dallo stack di rete. Provi a implementare Drop per Packet per aggiornare le statistiche di parsing leggendo attraverso il puntatore grezzo. Il pericolo è che il Vec<u8> venga eliminato quando la funzione di ricezione esce, ma Packet potrebbe essere memorizzato in una coda per un'elaborazione successiva, portando a un uso dopo la liberazione quando viene eseguito il Drop.
Inizialmente, consideri di utilizzare un riferimento &'a [u8] invece di un puntatore grezzo. Questo sfrutta il controllore dei prestiti per garantire che il buffer viva a lungo abbastanza. Tuttavia, questo limita significativamente l'API poiché non puoi muovere liberamente il pacchetto o memorizzarlo in collezioni che richiedono vincoli 'static, e impedisce schemi auto-referenziali comuni nei parser.
In secondo luogo, consideri di utilizzare Rc<Vec<u8>> per condividere la proprietà del buffer. Questo garantisce che i dati rimangano validi finché esiste un pacchetto. Lo svantaggio è il costo delle prestazioni del conteggio dei riferimenti e dell'allocazione dell'heap, che viola i requisiti di zero-copy e zero-overhead per l'elaborazione di rete ad alta velocità.
In terzo luogo, consideri di aggiungere PhantomData<&'a ()> per contrassegnare la dipendenza da durata mantenendo il puntatore grezzo per le prestazioni. Tuttavia, questo rivela che implementare Drop è fondamentalmente pericoloso qui perché il compilatore non può garantire che il buffer viva più a lungo del pacchetto. Decidi di rimuovere l'implementazione di Drop e invece utilizzare un metodo di pulizia manuale chiamato prima che il buffer venga liberato, o passare a Cow<'a, [u8]> per supportare sia i dati presi in prestito che quelli posseduti.
Scegli l'approccio Cow<'a, [u8]>, che elimina i puntatori grezzi e la necessità di una logica Drop non sicura. Il risultato è un parser che si compila con successo con garanzie rigorose di durata, garantendo che nessun pacchetto possa vivere più a lungo del suo buffer sottostante mantenendo comunque le prestazioni per il caso preso in prestito.
Perché il compilatore consente di implementare Drop per una struttura contenente PhantomData<&'static T>, ma lo rifiuta per PhantomData<&'a T> dove 'a è non statico?
Quando la durata è 'static, i dati referenziati vivono per l'intera esecuzione del programma, quindi non c'è possibilità di deallocazione prima che il distruttore venga eseguito. Quando 'a è una durata locale, i dati potrebbero essere eliminati mentre la struttura esiste ancora, creando un accesso a riferimento pendente nel Drop. Il compilatore rifiuta il caso della durata locale perché non può dimostrare che il distruttore non accederà ai dati dopo che sono stati liberati, mentre 'static fornisce questa garanzia in modo intrinseco.
In che modo PhantomData<T> (semantica di possesso) differisce da PhantomData<&'a T> (semantica di prestito) nel contesto di dropck, e perché il primo non impedisce alla struttura di uscire dal proprio ambito?
PhantomData<T> indica che la struttura agisce come se possedesse un T, il che influisce sulla variazione e sul controllo di eliminazione assumendo che la struttura possa eliminare un T, ma non lega la durata della struttura a una specifica durata di prestito 'a. Pertanto, il compilatore presume che la struttura possa vivere più a lungo di qualsiasi dato locale a meno che T stesso non contenga durate. Al contrario, PhantomData<&'a T> costringe esplicitamente la struttura alla durata 'a, garantendo che non possa vivere più a lungo del prestito e dunque prevenendo usi dopo la liberazione nei distruttori.
Qual era lo scopo dell'attributo may_dangle (instabile/deprecato) in relazione a dropck, e come si applicava a tipi come Vec<T>?
L'attributo #[may_dangle] permetteva al codice non sicuro di informare il compilatore che l'implementazione di Drop di un tipo non avrebbe accesso ai contenuti di un parametro generico T, anche se T non fosse strettamente più lungo del contenitore. Questo era cruciale per collezioni come Vec<T>, che possiedono il proprio buffer ma non hanno bisogno di leggere i valori T durante la distruzione (devono solo deallocare la memoria). I candidati spesso dimenticano che Drop Check è conservativo per impostazione predefinita, assumendo che Drop potrebbe accedere a tutto, e che may_dangle era il meccanismo per rinunciare a questa assunzione per flessibilità nelle collezioni, anche se richiedeva codice non sicuro e invarianti rigorosi per prevenire l'accesso a dati pendenti.