Skip to content

Trait method resolution is overly eager for nested pointers & types #11820

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
huonw opened this issue Jan 26, 2014 · 3 comments
Closed

Trait method resolution is overly eager for nested pointers & types #11820

huonw opened this issue Jan 26, 2014 · 3 comments
Labels
A-trait-system Area: Trait system E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.

Comments

@huonw
Copy link
Member

huonw commented Jan 26, 2014

&T has an impl of Clone for all T (i.e. (&T).clone() should always work), however having &TypeThatConditionallyImplementsClone<T> is not always clonable, because (it appears that) the compiler will lock itself into using the Clone impl for the inner type, but find that T doesn't satisfy the requirements and so error.

#[allow(dead_code)];

struct NoClone;

#[cfg(error)]
fn err() {
    let x = Some(NoClone);
    let y = &x;
    let _: &Option<NoClone> = y.clone();
}

fn ok() {
    let x = NoClone;
    let y = &x;
    let _: &NoClone = y.clone();
}

fn main() { }

Without --cfg error it compiles fine, but with it:

pointer-option-method.rs:9:31: 9:41 error: failed to find an implementation of trait std::clone::Clone for NoClone
pointer-option-method.rs:9     let _: &Option<NoClone> = y.clone();
                                                         ^~~~~~~~~~
@reem
Copy link
Contributor

reem commented Sep 3, 2014

Triage. This arises with basically anything that implements Deref including Arc and Box<SomethingClone>.

@japaric
Copy link
Member

japaric commented Nov 7, 2014

@huonw example is working with a recent version:

rustc 0.13.0-dev (97a57ec90 2014-11-07 11:31:25 +0000)

@Gankra
Copy link
Contributor

Gankra commented Dec 31, 2014

The DList iterator that claims to not be able to derive clone seems to be able to now. Marking needs test.

@Gankra Gankra added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Dec 31, 2014
@bors bors closed this as completed in 802e707 Mar 17, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-trait-system Area: Trait system E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Projects
None yet
Development

No branches or pull requests

5 participants