The error message for trying to derive an unsafe trait impl doesn't mention the trait name

[dotdash]

I tried to derive every possible trait on an enum and received this error:

enum-derive.rs:3:1: 3:112 note: in this expansion of #[derive] (defined in enum-derive.rs)
enum-derive.rs:3:1: 3:112 error: this unsafe trait should be implemented explicitly
enum-derive.rs:3 #[derive(PartialEq, PartialOrd, Clone, Copy, Hash, RustcEncodable, RustcDecodable, Eq, Ord, Debug, Send, Sync)]
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

which isn't as helpful as it could be because it doesn't tell me which of the traits is the one it's complaining about.

[durka]

We just need to split this function into two (so it knows whether it's Send or Sync) and change the message. Also, shouldn't it have printed two errors?

[durka]

This is actually a regression. Playpen. On stable and beta the error spans point to the trait names, but on nightly (RUST_NEW_ERROR_FORMAT or not) they point to the whole attribute. cc #33240 @nikomatsakis @jonathandturner

[nikomatsakis]

Hmm. This is definitely a regression, but I'm not sure whether it's necessarily related to the new error messages (I can't think how that change would have caused this). I wonder if there were any changes to the deriving code tweaking the spans that it is using? Have to dig into it.

[sophiajt]

Using a nightly before the new error format landed gives me this:

quicktest.rs:1:1: 1:112 error: this unsafe trait should be implemented explicitly
quicktest.rs:1 #[derive(PartialEq, PartialOrd, Clone, Copy, Hash, RustcEncodable, RustcDecodable, Eq, Ord, Debug, Send, Sync)] enum E {}
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So it's likely a change between the beta and the nightly before we added the new errors.

[nikomatsakis]

cc @LeoTestard could this have been caused by your changes related to stability? I suppose it might have been caused my PR for pattern matching, thought I don't think I changed any spans there.

[LeoTestard]

@nikomatsakis Hmm, possible. I'll look at it more deeply.

[LeoTestard]

Indeed it looks like it's caused by the fact that #[derive_*] attributes are now emitted with a special span so that the expansion functions for them knows if they have been generated by the expansion of a trusted attribute or if they have been written explicitly by the programmer (which is forbidden). I see three possiblities to fix that now:

• Make the generated attributes use their original span again, but somehow find a trick to mark that span as allowing unstable, instead of making them use another span.
• Keep things like that and change the expansion function for unsafe bounds to use the span of the meta item instead of the span of the whole attribute, which should point to the correct location I think. It's the easiest way, but there might be some other places in the expansion functions for other traits which might require the same fix.
• Change the way the expansion of #[derive] works to stop producing intermediate attributes and remove those span hacks. I think that's what @nrc said he wants, eventually.