From 36bb4e98fb1628eeec9331038a184cc9e009abd4 Mon Sep 17 00:00:00 2001 From: lcnr Date: Mon, 17 Apr 2023 13:53:07 +0200 Subject: [PATCH] self review --- 0000-template.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/0000-template.md b/0000-template.md index a21f68f4663..1402f42b17f 100644 --- a/0000-template.md +++ b/0000-template.md @@ -6,7 +6,7 @@ # Summary [summary]: #summary -Cleanup the rules for implicit drops by splitting `#[may_dangle]` into two separate attributes +Cleanup the rules for implicit drops by splitting `#[may_dangle]` into two separate attributes: `#[only_dropped]` and `#[fully_ignored]`. Change `PhantomData` to get completely ignored by dropck as its current behavior is confusing and inconsistent. @@ -79,7 +79,7 @@ fn can_drop_dead_reference() { } ``` The above example will however fail if we add a manual `Drop` impl as the compiler conservatively -assumes that all generic parameters of the `Drop` impl are considered used: +assumes that all generic parameters of the `Drop` impl are used: [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e604bcaecb7b2b4cf7fd0440faf165ac). In case a manual `Drop` impl does not access a generic parameter, you can add @@ -116,8 +116,8 @@ fn can_drop_dead_reference() { } ``` -The ability to differentiate between `#[fully_unused]` and `#[only_dropped]` is especially useful -for type parameters, consider the following simplified types from the standard library: +The ability to differentiate between `#[fully_unused]` and `#[only_dropped]` is significant +for type parameters: ```rust pub struct BTreeMap { @@ -155,13 +155,12 @@ When implicitly dropping a variable of type `T`, liveness requirements are compu - or they are marked with `#[only_dropped]`, in which case recurse into the generic argument. - Regardless of whether `T` implements `Drop`, recurse into all types *owned* by `T`: - references, raw pointers, function pointers, function items and scalars do not own - anything. They are trivially drop. + anything. They can be trivially dropped. - tuples and arrays consider their element types to be owned. - all fields (of all variants) of ADTs are considered owned. We consider all variants - for enums. The only exception here is `ManuallyDrop` which does not consider `U` to - be owned. `PhantomData` does not have any fields and therefore also does not consider - `U` to be owned. - - closures and generators consider their upvars to be owned. + for enums. The only exception here is `ManuallyDrop` which is not considered to own `U`. `PhantomData` does not have any fields and therefore also does not consider + `U` to be owned. + - closures and generators own their captured upvars. Checking drop impls may error for generic parameters which are known to be incorrectly marked: - `#[fully_unused]` parameters which are recursively owned @@ -178,8 +177,8 @@ into types owned by `T` to figure out the correct constraints. `PhantomData` currently considers `U` to be owned while not having drop glue itself. This means that `(PhantomData>, String)` requires `'s` to be live while -`(PhantomData>, u32)` does not. The current behavior is required for get the -behavior of `#[only_dropped]` for unowned parameters by adding `PhantomData` as a field. +`(PhantomData>, u32)` does not. This is required for get the +behavior of `#[only_dropped]` for parameters otherwise not owned by adding `PhantomData` as a field. One can easily forget this, which caused the [unsound](https://github.com/rust-lang/rust/issues/76367) [issues](https://github.com/rust-lang/rust/issues/99408) mentioned above. @@ -204,9 +203,9 @@ It is therefore quite important to improve the status quo. A more general extension to deal with partially invalid types is far from trivial. We currently assume types to always be well-formed and any approach which generalizes `#[may_dangle]` will -have huge consequences for how well-formedness is handled. This impacts many - often implicit - +have major consequences for how well-formedness is handled. This impacts many - often implicit - interactions and assumptions. It is highly unlikely that we will have the capacity for any such change -in the near future. The benefits from such are change are also likely to be fairly limited while +in the near future. The benefits from such are change are likely to be fairly limited while adding significant complexity. # Prior art