Change:
pub fn parameterized(f: &mut fmt::Formatter, substs: &subst::Substs, <del> did: DefId, </del> <ins> mut did: DefId, </ins> projections: &[ty::ProjectionPredicate]) -> fmt::Result { <ins> let key = ty::tls::with(|tcx| tcx.def_key(did)); let mut item_name = if let Some(name) = key.disambiguated_data.data.get_opt_name() { Some(name) } else { did.index = key.parent.unwrap_or_else( || bug!("finding type for {:?}, encountered def-id {:?} with no parent", did, did)); parameterized(f, substs, did, projections)?; return write!(f, "::{}", key.disambiguated_data.data.as_interned_str()); }; </ins> let mut verbose = false; let mut num_supplied_defaults = 0; let mut has_self = false; let mut num_regions = 0; let mut num_types = 0; <del> let mut item_name = None; </del> let mut is_value_path = false; let fn_trait_kind = ty::tls::with(|tcx| { // Unfortunately, some kinds of items (e.g., closures) don't have

Discussion:
UPDATE: Note that would like to mentor and wrote out some steps to fix this . repro steps: a new cargo project with rand to the dependencies with (Edit: also triggers the ICE) (Note that using various different crates as dependencies will also cause various different ICEs) (Also note that most of these ICEs do not occur if not setting while compiling) full log: Relevant excerpt:
As rbml is gone now (), maybe worth a try to re-test?
Suprisingly, this is still reproducible with : Also, it doesn't happen on the 1.12.0 release, so its a regression.
It happens on beta as well...
I think this is the closure bug (closures don't have generics atm, may change later). Technically not a language regression as this is from compiler logging and AFAIK that's disabled in non-nightly. The correct way to use is with a list of module paths (can be just crate names).
it reproduces on beta, so it will probably also reproduce on the next stable.
Introduced between and ().
repeating what I said in IRC (for readers who only read this discussion on github): compiler logging works for me on stable as well. Cross linking , as that issue contains discussion about which behaviour of the compiler to disable on stable and which not.
Title is misleading, rustc "debug" logging (literally of all output from ) doesn't work on stable, but handful of do. It's one of those rare cases where the information is essential to debugging ICEs and whatnot. The closure bug is preexisting, but ended up exposed ( and hit it in miri before). One reasonable workaround that can be backported to beta is adding before , and the argument to can be replaced with (since the loop finishes only when one of them is reached). Actually giving closures generics can be done after the refactor I'm working on lands, but right now it'd just be a messier hack, and printing code has to be rewritten anyway to handle multi-level generics. EDIT: willing to mentor this as it's not too complicated but testing it would be time-consuming.
compiler team please prioritize.
If the solution to this involves changing the name of keep in mind that cargo uses it too.
Did you remove T-compiler on purpose?
nope
I'll take this on, will ping when I have a chance to work on it.

Shouldn't be too long.
triage: P-medium We should fix this (and both and seem to be interested) but it's not considered a "high priority" regression, since it's not visible on stable and using on the compiler as an end-user is not really a recommended course of action.
Any progress? This is currently making my life difficult. It turns out that now triggers it, either in master or my private branch, not sure which.
Unfortunately not. I'm hoping to make some by the end of this week; I've tried looking at the code, but have not been able to talk to or about fixing this yet: I don't quite understand what eddyb suggested in the comment above. Feel free to steal this from me if you'd like, though.
I'll be happy to mentor you tomorrow.
This has been fixed; I understand you were waiting on that.
Not sure closing this is the best idea, don't think has been renamed yet.
I feel like renaming RUST_LOG is unrelated to the ICE and as such should probably be filed as a separate issue?
Fix is incomplete, reopening.
I thought this issue was for the RUST_LOG crash.
It was, and still is. I found another one that's still this issue, or at least closely related to it, then gave it to them on IRC. I'm sure can explain further, as I don't know about the parts of the code that that discussion ended up leading to.