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

#[deriving(..)] doesn't work on structs that specify their bounds using where clauses #19358

Closed
japaric opened this issue Nov 27, 2014 · 0 comments · Fixed by #19831
Closed

Comments

@japaric
Copy link
Member

japaric commented Nov 27, 2014

STR

trait Trait {}

// OK
#[deriving(Show)]
struct Foo<T: Trait> {
    foo: T,
}

#[deriving(Show)]
//~^ error: the trait `Trait` is not implemented for the type `T`
struct Bar<T> where T: Trait {
    bar: T,
}

fn main() {}

Output

If you check the --pretty=expanded output, you'll notice the T: Trait bound is missing in the Bar case.

// OK
struct Foo<T: Trait> {
    foo: T,
}
#[automatically_derived]
impl <T: ::std::fmt::Show + Trait> ::std::fmt::Show for Foo<T> {
    fn fmt(&self, __arg_0: &mut ::std::fmt::Formatter) -> ::std::fmt::Result {
        match *self {
            Foo { foo: ref __self_0_0 } =>
            match (&(*__self_0_0),) {
                (__arg0,) => {
                    #[inline]
                    #[allow(dead_code)]
                    static __STATIC_FMTSTR: &'static [&'static str] =
                        &["Foo { foo: ", " }"];
                    let __args_vec =
                        &[::std::fmt::argument(::std::fmt::Show::fmt,
                                               __arg0)];
                    let __args =
                        unsafe {
                            ::std::fmt::Arguments::new(__STATIC_FMTSTR,
                                                       __args_vec)
                        };
                    __arg_0.write_fmt(&__args)
                }
            },
        }
    }
}

//~^ error: the trait `Trait` is not implemented for the type `T`
struct Bar<T> {
    bar: T,
}
#[automatically_derived]
impl <T: ::std::fmt::Show> ::std::fmt::Show for Bar<T> {
    fn fmt(&self, __arg_0: &mut ::std::fmt::Formatter) -> ::std::fmt::Result {
        match *self {
            Bar { bar: ref __self_0_0 } =>
            match (&(*__self_0_0),) {
                (__arg0,) => {
                    #[inline]
                    #[allow(dead_code)]
                    static __STATIC_FMTSTR: &'static [&'static str] =
                        &["Bar { bar: ", " }"];
                    let __args_vec =
                        &[::std::fmt::argument(::std::fmt::Show::fmt,
                                               __arg0)];
                    let __args =
                        unsafe {
                            ::std::fmt::Arguments::new(__STATIC_FMTSTR,
                                                       __args_vec)
                        };
                    __arg_0.write_fmt(&__args)
                }
            },
        }
    }
}

fn main() { }

Version

rustc 0.13.0-dev (8fb027e39 2014-11-26 12:02:16 +0000)

The possible solution would be to make the deriving syntax extension also copy the where clause bounds into the expanded impl, just like it already does for the "inline bounds" impl<T: Show + Trait> ....

@japaric japaric changed the title #[Deriving(..)] doesn't work on structs that specify their bounds using where clauses #[deriving(..)] doesn't work on structs that specify their bounds using where clauses Nov 27, 2014
brson added a commit that referenced this issue Dec 16, 2014
alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 17, 2014
closes rust-lang#12677 (cc @Valloric)
cc rust-lang#15294

r? @aturon / @alexcrichton

(Because of rust-lang#19358 I had to move the struct bounds from the `where` clause into the parameter list)
alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 17, 2014
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

Successfully merging a pull request may close this issue.

1 participant