Change:
Found in the crater run: ICEs: ` This ICE happens on: but only shows a compiler error.
Assigning as and removing .
This is because an integration gets checked, which relies on the feature to be enabled. Once it is enabled, does not fail anymore, and yet the ICE persists . I'll thus kindly ask for this to be "re-prioritized", if possible, thanks. modify labels: +I-prioritize
Assigning and removing as in the prioritization working group.
ping cleanup This needs mcve and bisection
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-07-20 to nightly-2020-08-25 regressed nightly: nightly-2020-07-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summary
Minimized:

Discussion:
use rustc_ast::expand::allocator::AllocatorKind; use rustc_data_structures::svh::Svh; use rustc_hir as hir; <ins> use rustc_hir::def::DefKind; </ins> use rustc_hir::def_id::{CrateNum, DefId, DefIdMap, CRATE_DEF_INDEX, LOCAL_CRATE}; use rustc_hir::definitions::{DefKey, DefPath, DefPathHash}; use rustc_middle::hir::exports::Export;

self.get_crate_data(def.krate).def_key(def.index) } <ins> fn def_kind(&self, def: DefId) -> DefKind { self.get_crate_data(def.krate).def_kind(def.index) } </ins> fn def_path(&self, def: DefId) -> DefPath { self.get_crate_data(def.krate).def_path(def.index) }

use rustc_ast::expand::allocator::AllocatorKind; use rustc_data_structures::svh::Svh; use rustc_data_structures::sync::{self, MetadataRef}; <ins> use rustc_hir::def::DefKind; </ins> use rustc_hir::def_id::{CrateNum, DefId, LOCAL_CRATE}; use rustc_hir::definitions::{DefKey, DefPath, DefPathHash}; use rustc_macros::HashStable;

// resolve fn def_key(&self, def: DefId) -> DefKey; <ins> fn def_kind(&self, def: DefId) -> DefKind; </ins> fn def_path(&self, def: DefId) -> DefPath; fn def_path_hash(&self, def: DefId) -> DefPathHash; fn all_def_path_hashes_and_def_ids(&self, cnum: CrateNum) -> Vec<(DefPathHash, DefId)>;

} } <ins> /// Walks up the tree of definitions starting at `def_id`, /// stopping at the first `DefKind::Mod` encountered fn nearest_mod_parent(&mut self, def_id: DefId) -> Module<'a> { let def_key = self.cstore().def_key(def_id); let mut parent_id = DefId { krate: def_id.krate, index: def_key.parent.expect("failed to get parent for module"), }; // The immediate parent may not be a module // (e.g. `const _: () =  { #[path = "foo.rs"] mod foo; };`) // Walk up the tree until we hit a module or the crate root. while parent_id.index != CRATE_DEF_INDEX && self.cstore().def_kind(parent_id) != DefKind::Mod { let parent_def_key = self.cstore().def_key(parent_id); parent_id.index = parent_def_key.parent.expect("failed to get parent for module"); } self.get_module(parent_id) } </ins> crate fn get_module(&mut self, def_id: DefId) -> Module<'a> { // If this is a local module, it will be in `module_map`, no need to recalculate it. if let Some(def_id) = def_id.as_local() {

.data .get_opt_name() .expect("given a DefId that wasn't a module"); <del> // This unwrap is safe since we know this isn't the root let parent = Some(self.get_module(DefId { index: def_key.parent.expect("failed to get parent for module"), ..def_id })); </del> <ins> let parent = Some(self.nearest_mod_parent(def_id)); </ins> (name, parent) };

if let Some(id) = def_id.as_local() { self.local_macro_def_scopes[&id] } else { <del> let module_def_id = ty::DefIdTree::parent(&*self, def_id).unwrap(); self.get_module(module_def_id) </del> <ins> // This is not entirely correct - a `macro_rules!` macro may occur // inside a 'block' module: // // ```rust // const _: () = { // #[macro_export] // macro_rules! my_macro { //     () => {}; // } // ` // We don't record this information for external crates, so // the module we compute here will be the closest 'mod' item // (not necesssarily the actual parent of the `macro_rules!` // macro). `macro_rules!` macros can't use def-site hygiene, // so this hopefully won't be a problem. // // See https://github.com/rust-lang/rust/pull/77984#issuecomment-712445508 self.nearest_mod_parent(def_id) </ins> } }

<ins> const _: () = { #[macro_export] macro_rules! first_macro { () => {} } mod foo { #[macro_export] macro_rules! second_macro { () => {} } } }; </ins>

<ins> // aux-build:issue-75982.rs // check-pass // Regression test for issue #75982 // Tests that don't ICE when invoking a foreign macro // that occurs inside a module with a weird parent. extern crate issue_75982; fn main() { issue_75982::first_macro!(); issue_75982::second_macro!(); } </ins>