Code change:
} } } <ins> declare_lint! { pub UNNECESSARY_EXTERN_CRATE, Allow, "suggest removing `extern crate` for the 2018 edition" } pub struct ExternCrate(/* depth */ u32); impl ExternCrate { pub fn new() -> Self { ExternCrate(0) } } impl LintPass for ExternCrate { fn get_lints(&self) -> LintArray { lint_array!(UNNECESSARY_EXTERN_CRATE) } } impl<'a, 'tcx> LateLintPass<'a, 'tcx> for ExternCrate { fn check_item(&mut self, cx: &LateContext, it: &hir::Item) { if let hir::ItemExternCrate(ref orig) =  it.node { if it.attrs.iter().any(|a| a.check_name("macro_use")) { return } let mut err = cx.struct_span_lint(UNNECESSARY_EXTERN_CRATE, it.span, "`extern crate` is unnecessary in the new edition"); if it.vis == hir::Visibility::Public || self.0 > 1 || orig.is_some() { let pub_ = if it.vis == hir::Visibility::Public { "pub " } else { "" }; let help = format!("use `{}use`", pub_); if let Some(orig) = orig { err.span_suggestion(it.span, &help, format!("{}use {} as {}", pub_, orig, it.name)); } else { err.span_suggestion(it.span, &help, format!("{}use {}", pub_, it.name)); } } else { err.span_suggestion(it.span, "remove it", "".into()); } err.emit(); } } fn check_mod(&mut self, _: &LateContext, _: &hir::Mod, _: Span, _: ast::NodeId) { self.0 += 1; } fn check_mod_post(&mut self, _: &LateContext, _: &hir::Mod, _: Span, _: ast::NodeId) { self.0 += 1; } } </ins>

Related discussion:
text: We need to add an epoch lint for It will lint , suggesting removal in root mods, and replacement with in non-root mods. This is blocked on the ability to elide extern crate in the first place.
It is also blocked on a feature to force linkage of a crate, see this comment and the discussion afterwards:
cc
I think the lint should be by default off in cases with , such as: This is because of the ergonomics problems with macros and the new macro import system, expressed here: It's bewildering for the migrating users if a lint tells them not to use the syntax, but then finding out that many of the macros out there have downright bad ergonomics with the import syntax. (For clarification: I think this is an undesirable state of affairs, and we should be linting against all , but if we do that, the ergonomics problem with the macro import should be fixed somehow.)
I don't think we want at all, really. If we want to import macros, we should have another means of doing it. Otherwise we have an inconsistency. So yes, I think I agree with your last paragraph above all,
I've discussed this a bit in the tracking issue for the macros import system:
Thanks, you expressed the exact concern I had in a concise way.
Another thing this needs to lint is unlisted crates that are included in that clash with existing modules. I'm not quite sure on what the story needs to be here cc
Does it? I've thought one of the things the path clarity RFC was about was to have separate namespaces for top level modules and extern crates.
The current plan has changed a bit so I'm not sure if that is still true. (If stuff does change it will probably be RFCd again, there's a bit of experimentation going on)
Sigh I hope we won't discuss all of this crap all over again... I don't enjoy that but it is not me who wants to change things.
I've hidden your last comment, which I found hostile and unconstructive.
IDK what has been hearing, but for me, this is the latest state of consensus on that issue, and it seems to have separate namespaces: is that the case? You seem unresponsive on IRC that's why I'm using github.
That's mostly the latest state of consensus, yeah. Some tweaks have been made iirc. Everything has been implemented.