@@ -199,24 +199,42 @@ assert (unsafely) that a generic type's destructor is *guaranteed* to
199
199
not access any expired data, even if its type gives it the capability
200
200
to do so.
201
201
202
- That attribute is called ` unsafe_destructor_blind_to_params ` .
202
+ That attribute is called ` may_dangle ` and was introduced in [ RFC 1327]
203
+ (https://github.com/rust-lang/rfcs/blob/master/text/1327-dropck-param-eyepatch.md ).
203
204
To deploy it on the Inspector example from above, we would write:
204
205
205
206
``` rust,ignore
206
207
struct Inspector<'a>(&'a u8, &'static str);
207
208
208
- impl<'a> Drop for Inspector<'a> {
209
- #[unsafe_destructor_blind_to_params]
209
+ unsafe impl<#[may_dangle] 'a> Drop for Inspector<'a> {
210
210
fn drop(&mut self) {
211
211
println!("Inspector(_, {}) knows when *not* to inspect.", self.1);
212
212
}
213
213
}
214
214
```
215
215
216
- This attribute has the word ` unsafe ` in it because the compiler is not
217
- checking the implicit assertion that no potentially expired data
216
+ Use of this attribute requires the ` Drop ` impl to be marked ` unsafe ` because the
217
+ compiler is not checking the implicit assertion that no potentially expired data
218
218
(e.g. ` self.0 ` above) is accessed.
219
219
220
+ The attribute can be applied to any number of lifetime and type parameters. In
221
+ the following example, we assert that we access no data behind a reference of
222
+ lifetime ` 'b ` and that the only uses of ` T ` will be moves or drops, but omit
223
+ the attribute from ` 'a ` and ` U ` , because we do access data with that lifetime
224
+ and that type:
225
+
226
+ ``` rust,ignore
227
+ use std::fmt::Display;
228
+
229
+ struct Inspector<'a, 'b, T, U: Display>(&'a u8, &'b u8, T, U);
230
+
231
+ unsafe impl<'a, #[may_dangle] 'b, #[may_dangle] T, U: Display> Drop for Inspector<'a, 'b, T, U> {
232
+ fn drop(&mut self) {
233
+ println!("Inspector({}, _, _, {})", self.0, self.3);
234
+ }
235
+ }
236
+ ```
237
+
220
238
It is sometimes obvious that no such access can occur, like the case above.
221
239
However, when dealing with a generic type parameter, such access can
222
240
occur indirectly. Examples of such indirect access are:
@@ -263,7 +281,7 @@ some other method invoked by the destructor, rather than being written
263
281
directly within it.
264
282
265
283
In all of the above cases where the ` &'a u8 ` is accessed in the
266
- destructor, adding the ` #[unsafe_destructor_blind_to_params ] `
284
+ destructor, adding the ` #[may_dangle ] `
267
285
attribute makes the type vulnerable to misuse that the borrower
268
286
checker will not catch, inviting havoc. It is better to avoid adding
269
287
the attribute.
0 commit comments