Change:
<short summary of the bugI tried this code: Running on a project that has as its direct or indirect dependency. I expected to see this happen: All packages documented. Instead, this happened: — also fails on . : Does also happen for older nightlies, though I forgot to capture the versions before updating in hope it'd fix the issue. There are more ICE issues pointing at , but none on this line here. Backtrace:
I can confirm that this ICE does not occur on Rust 1.37.0 stable, as shown in This might be a regression that slipped through the stable release somehow.
This still happens on 1.39 stable.
cc
It also does it when documenting a project with on nightly. I had no trouble documenting all deps more than 2 weeks ago though.
This happened on our recent build rust 1.39.0 as well.
cc please triage regressions! If anyone would like to help out here: This is in need of a minimal example that reproduces the issue, as well as a bisection to pinpoint the PR that introduced this regression.
Sorry for not getting to this earlier. I've reduced down to: The is coming from the path inside which is messed up somehow by the macro. Bisecting this pointed to which almost certainly means it was caused by (cc. This is an issue in rustc as well because if you try to use the method from another crate like this for example: rather than the expected new` error since it now produces an ICE: <details<summarybacktrace</summary</detailsAnother interesting case comes from removing the inner module: This compile before but now somehow. Also the regressions in and are a similar but newer regression which I've made a new issue for: .
I guess I'll take a look since it's been a week. Thanks for the minimal code case!
Was this not fixed by ?
I don't know. If so then we're all good?
No, I can confirm there's still an ICE.
Is the nonrustdoc example from still ICEing or is it just the rustdoc issue left?
I'll see what happens.
Similarly to the case in this ICE in rustdoc may mean that a bug or error is silently ignored in rustc. So hiding it like does is not a good idea.
Fixed in

Discussion:
self.r.define(parent, ident, TypeNS, imported_binding); } <del> ItemKind::GlobalAsm(..) => {} </del> ItemKind::Mod(..) if ident.name == kw::Invalid => {} // Crate root ItemKind::Mod(..) => {

self.parent_scope.module = module; } <del> // Handled in `rustc_metadata::{native_libs,link_args}` ItemKind::ForeignMod(..) => {} </del> // These items live in the value namespace. ItemKind::Static(..) => { let res = Res::Def(DefKind::Static, self.r.definitions.local_def_id(item.id));

self.insert_field_names_local(def_id, vdata); } <del> ItemKind::Impl(.., ref impl_items) => { for impl_item in impl_items { self.resolve_visibility(&impl_item.vis); } } </del> ItemKind::Trait(..) => { let def_id = self.r.definitions.local_def_id(item.id);

self.parent_scope.module = module; } <ins> // These items do not add names to modules. ItemKind::Impl(..) | ItemKind::ForeignMod(..) | ItemKind::GlobalAsm(..) => {} </ins> ItemKind::MacroDef(..) | ItemKind::Mac(_) => unreachable!(), } }

} impl<'a, 'b> Visitor<'b> for BuildReducedGraphVisitor<'a, 'b> { <del> method!(visit_impl_item: ast::ImplItem, ast::ImplItemKind::Macro, walk_impl_item); </del> method!(visit_expr:      ast::Expr,     ast::ExprKind::Mac,       walk_expr); method!(visit_pat:       ast::Pat,      ast::PatKind::Mac,        walk_pat); method!(visit_ty:        ast::Ty,       ast::TyKind::Mac,         walk_ty);

visit::walk_trait_item(self, item); } <ins> fn visit_impl_item(&mut self, item: &'b ast::ImplItem) { if let ast::ImplItemKind::Macro(..) = item.kind { self.visit_invoc(item.id); } else { self.resolve_visibility(&item.vis); visit::walk_impl_item(self, item); } } </ins> fn visit_token(&mut self, t: Token) { if let token::Interpolated(nt) = t.kind { if let token::NtExpr(ref expr) = *nt {

<ins> // Visibilities on impl items expanded from macros are resolved (issue #64705). macro_rules! perftools_inline { ($($item:tt)*) => ( $($item)* ); } mod state { pub struct RawFloatState; impl RawFloatState { perftools_inline! { pub(super) fn new() {} // OK } } } pub struct RawFloatState; impl RawFloatState { perftools_inline! { pub(super) fn new() {} //~ ERROR failed to resolve: there are too many initial `super`s } } fn main() {} </ins>

<ins> error[E0433]: failed to resolve: there are too many initial `super`s. --> $DIR/impl-items-vis-unresolved.rs:21:13 | LL |         pub(super) fn new() {} |             ^^^^^ there are too many initial `super`s. error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </ins>