Unused import `EmbedMigrations` from `embed_migrations!()`

[djc]

Setup

Versions

• Rust: 1.28.0
• Diesel: 1.3.2
• Database: SQLite
• Operating System macOS

Feature Flags

• diesel: chrono, sqlite

Problem Description

What are you trying to accomplish?

Run migrations in an automated integration test.

What is the expected output?

No compiler warnings.

What is the actual output?

   Compiling trackpay v0.1.0 (file:///Users/djc/src/trackpay)
warning: unused import: `EmbedMigrations`
   --> tests/simple.rs:203:1
    |
203 | embed_migrations!();
    | ^^^^^^^^^^^^^^^^^^^^
    |
    = note: #[warn(unused_imports)] on by default
    = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

I cannot reproduce this on the nightly compiler, though.

Are you seeing any additional errors?

No.

Steps to reproduce

Diesel-relevant changes that triggered this:

diff --git a/tests/simple.rs b/tests/simple.rs
index c409070..e175794 100644
--- a/tests/simple.rs
+++ b/tests/simple.rs
@@ -1,6 +1,9 @@
+extern crate diesel_migrations;
@@ -13,13 +16,29 @@
+    embedded_migrations::run(&*ctx.connection()).unwrap();
@@ -183,3 +202,5 @@
+embed_migrations!();

Checklist

• I have already looked over the issue tracker for similar issues.
• This issue can be reproduced on Rust's stable channel. (Your issue will be
  closed if this is not the case)

[djc]

BTW, I also ran cargo expand on my test module and could not find any mention of EmbedMigrations. So perhaps this is part of an intermediate macro output?

[weiznich]

Duplicate of #1739.
(Rustc uses the derive be in the error message, so this does not point to the actual unused important l

[pjenvey]

Can we leave this open until this fix is brought into the 1.3 branch?

[sgrif]

We will not be backporting this to 1.3

[djc]

@sgrif -- with all due respect, without any rationale given, your response to the backporting request comes off as rather curt.

Is there some policy against backporting? Is backporting excessively hard/expensive for this project? It seems like low-hanging fruit for users who get a false positive compiler warning, to me.