Dyn Trait & #[derive(Debug, Fail)]


#1

Hi,

I’m trying to play with the very exciting new dyn Traits in rust 1.27.0 but I’m getting one warning that I can’t understand – probably because my Rust-fu is still very…shaky.

I’m defining my own Failure using the failure crate and it looks like this:

#[derive(Debug, Fail)]
#[fail(display = "Sending failed.")]
pub struct TelegramError {
    cause: String,
}

When compiling and having #![warn(bare_trait_objects)] activated, I get this warning:

warning: trait objects without an explicit `dyn` are deprecated
  --> src/telegram.rs:18:17
   |
18 | #[derive(Debug, Fail)]
   |                 ^^^^ help: use `dyn`: `dyn (Fail)`
   |

So first of all I’m kinda surprised that derive is affected by this too – but that happens quite often to me :slight_smile: – but more importantly, I don’t know what to do about it?

The obvious solution of doing what it’s telling me leads to this error:

error: expected one of `)`, `,`, or `::`, found `(`
  --> src/telegram.rs:18:21
   |
18 | #[derive(Debug, dyn (Fail))]
   |                     ^ expected one of `)`, `,`, or `::` here

I’ve also tried to put the parens differently to no avail.

What am I missing here? Am I doing something wrong? Is there something weird about failure? Or about the linter? Why is it suggesting invalid syntax to me?


#2

I don’t think you’re doing anything wrong. I suspect failure's proc macro needs to be updated to use dyn syntax. It is odd how this error is surfaced though.

cc @withoutboats


#3

… thus breaking it on all older versions of rustc. The expansion could add an allow(bare_trait_objects), but that will also break on older versions of rustc. and allow(unknown_lints).

Rust could really use some kind of inert “allow lint even if it doesn’t exist” thing for derives.


#4

Isn’t that what #[allow(unknown_lints)] is for?


#5

Not a good answer, but that wouldn’t break older versions:

warning: unknown lint: `random_thing`
  --> src/main.rs:18:10
   |
18 | #![allow(random_thing)]
   |          ^^^^^^^^^^^^
   |
   = note: #[warn(unknown_lints)] on by default

(Doesn’t break in that this is only a warning)


#6

Did not know about that. In my defense, the only search results I could find (already knowing what it was called) were in the rustc source code, so I’m not sure this has ever been advertised.

If someone finds a warning annoying enough to try to silence it, producing a different warning isn’t an improvement. :stuck_out_tongue: But fair enough, I probably shouldn’t have used “break”.


#7

Oh, my bad, missed that the original problem was only a warning, not an error


#8

Well, originally I ran it with #![deny(bare_trait_objects)] since especially as a beginner (and primed by years of C :fearful: ) I tend to run my compilers in the strictest possible way. :slight_smile: The reason why I framed it as a warning is to avoid to get an answer that I can switch off deny. :slight_smile:


#9

That’s on one hand comforting :relieved:, but on the other hand the rest of the thread points sounds like that part of the implementation of dyn Impl has holes? Is that something that’s likely to be fixed inside Rust or how exactly is this thing leaking? :thinking:

Is possible to disable the warning selectively for specific expressions? I’ve tried a Hail Mary and plastered it with #[allow(bare_trait_objects)] from all sides but that didn’t do anything.


#10

Not sure what the best approach here is. One thing you can do is move your Fail derived types to a separate module, and then put a mod level #![allow(bare_trait_objects)] there.


#11

Thanks will try!

Thanks everyone for answering – Rust makes me feel very stupid very often so it’s very good to hear it’s not my fault this time. :slight_smile:


#12

cc @ekuber because the compiler diagnostic

warning: trait objects without an explicit `dyn` are deprecated
  --> src/telegram.rs:18:17
   |
18 | #[derive(Debug, Fail)]
   |                 ^^^^ help: use `dyn`: `dyn (Fail)`
   |

is, as discussed, suggesting an incorrect fix. Maybe it can be improved.


#13

Thanks for the ping, this is definitely something we want to probe for before giving suggestions. I’ll dig deeper when I have time.