Resolution of macro derive behavior has been modified on 1.30

[dereckson]

Setup

Versions

• Rust: 1.30.0-nightly (721913067 2018-08-26)
• Diesel: 1.3.2

Problem Description

In the past, the proc_macro! expansion could refer to items, without importing them explicitly again in the source file using this macro.

This behavior is being phasing out and triggers warnings at build time.

See rust-lang/rust#50504

And more explicitly rust-lang/rust#50504 (comment)

Steps to reproduce

1. Switch to an up to date nightly toolchain
2. Generate a schema through diesel migration run
3. Build anything using a models.rs with #[derive(Queryable,Debug)].

Output

For table!

warning: cannot find type `table` in this scope
   --> <table_body macros>:165:33
    |
165 | derive ( Debug , Clone , Copy , QueryId ) ] /// The actual table struct
    |                                 ^^^^^^^ names from parent modules are not accessible without an explicit import

For the models

  --> src/models.rs:14:10
   |
14 | #[derive(Queryable,Debug)]
   |          ^^^^^^^^^ names from parent modules are not accessible without an explicit import
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #50504 <https://github.com/rust-lang/rust/issues/50504>

Workaround

Invoke cargo or rustc with the RUSTFLAGS="-Aproc-macro-derive-resolution-fallback" environment variable.

For example, RUSTFLAGS="-Aproc-macro-derive-resolution-fallback" cargo check

You can also create a .cargo/config file at project level with the relevant flag:

[build]
#rustflags = ["-Aproc-macro-derive-resolution-fallback"]

Checklist

• This issue can be reproduced on Rust's stable channel. (Your issue will be
  closed if this is not the case)

It can't, as it's an upcoming behavior, but perhaps it's pertinent to track it, as it's mature code ready to land to stable at 1.30 release date (currently Oct 25 2018), and to document a workaround.

If not, we can probably close it and reopen at 1.30 release.

[Eijebong]

This has been fixed by #1787