Skip to content

Cloning an Arc with a Trait-Object tries to Clone the Trait-Object #15125

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

Closed
reem opened this issue Jun 23, 2014 · 4 comments
Closed

Cloning an Arc with a Trait-Object tries to Clone the Trait-Object #15125

reem opened this issue Jun 23, 2014 · 4 comments

Comments

@reem
Copy link
Contributor

reem commented Jun 23, 2014

This will compile:

use std::sync::Arc;

trait TestTrait {}

pub struct Shared {
    pub thing: Arc<Box<TestTrait + Send + Share>>
}

impl Clone for Shared {
    fn clone(&self) -> Shared {
        Shared {
            thing: self.thing.clone()
        }
    }
}

But adding a :Clone bound to the TestTrait definition like so:

use std::sync::Arc;

trait TestTrait: Clone {}

pub struct Shared {
    pub thing: Arc<Box<TestTrait + Send + Share>>
}

impl Clone for Shared {
    fn clone(&self) -> Shared {
        Shared {
            thing: self.thing.clone()
        }
    }
}

Fails with:

src/shared.rs:12:20: 12:38 error: cannot call a method whose type contains a self-type through an object
src/shared.rs:12             thing: self.thing.clone()
                                    ^~~~~~~~~~~~~~~~~~

I think this is just a name resolution issue, but I'm not sure why this happens.

@alexcrichton
Copy link
Member

This appears to be a problem with autoderef. For example, this code compiles just fine:

use std::sync::Arc;

trait TestTrait: Clone {}

pub struct Shared {
    pub thing: Arc<Box<TestTrait + Send + Share>>
}

fn clone<T: Clone>(t: &T) -> T { t.clone() }

impl Clone for Shared {
    fn clone(&self) -> Shared {
        Shared {
            thing: clone(&self.thing),
        }
    }
}

In other words, the error is legitimate, you're just not calling the method you expecting. It appears the invocation of clone() is jumping to Clone::<Self>::clone rather than Clone::<Arc<Self>>::clone.

@reem
Copy link
Contributor Author

reem commented Jun 23, 2014

That's what I guessed, and in fact I used that same workaround to make this code work. Is this the expected behavior?

@alexcrichton
Copy link
Member

I would suspect that this is a bug, I would also suspect that those such as @pnkfelix, @nick29581, or @nikomatsakis would know more than me.

@reem
Copy link
Contributor Author

reem commented Nov 17, 2014

This is closed under new auto-deref semantics.

@reem reem closed this as completed Nov 17, 2014
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 17, 2023
internal: support `#[rustc_coinductive]`

rust-lang#100386 changed the trait solver so that `Sized` is treated as coinductive trait, just like auto traits. This is now controlled by the perma-unstable `#[rustc_coinductive]` attribute (rust-lang#108033), which this PR adds support for.

In practice, I don't think this matters much if at all. Currently we don't give chalk enough information so chalk cannot precisely (dis)prove `Sized` bounds.
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 17, 2023
Revert "Support `#[rustc_coinductive]`"

Reverts rust-lang#15125, addresses rust-lang/rust-analyzer#15125 (comment)

I'll add the support again once I figure out the problem.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants