deriving doesn't work inside function

[lifthrasiir]

Example: (also confirmed by --pretty expanded)

fn main() {
    #[deriving(Eq)] struct x { x:int }
    x{x:4} == x{x:4};
}

[lifthrasiir]

It seems that this issue is well known but not filed as a bug. Also note that the problem is not limited to deriving_eq but other item decorators as well.

[catamorphism]

Not critical for 0.7. Nominating for milestone 1, well-defined.

[graydon]

declined; it's a bug but not a major one, can be worked around.

[pnkfelix]

visited for triage 2013-07-23. Fixing this cleanly requires poking around in the expand code; I looked briefly at doing so: one obstacle is that the expand code (and potentially the ast fold functions it uses) would need to be generalized to support mapping an item to a ~[item], rather than an Option<item> like it does now. (The good news is that I think most of that change is largely mechanical. But then again, I did not take the time to finish hacking it up.)

[huonw]

@pnkfelix I don't think that's the problem for this exact issue (it is for #4375 though), #[deriving] is a ItemDecorator:

pub type ItemDecorator = @fn(@ExtCtxt,
                             span,
                             @ast::MetaItem,
                             ~[@ast::item])
                          -> ~[@ast::item];

I believe the problem is the items inside the stmts in a blk are never expanded.

(In any case, I have a feeling that @jbclements would appreciate syntax::ext remaining relatively stable until #7745 lands.)

[pnkfelix]

@huonw I agree that the problem is that items inside a statement are not expanded; I looked into the code to see how hard it would be to fix that. Expanding an item with an ItemDecorator requires handling the ~[@ast::item] it returns, but the relevant parts where this would naturally go are expecting only a Option<item>; that is all I was saying.

[pnkfelix]

(in particular, the deriving(Eq) attribute definitely requires being able to expand the item into multiple items.)

[huonw]

I see; that makes sense.

[lilyball]

Unfortunately this issue means we can't demonstrate #[deriving(...)] when using rusti in #rust.

[klutzy]

Still relevant. (revision 658637b)