Change:
<ins> error[E0255]: the name `issue_56411_aux` is defined multiple times --> $DIR/issue-56411.rs:5:21 | LL |             mod $name; |             ---------- previous definition of the module `issue_56411_aux` here LL |             pub use self::$name; |                     ^^^^^^^^^^^ |                     | |                     `issue_56411_aux` reimported here |                     you can use `as` to change the binding name of the import ... LL | import!(issue_56411_aux); | ------------------------- in this macro invocation | = note: `issue_56411_aux` must be defined only once in the type namespace of this module error[E0365]: `issue_56411_aux` is private, and cannot be re-exported --> $DIR/issue-56411.rs:5:21 | LL |             pub use self::$name; |                     ^^^^^^^^^^^ re-export of private `issue_56411_aux` ... LL | import!(issue_56411_aux); | ------------------------- in this macro invocation | = note: consider declaring type or module `issue_56411_aux` with `pub` error: aborting due to 2 previous errors Some errors occurred: E0255, E0365. For more information about an error, try `rustc --explain E0255`. </ins>

Discussion:
As of rustc 1.33.0-nightly ( 2018-12-22) the following macro invocation fails with an ICE. Mentioning and because this may have to do with slicing introduced in . Same repro in script form:
is working on a solution in

<details </summary<p</p is empty <details<summaryerror </summary<p<pre<font color="#AB4642"<b </b</font<font color="C1B9"<bice</b</font<font color="CAFC2"<bgit:(</b</font<font color="#AB4642"<bmaster</b</font<font color="CAFC2"<b) </b</font<font color="#F7CA88"<b</b</fontRUSTBACKTRACE=1 cargo +beta build <font color="#A1B56C"<bCompiling</b</fontice v0.1.0 (/home/shadlock0133/projects/rust/ice) thread &apos;main&apos; panicked at &apos;byte index 45 is out of bounds of &apos; stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at at 2: std::panicking::defaulthook::{{closure}} at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::continuepanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::str::sliceerrorfail at 10: core::str::traits::&lt;impl core::slice::SliceIndex&lt;str&gt; for core::ops::range::RangeTo&lt;usize&gt;&gt;::index::{{closure}} 11: rustcresolve::Resolver::reportconflict 12: rustcresolve::resolveimports::ImportResolver::resolveimports 13: rustcresolve::macros::&lt;impl syntax::ext::base::Resolver for rustcresolve::Resolver&lt;&apos;a, &apos;crateloader&gt;&gt;

::resolveimports 14: syntax::ext::expand::MacroExpander::expandfragment 15: syntax::ext::expand::MacroExpander::expandcrate 16: rustcdriver::driver::phase2configureandexpandinner::{{closure}} 17: rustc::util::common::time 18: rustcdriver::driver::phase2configureandexpand 19: rustcdriver::driver::compileinput 20: rustcdriver::runcompilerwithpool 21: rustcdriver::driver::spawnthreadpool 22: rustcdriver::runcompiler 23: &lt;scopedtls::ScopedKey&lt;T&gt;&gt;::set 24: &lt;std::panic::AssertUnwindSafe&lt;F&gt; as core::ops::function::FnOnce&lt;()&gt;&gt;::callonce 25: rustmaybecatchpanic at 26: rustcdriver::run 27: rustcdriver::main 28: std::rt::langstart::{{closure}} 29: std::panicking::try::docall at at 30: rustmaybecatchpanic at 31: std::rt::langstartinternal at at at 32: main 33: libcstartmain 34: &lt;unknown&gt; query stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.31.0-beta.19 ( 2018-11-26) running on x8664-unknown-linux-gnu note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib note: some of the compiler flags provided by cargo are hidden <font color="#AB4642"<berror:</b</fontCould not compile . To learn more, run the command again with --verbose. </pre</p</details
More or less same as should stop doing span arithmetics. cc
I don't see how not to do span arithmetics here ? In , the snippet is , source is and the binding is .

By taking the snippet that starts at the beginning of the binding span and end at the end of source span, we have In this case, I think it would be better to remove the suggestion when the issue happens in a macro because the suggestion will be wrong anyway.
we could completely avoid span arithmetics by giving more useful spans, instead of having to come up with them on the spot. The counterarguments to that would be that it would increase memory usage in every import and that this suggestion is already useless in macro context (especially in this case).