Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unsized ManuallyDrop #53033

Merged
merged 4 commits into from
Aug 14, 2018
Merged

unsized ManuallyDrop #53033

merged 4 commits into from
Aug 14, 2018

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Aug 3, 2018

I think this matches what @eddyb had in #52711 originally.

However, I have never added a CoerceUnsized before so I am not sure if I did this right. I copied the unstable attribute on the impl from elsewhere, but AFAIK it is useless because impl's are insta-stable... so shouldn't this rather say "stable since 1.30"?

This is insta-stable and hence requires FCP, at least.

Fixes #47034

@rust-highfive
Copy link
Collaborator

r? @bluss

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 3, 2018
@cramertj cramertj added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Aug 3, 2018
@kennytm kennytm added the relnotes Marks issues that should be documented in the release notes of the next release. label Aug 4, 2018
#[inline]
fn deref_mut(&mut self) -> &mut Self::Target {
&mut self.value
}
}

#[unstable(feature = "coerce_unsized", issue = "27732")]
impl<T: CoerceUnsized<U>, U> CoerceUnsized<ManuallyDrop<U>> for ManuallyDrop<T> {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uh, no, this allows ManuallyDrop<Rc<T>> to coerce to ManuallyDrop<Rc<dyn Trait>> - do we need that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this change even useful without a CoerceUnsized? AFAIK all types that do T: ?Sized also have a CoerceUnsized, or is that not the case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In your test, the only needed CoercedUnsized impl is that for Box, pointers to ManuallyDrop can be coerced just because it's a ?Sized struct (you can test this with any such structs, there's no opt-in there).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, done.

@@ -21,4 +21,8 @@ fn smoke() {

let x = ManuallyDrop::new(TypeWithDrop);
drop(x);

// also test unsizing
let x : Box<ManuallyDrop<[TypeWithDrop]>> = Box::new(ManuallyDrop::new([TypeWithDrop]));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be less confusing if the array had two elements or something.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@RalfJung
Copy link
Member Author

RalfJung commented Aug 9, 2018

I also added repr(transparent) because that seems reasonable.

@SimonSapin
Copy link
Contributor

This is insta-stable and hence requires FCP, at least.

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Aug 9, 2018

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Aug 9, 2018
@rfcbot
Copy link

rfcbot commented Aug 12, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Aug 12, 2018
@alexcrichton
Copy link
Member

@bors: r=SimonSapin

@bors
Copy link
Contributor

bors commented Aug 14, 2018

📌 Commit 5ee5a7e has been approved by SimonSapin

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 14, 2018
kennytm added a commit to kennytm/rust that referenced this pull request Aug 14, 2018
unsized ManuallyDrop

I think this matches what @eddyb had in rust-lang#52711 originally.

~~However, I have never added a `CoerceUnsized` before so I am not sure if I did this right. I copied the `unstable` attribute on the `impl` from elsewhere, but AFAIK it is useless because `impl`'s are insta-stable... so shouldn't this rather say "stable since 1.30"?~~

This is insta-stable and hence requires FCP, at least.

Fixes rust-lang#47034
@bors
Copy link
Contributor

bors commented Aug 14, 2018

⌛ Testing commit 5ee5a7e with merge 5bb9239...

bors added a commit that referenced this pull request Aug 14, 2018
unsized ManuallyDrop

I think this matches what @eddyb had in #52711 originally.

~~However, I have never added a `CoerceUnsized` before so I am not sure if I did this right. I copied the `unstable` attribute on the `impl` from elsewhere, but AFAIK it is useless because `impl`'s are insta-stable... so shouldn't this rather say "stable since 1.30"?~~

This is insta-stable and hence requires FCP, at least.

Fixes #47034
@bors
Copy link
Contributor

bors commented Aug 14, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: SimonSapin
Pushing 5bb9239 to master...

@bors bors merged commit 5ee5a7e into rust-lang:master Aug 14, 2018
@RalfJung RalfJung deleted the manually_dro branch August 16, 2018 10:53
@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Aug 22, 2018
@SimonSapin
Copy link
Contributor

Why was no CoerceUnsized impl necessary?

@RalfJung
Copy link
Member Author

Those are for smart ptrs only, not for structs that wrap a T immediately.

@eddyb
Copy link
Member

eddyb commented Nov 4, 2018

To expand on that, we could add this:

impl<T, U> CoerceUnsized<ManuallyDrop<U>> for ManuallyDrop<T>
	where T: CoerceUnsized<U>
{}

But what it'd do is let e.g. ManuallyDrop<Rc<T>> would coerce to ManuallyDrop<Rc<dyn Trait>>.

@js2xxx
Copy link

js2xxx commented Dec 5, 2023

To expand on that, we could add this:

impl<T, U> CoerceUnsized<ManuallyDrop<U>> for ManuallyDrop<T>
	where T: CoerceUnsized<U>
{}

But what it'd do is let e.g. ManuallyDrop<Rc<T>> would coerce to ManuallyDrop<Rc<dyn Trait>>.

I think having some sort of coercion like that is not harmful at all. ManuallyDrop IS a smart pointer by definition because it implements Deref, according to the official API documentation. It can be even directly wrapped in Pin if T: Unpin.
That goes the same for DispatchFromDyn.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ManuallyDrop<T> where T: ?Sized