Diesel: Macros 1.1 broken on nightly-2016-10-20

[shssoichiro]

If I try to compile a program which uses diesel 0.8.0, using rustc nightly-2016-10-20, the compilation fails in my crate with the following errors:

error: `Identifiable` is a derive mode
  --> src/models/account.rs:16:1
   |
16 | pub struct Account {
   | ^

error: `Queryable` is a derive mode
  --> src/models/account.rs:16:1
   |
16 | pub struct Account {
   | ^

error: `Insertable` is a derive mode
  --> src/models/account.rs:45:1
   |
45 | pub struct NewAccount {
   | ^

The program compiles and runs successfully on nightly-2016-10-19. Unless this is a bug in the latest nightly, the assumption that macros 1.1 would keep diesel from breaking with nightly updates may have been incorrect.

[sgrif]

I _think_ this is a bug in the latest nightly, but I will investigate further.

[oeb25]

FYI using the macro around the struct results in the same error eg.

// src/models.rs
Queryable! { struct Thing { ... } }

error: `Queryable` is a derive mode
 --> src/models.rs:3:1
  |
3 | Queryable! { struct Thing { ... } }
  | ^^^^^^^^^

having

// src/lib.rs
extern crate dotenv;

#[macro_use] extern crate diesel;
#[macro_use] extern crate diesel_codegen;

use diesel::prelude::*;
use diesel::pg::PgConnection;
use dotenv::dotenv;
use std::env;

pub mod schema;
pub mod models;

Any update on this? I read jseyfried's comment on the issue on the rust repo, but I'm not entirely sure what this means for Diesel.

Does this require a change in Diesel, user code or are we waiting for a fix in rust?

[SergioBenitez]

Any update on this? Just hit this bug.

[sgrif]

I'm hoping to get this fixed upstream.

[SergioBenitez]

@sgrif That seems like a direction that might take some time, if it is resolved in your favor at all. The issue seems to be that a recent change put macros and derives in the same namespace, thus Queryable! and [derive(Queryable)] collide. It does not seem like it would be onerous to rename one of the two, presumably the macro, to something different. Alternatively, you could provide a duplicate macro with a different name (say, Queryable_) that is only used for code generation so that Queryable can still be used by others. This would resolve the conflict while keeping the ergonomics you're presumably aiming for.