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

Stabilize nested self receivers #64325

Open
wants to merge 1 commit into
base: master
from

Conversation

@cramertj
Copy link
Member

commented Sep 9, 2019

Previously, only Self, &Self, &mut Self, Arc, Rc,
and Box were available as stable method receivers.

This commit stabilizes nested uses of all the above types.
However, nested receivers remain non-object-safe.

I'll follow up with a comment proposing FCP for this.

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented Sep 9, 2019

r? @zackmdavis

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

src/librustc_typeck/check/wfcheck.rs Outdated Show resolved Hide resolved
src/librustc_typeck/check/wfcheck.rs Show resolved Hide resolved
src/librustc_typeck/check/wfcheck.rs Outdated Show resolved Hide resolved
Stabilize nested self receivers
Previously, only Self, &Self, &mut Self, Arc<Self>, Rc<Self>,
and Box<Self> were available as stable method receivers.

This commit stabilizes nested uses of all the above types.
However, nested receivers remain non-object-safe.

@cramertj cramertj force-pushed the cramertj:nested-self-types branch from 0e077b0 to 4355661 Sep 9, 2019

@@ -879,6 +879,11 @@ fn receiver_is_valid<'fcx, 'tcx>(
// The first type is `receiver_ty`, which we know its not equal to `self_ty`; skip it.
autoderef.next();

let receiver_trait_def_id = fcx.tcx.require_lang_item(
lang_items::ReceiverTraitLangItem,
None,

This comment has been minimized.

Copy link
@Centril

Centril Sep 9, 2019

Member

Not Some(span) here?

This comment has been minimized.

Copy link
@cramertj

cramertj Sep 10, 2019

Author Member

Nope, the span this would point to would be nonsense (it'd point to some random function that took self: ... as an argument)

This comment has been minimized.

Copy link
@Centril

Centril Sep 10, 2019

Member

I see. Can you add your explanation as a comment?

@Centril

This comment has been minimized.

Copy link
Member

commented Sep 11, 2019

Thought about this some more... I think it would be good to extend the lifetime elisions tests as well to account for what we're adding here to be on the safe side (although that is controlled by a different part of the compiler, that is the current state of affairs and having an insurance policy is nice).

@Centril

This comment has been minimized.

Copy link
Member

commented Sep 11, 2019

Also... some more thinking: It might be premature to do the impl + stabilization in one go. I think I would be more comfortable with feature gating the impl + letting it sit for a few weeks in nightly before stabilizing so we are sure there aren't any problems...

@cramertj

This comment has been minimized.

Copy link
Member Author

commented Sep 12, 2019

I think it would be good to extend the lifetime elisions tests as well to account for what we're adding here to be on the safe side (although that is controlled by a different part of the compiler, that is the current state of affairs and having an insurance policy is nice).

Sure, I can add some more elision-specific tests.

It might be premature to do the impl + stabilization in one go. I think I would be more comfortable with feature gating the impl + letting it sit for a few weeks in nightly before stabilizing so we are sure there aren't any problems...

This has already been available on nightly under #![feature(arbitrary_self_types)] for nearly a year now. I don't think that it'd benefit from being separately feature-gated for more time.

@Centril

This comment has been minimized.

Copy link
Member

commented Sep 12, 2019

This has already been available on nightly under #![feature(arbitrary_self_types)] for nearly a year now. I don't think that it'd benefit from being separately feature-gated for more time.

I mostly wanted a few weeks to test the new code paths but I guess the gating itself might be as much code as the PR itself so it might not actually test the specifics much more.

@zackmdavis

This comment has been minimized.

Copy link
Member

commented Sep 14, 2019

(going through my review debt now; since Centril has already stepped up to comment in depth, I hope it's OK if I abdicate reviewer status on this one)

r? @Centril

@rust-highfive rust-highfive assigned Centril and unassigned zackmdavis Sep 14, 2019

@Centril

This comment has been minimized.

Copy link
Member

commented Sep 14, 2019

I'm gonna pass the torch to @mikeyhew since this is the first time I've read this code. ;)

@Centril

This comment has been minimized.

Copy link
Member

commented Sep 14, 2019

Forgot to actually do that... 😅

r? @mikeyhew

@Centril

This comment has been minimized.

Copy link
Member

commented Sep 14, 2019

I guess they cannot be assigned... assigning to @nikomatsakis who reviewed #56805 and also cc @arielb1 who reviewed #45870.

r? @nikomatsakis

@mikeyhew
Copy link
Contributor

left a comment

I thought I'd take a look anyway. LGTM


fn receiver_is_implemented(
fcx: &FnCtxt<'_, 'tcx>,
receiver_trait_def_id: DefId,

This comment has been minimized.

Copy link
@mikeyhew

mikeyhew Sep 15, 2019

Contributor

Just wondering - is there any benefit to taking this as an argument instead of getting it in the function body? How expensive of an operation is require_lang_item?

@jonas-schievink jonas-schievink added this to the 1.39 milestone Sep 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.