Skip to content

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

New issue

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

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

Already on GitHub? # 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
# for free to join this conversation on GitHub. Already have an account? # 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