Add associated types support for #[derive(...)] #21237

erickt · 2015-01-16T15:14:08Z

This PR adds support for associated types to the #[derive(...)] syntax extension. In order to do this, it switches over to using where predicates to apply the type constraints. So now this:

type Trait {
    type Type;
}

#[derive(Clone)]
struct Foo<A> where A: Trait {
    a: A,
    b: <A as Trait>::Type,
}

Gets expended into this impl:

impl<A: Clone> Clone for Foo<A> where
    A: Trait,
    <A as Trait>::Type: Clone,
{
    fn clone(&self) -> Foo<T> {
        Foo {
            a: self.a.clone(),
            b: self.b.clone(),
        }
    }
}

rust-highfive · 2015-01-16T15:14:20Z

r? @alexcrichton

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

erickt · 2015-01-16T16:55:54Z

Unfortunately this can't land quite yet. It turns out the visibility checker reports that this is exposing a private type:

struct Foo<T>(T);
impl<T> Clone for Foo<T> where T: Clone { ... }

pub struct Bar<T>(Foo<T>);
impl<T> Clone for Bar<T> where Foo<T>: Clone { ... }

@nikomatsakis said in #21203 (comment) that the privacy rules are being too strict here and might need to be relaxed.

alexcrichton · 2015-01-16T18:45:03Z

r? @huonw - you're more familiar with #[derive] internals than I

nikomatsakis · 2015-01-16T21:26:20Z

I'm not so sure about the privacy thing anymore.

huonw · 2015-01-17T00:05:28Z

src/libsyntax/ext/deriving/generic/mod.rs

+
+    impl<'a> visit::Visitor<'a> for Visitor<'a> {
+        fn visit_path(&mut self, path: &'a ast::Path, _id: ast::NodeId) {
+            match path.segments.first() {


I suspect this should check that path.segments has length 1, or maybe the shadowing rules means it doesn't matter? (i.e. is struct Foo<std> { x: std::option::Option<u8> } legal?)

Drat, you're right, this currently compiles:

mod T { pub type Type = i32; } trait Trait { type Type; } struct Baz<T: Trait> { a: T::Type, }

I filed #21301 to get that fixed. It'll probably not be that much of an issue in practice though, as you'd have to be crazy to write that :)

huonw · 2015-02-01T11:03:49Z

@erickt what's the status of this? Is

Unfortunately this can't land quite yet

still true?

erickt · 2015-02-03T21:06:20Z

@huonw: Ack! I was on a business trip this past week and forgot all about wrapping up this PR. I'll try to get it done this week :)

erickt · 2015-02-05T17:26:00Z

@huonw: Should work now, and it passes locally. re-r?

erickt · 2015-02-07T08:29:23Z

@huonw: updated the PR to also work with phantom types, closing #7671.

huonw · 2015-02-08T02:41:08Z

This approach is definitely an improvement, but it doesn't solve #7671 completely, e.g.

#[derive(Debug)] // T: Debug is not inserted
struct Foo<T>;

#[derive(Debug)] // T: Debug is inserted, but T is still phantom
struct Bar<T> {
    x: Foo<T>
}

Also, I think this may "break" the standard library marker types like InvariantType (and Phantom if/when it appears) which are possibly meant to represent that some type behaves like it stores a T, so the relevant traits should only be implemented when T has them implemented. The type parameters to these types are phantom types so #[derive] will no longer insert those bounds after this patch.

That said, I'm not sure that it is necessary to have these restricted implementions.

goffrie · 2015-02-08T03:02:42Z

I suspect it's not worth trying to solve the general case of #7671. The privacy thing is a real kicker - if a public type Bar<T> contains a private type Foo<T>, then Bar essentially needs to expose the full rules for Foo<T> being Clone-able - so the derive mechanism would need to see what impls exist for Foo<T>, which might depend on even more private types... As a middle ground, maybe we could emit the where Foo<T>: Clone clause when Foo is public (or Bar is private), but use the approximation where T: Clone otherwise?

erickt · 2015-02-08T03:46:16Z

@goffrie: unfortunately in libsyntax at this point in time we can't see if a type is public or private. I believe we would need typeck in order to have that information.

@huon: good point. Maybe phantom types impls should written by hand.

erickt · 2015-02-09T02:16:24Z

After talking to @huonw, I feel like there isn't a great solution that works for phantom/marker types at the same time as working for an edge case of associated types. Say we extend @huonw's phantom type example from before, this time adding an associated type that's not using the trait type:

#[derive(Debug)]
struct Foo<T>;

#[derive(Debug)]
struct Bar<T>(Foo<T>);

trait Trait { type Type; }

#[derive(Debug)]
struct Baz<T: Trait>(T::Type);

We can either generate an impl that constrains all the type parameters, which is our current approach:

struct Foo<T>;
impl<T> Debug for Foo<T> where T: Debug { ... }

struct Bar<T>(Foo<T>);
impl<T> Debug for Bar<T> where T: Debug { ... }

trait Trait { type Type; }

struct Baz<T: Trait>(T::Type);
impl<T> Debug for Baz<T> where T: Debug, T::Type: Debug { ... }

Notice that the impl for Baz has an unnecessary T: Debug constraint. Or only the type parameters used in the field:

struct Foo<T>;
impl<T> Debug for Foo<T> { ... }

struct Bar<T>(Foo<T>);
impl<T> Debug for Bar<T> where T: Debug { ... }

trait Trait { type Type; }

struct Baz<T: Trait>(T::Type);
impl<T> Debug for Baz<T> where T::Type: Debug { ... }

Notice that for Bar there is an unnecessary T: Debug constraint because Foo<T> doesn't use T.

Does anyone have an opinion on which approach to use, or if there are some good heuristics here to decide what to do here?

huonw · 2015-03-08T05:41:46Z

src/libsyntax/ext/deriving/generic/mod.rs

+                        None => {}
+                    }
+                }
+                ast::TyQPath(_) => {


Hm, this will pick up non-generic QPath's too, right? e.g. struct Foo(<Bar as Iterator>::Item);.
(I guess these come up rarely enough that it probably doesn't matter?)

I'll add a pass through the QPath that checks if it references any of the type parameters. If it does, I'll add it to the types to be constrained. If not, i'll skip it. That should protect against this case.

erickt · 2015-03-14T07:45:06Z

Took a while, but I finally updated the patch to compile on head and address @goffrie's comment.

tamird · 2015-03-15T15:40:39Z

src/libsyntax/ext/deriving/generic/mod.rs

@@ -558,6 +652,21 @@ impl<'a> TraitDef<'a> {
                       enum_def: &EnumDef,
                       type_ident: Ident,
                       generics: &Generics) -> P<ast::Item> {
+        let mut field_tys = Vec::new();
+
+        for variant in enum_def.variants.iter() {


can this be written as

let field_tys = enum_def.variants.flat_map(|variant| { match variant.node.kind { ast::VariantKind::TupleVariantKind(ref args) => { args.iter().map(|arg| arg.ty.clone()) } ast::VariantKind::StructVariantKind(ref args) => { args.fields.iter().map(|field| field.node.ty.clone()) } } }).collect();

❓

@tamird: Unfortunately it cannot because those inner iterators are actually two different types.

erickt · 2015-03-19T15:35:25Z

@bors: r+ edb33f2

bors · 2015-03-19T15:45:22Z

⌛ Testing commit edb33f2 with merge e989552...

bors · 2015-03-19T16:42:15Z

💔 Test failed - auto-mac-64-opt

Manishearth · 2015-03-20T11:22:03Z



---- [compile-fail] compile-fail/derive-assoc-type-not-impl.rs stdout ----

error: compile-fail test compiled successfully!
status: exit code: 0
command: x86_64-apple-darwin/stage2/bin/rustc /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/test/compile-fail/derive-assoc-type-not-impl.rs -L x86_64-apple-darwin/test/compile-fail/ --target=x86_64-apple-darwin -L x86_64-apple-darwin/test/compile-fail/derive-assoc-type-not-impl.stage2-x86_64-apple-darwinlibaux -C prefer-dynamic -o x86_64-apple-darwin/test/compile-fail/derive-assoc-type-not-impl.stage2-x86_64-apple-darwin --cfg rtopt --cfg debug -O -L x86_64-apple-darwin/rt
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------

------------------------------------------

thread '[compile-fail] compile-fail/derive-assoc-type-not-impl.rs' panicked at 'explicit panic', /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/compiletest/runtest.rs:1482



failures:
    [compile-fail] compile-fail/derive-assoc-type-not-impl.rs

bors · 2015-03-24T20:59:07Z

⌛ Testing commit 7971f39 with merge 4c3f968...

bors · 2015-03-24T21:21:54Z

💔 Test failed - auto-linux-64-x-android-t

Closes rust-lang#7671, rust-lang#19839

erickt · 2015-03-24T21:44:51Z

@bors: retry

erickt · 2015-03-25T00:42:40Z

@bors: r+ rollup

bors · 2015-03-25T00:42:41Z

📌 Commit 9cabe27 has been approved by erickt

bors · 2015-03-25T05:29:16Z

⌛ Testing commit 9cabe27 with merge 72d0695...

bors · 2015-03-25T07:47:29Z

💔 Test failed - auto-win-32-opt

erickt · 2015-03-25T15:10:47Z

@bors: retry

This PR adds support for associated types to the `#[derive(...)]` syntax extension. In order to do this, it switches over to using where predicates to apply the type constraints. So now this: ```rust type Trait { type Type; } #[derive(Clone)] struct Foo<A> where A: Trait { a: A, b: <A as Trait>::Type, } ``` Gets expended into this impl: ```rust impl<A: Clone> Clone for Foo<A> where A: Trait, <A as Trait>::Type: Clone, { fn clone(&self) -> Foo<T> { Foo { a: self.a.clone(), b: self.b.clone(), } } } ```

bors · 2015-03-26T13:38:42Z

⌛ Testing commit 9cabe27 with merge 557d434...

This PR adds support for associated types to the `#[derive(...)]` syntax extension. In order to do this, it switches over to using where predicates to apply the type constraints. So now this: ```rust type Trait { type Type; } #[derive(Clone)] struct Foo<A> where A: Trait { a: A, b: <A as Trait>::Type, } ``` Gets expended into this impl: ```rust impl<A: Clone> Clone for Foo<A> where A: Trait, <A as Trait>::Type: Clone, { fn clone(&self) -> Foo<T> { Foo { a: self.a.clone(), b: self.b.clone(), } } } ```

bors · 2015-03-26T16:10:21Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-nopt-t, auto-win-64-opt

derive applies the necessary trait bounds to derived impl. see rust-lang/rust#21237 for more details

435: derive Eq for other core geo types r=frewsxcv a=michaelkirk Adds `Eq` conformance to other core geo types, building off of #431 > Seems reasonable to me! Yeah +1 to adding the same impl for all the other core geo types Rather than spelling out the impl, I've taken advantage of how `derive` already bounds the generated impl for us. See rust-lang/rust#21237 for more details I wrote a few doc-tests while developing, but I reverted them in fc33f9f since they're pretty verbose, and seem superfluous since they're only asserting rust language semantics rather than anything substantial in this lib. I can un-revert them if you'd prefer. Co-authored-by: Michael Kirk <[email protected]>

jendrikw · 2022-07-18T16:00:12Z

I think this is badly documented. A few sentences at https://doc.rust-lang.org/std/clone/trait.Clone.html#derivable would be nice.

rust-highfive assigned alexcrichton Jan 16, 2015

erickt force-pushed the derive-assoc-types branch from a861370 to 46a221e Compare January 16, 2015 15:14

rust-highfive assigned huonw and unassigned alexcrichton Jan 16, 2015

huonw reviewed Jan 17, 2015
View reviewed changes

bvssvni mentioned this pull request Feb 4, 2015

Compiler errors (Copy constraint on Buffer) PistonDevelopers/hematite#181

Closed

erickt force-pushed the derive-assoc-types branch from 46a221e to 85ba662 Compare February 5, 2015 17:24

goffrie mentioned this pull request Feb 6, 2015

deriving(Eq) requires Eq for type parameter even when phantom #7671

Closed

erickt force-pushed the derive-assoc-types branch from 85ba662 to 6311d3b Compare February 7, 2015 08:29

huonw reviewed Mar 8, 2015
View reviewed changes

erickt force-pushed the derive-assoc-types branch from 6311d3b to edb33f2 Compare March 14, 2015 07:43

tamird reviewed Mar 15, 2015
View reviewed changes

erickt added 2 commits March 24, 2015 14:26

test: silence a warning

d4701bd

syntax: Update #[derive(...)] to work with phantom and associated types

9cabe27

Closes rust-lang#7671, rust-lang#19839

erickt force-pushed the derive-assoc-types branch from 7971f39 to 9cabe27 Compare March 24, 2015 21:43

Manishearth mentioned this pull request Mar 26, 2015

Rollup of 7 pull requests #23724

Closed

erickt mentioned this pull request Mar 26, 2015

Rollup of 5 pull requests #23726

Closed

erickt mentioned this pull request Mar 26, 2015

Rollup of 5 pull requests #23727

Closed

bors merged commit 9cabe27 into rust-lang:master Mar 26, 2015

Aatch mentioned this pull request Feb 28, 2016

It is possible to write to a field of an uninitialized struct #31947

Closed

michaelkirk added a commit to michaelkirk/rust-geo that referenced this pull request Apr 1, 2020

derive Eq trait

302d17d

derive applies the necessary trait bounds to derived impl. see rust-lang/rust#21237 for more details

michaelkirk mentioned this pull request Apr 1, 2020

derive Eq for other core geo types georust/geo#435

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add associated types support for #[derive(...)] #21237

Add associated types support for #[derive(...)] #21237

erickt commented Jan 16, 2015

rust-highfive commented Jan 16, 2015

erickt commented Jan 16, 2015

alexcrichton commented Jan 16, 2015

nikomatsakis commented Jan 16, 2015

huonw Jan 17, 2015

erickt Jan 17, 2015

huonw commented Feb 1, 2015

erickt commented Feb 3, 2015

erickt commented Feb 5, 2015

erickt commented Feb 7, 2015

huonw commented Feb 8, 2015

goffrie commented Feb 8, 2015

erickt commented Feb 8, 2015

erickt commented Feb 9, 2015

huonw Mar 8, 2015

erickt Mar 8, 2015

erickt commented Mar 14, 2015

tamird Mar 15, 2015

erickt Mar 19, 2015

erickt commented Mar 19, 2015

bors commented Mar 19, 2015

bors commented Mar 19, 2015

Manishearth commented Mar 20, 2015

bors commented Mar 24, 2015

bors commented Mar 24, 2015

erickt commented Mar 24, 2015

erickt commented Mar 25, 2015

bors commented Mar 25, 2015

bors commented Mar 25, 2015

bors commented Mar 25, 2015

erickt commented Mar 25, 2015

bors commented Mar 26, 2015

bors commented Mar 26, 2015

jendrikw commented Jul 18, 2022

Add associated types support for #[derive(...)] #21237

Add associated types support for #[derive(...)] #21237

Conversation

erickt commented Jan 16, 2015

rust-highfive commented Jan 16, 2015

erickt commented Jan 16, 2015

alexcrichton commented Jan 16, 2015

nikomatsakis commented Jan 16, 2015

huonw Jan 17, 2015

Choose a reason for hiding this comment

erickt Jan 17, 2015

Choose a reason for hiding this comment

huonw commented Feb 1, 2015

erickt commented Feb 3, 2015

erickt commented Feb 5, 2015

erickt commented Feb 7, 2015

huonw commented Feb 8, 2015

goffrie commented Feb 8, 2015

erickt commented Feb 8, 2015

erickt commented Feb 9, 2015

huonw Mar 8, 2015

Choose a reason for hiding this comment

erickt Mar 8, 2015

Choose a reason for hiding this comment

erickt commented Mar 14, 2015

tamird Mar 15, 2015

Choose a reason for hiding this comment

erickt Mar 19, 2015

Choose a reason for hiding this comment

erickt commented Mar 19, 2015

bors commented Mar 19, 2015

bors commented Mar 19, 2015

Manishearth commented Mar 20, 2015

bors commented Mar 24, 2015

bors commented Mar 24, 2015

erickt commented Mar 24, 2015

erickt commented Mar 25, 2015

bors commented Mar 25, 2015

bors commented Mar 25, 2015

bors commented Mar 25, 2015

erickt commented Mar 25, 2015

bors commented Mar 26, 2015

bors commented Mar 26, 2015

jendrikw commented Jul 18, 2022