#[derive(Copy="something")] should be rejected

[aochagavia]

This compiles:

#[derive(Clone="2", Show(Wrong))]
struct MyStruct;

Other wrong attributes:

#[deprecated(Very, Wrong)]
#[test="something"]
#[test(Wrong)]
#[stable(Wrong)]
#[unstable(Wrong)]

[aochagavia]

cc @nick29581

[nrc]

I don't think it is intentional, the derive parser will collect arguments, and then the copy or clone impls will silently ignore them. It would be good to error or warn if we can here.

[aochagavia]

I could add a fix in #21265. Or do you prefer that I open a new PR for that?

[nrc]

new PR please

[nrc]

I guess this is technically a backwards incompatible change, since it will break programs with extraneous params. Although it is also just a bug. In any case, nomintating.

[kmcallister]

I think we have this problem throughout attribute handling code and not just on derive :/

[aochagavia]

I have updated the code example, since it is also possible to do #[derive(Clone(Wrong))]

I think the problem is in L61 and L62. We should only accept MetaWord and produce errors for MetaNameVariable and MetaList.

[brson]

many cases like this in the compiler where we are not vigilent about rejecting malformed attributes.

[pnkfelix]

polish issue, where it would not be the end of the world if we did not get around to addressing it, though it would be nice if it were fixed.

Assigning 1.0, P-low.

[kmcallister]

I think people will cut us a little slack on backwards compatibility of crap like

#[derive(Clone="2", Show(Wrong))]

The only way I could see this mattering is if a plugin makes an ill-advised attempt to extend the derive syntax. But plugins are unstable anyway.

[aochagavia]

I have updated the list of attributes (added #[test], #[deprecated], #[stable], #[unstable])

[pnkfelix]

This appears to be fixed; closing.