Change:
EntryKind::AssociatedType(container) => { (ty::AssociatedKind::Type, container, false) } <ins> EntryKind::AssociatedExistential(container) => { (ty::AssociatedKind::Existential, container, false) } </ins> _ => bug!("cannot get associated-item of `{:?}`", def_key) };

Discussion:
<details<summaryICE</summary needs an arm for ? Edit:
Oops. Yea. I assumed this would work since works.
Is the fix just to have ? I that and it passes the repro in the OP, but my real code triggers another ICE at: where the returns If you think the fix for this ICE is just that one call, I can start making a minimal repro for this second ICE too.
I think they are closely related. We should probably run in case returns . A repro for that would be nice though. It should probably suffice to add some lifetimes to the existential type or its concrete type.
My real code's existential types do not have lifetimes, though they do have bounds. Adding bounds to the OP code did not repro the same crash. The concrete type for the first one is compiler-created because it's the return type of an async block. I believe this is sugar for , so that should also not have any lifetimes. The second one's concrete type is my own Stream impl that also does not have lifetimes. It'll take me some time to get a repro because something is broken with the rustc I built locally (it started hitting even though it was fine before, not sure why). If you want you can find the real code at The existential types are in the crate and imported by the workspace root crate. It won't compile because I'm still in the process of migrating it to std::future, but atleast it shouldn't ICE.
Rust + factorio? <3 the issue you are hitting is that a is hidden from you. I'm fixing that later today
The I started hitting was because of two different versions of libsyntaxpos in stage1 builds, as I described So with stage2 builds I don't have that problem, So I've got a repro for the issue where returns . It happens when using the imported existential type in a struct or enum definition, like: <details<summaryICE</summary</details
Your suggestion did fix that error by the way.
With the above patch, there is a new ICE when using the field inside an inherent method. <details<summaryICE</summary</details
For me another variant of this issues is blocker: and - is same : and : <details<summaryICE</summary<p</p</details
Is there any progress on this?

how do you feel about making a PR with your patch that has a partial fix? It looks like that would be enough to unblock me from using existential types in my project.
A bunch of stuff changed with so the second patch won't apply directly. I'll retest and put up a fork.
For the first ICE (function that returns existential type in crate A called from crate B), the patch (on top of ) is The second ICE (existential type exported from crate A used as struct member in crate B) is already fixed. The third ICE (existential type exported from crate A used in return type of a function in crate B) still exists. And, while I'm at it, ICE also still exists.
thanks so much for following up on this! Do you want to open a PR, since you've done all the work?
The patch is just guesswork on my part, and the whole thing is still broken anyway, so there's no point to me making a PR. If you want to try it you can apply that patch locally.
Just encountered an ICE and searching led me here. Is this just another instance of the same bug or should I report it separately? Run on using nightly rustc and you get:
I'm running into this with  too. Curiously, I see this when I run tests, presumably because the crate-under-test essentially operates as an "external" crate? <details<summaryICE</summary<pre<codeerror: internal compiler error: cannot get associated-item of thread 'main' panicked at 'Box<Any',

stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at 2: std::panicking::defaulthook::{{closure}} at at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanic 7: rustcerrors::Handler::bug 8: rustc::util::bug::optspanbugfmt::{{closure}} 9: rustc::ty::context::tls::withopt::{{closure}} 10: rustc::ty::context::tls::withcontextopt 11: rustc::ty::context::tls::withopt 12: rustc::util::bug::optspanbugfmt 13: rustc::util::bug::bugfmt 14: rustcmetadata::decoder::<impl rustcmetadata::cstore::CrateMetadata::getassociateditem 15: rustcmetadata::cstoreimpl::provideextern::associateditem 16: rustc::ty::query::querycompute::associateditem 17: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::associateditem<'tcx::compute 18: rustc::ty::context::tls::withcontext 19: rustc::depgraph::graph::DepGraph::withtaskimpl 20: <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q::start 21: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::forcequerywithjob 22: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,

'tcx::getquery 23: rustc::traits::project::assoctydef 24: rustc::infer::InferCtxt::commitifok 25: rustc::traits::project::optnormalizeprojectiontype 26: rustc::traits::project::normalizeprojectiontype 27: <rustc::traits::project::AssociatedTypeNormalizer<'a, 'b, 'gcx, 'tcxas rustc::ty::fold::TypeFolder<'gcx, 'tcx::foldty 28: rustc::traits::project::optnormalizeprojectiontype 29: rustc::traits::project::normalizeprojectiontype 30: rustc::ty::context::tls::withrelatedcontext 31: rustc::infer::canonical::queryresponse::<impl rustc::infer::InferCtxtBuilder<'cx, 'gcx, 'tcx::entercanonicaltraitquery 32: rustctraits::normalizeprojectionty::normalizeprojectionty 33: rustc::ty::query::querycompute::normalizeprojectionty 34: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::normalizeprojectionty<'tcx::compute 35: rustc::ty::context::tls::withcontext 36: rustc::depgraph::graph::DepGraph::withtaskimpl 37: <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q::start 38: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::forcequerywithjob 39: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::getquery 40: <rustc::traits::query::normalize::QueryNormalizer<'cx, 'gcx, 'tcxas rustc::ty::fold::TypeFolder<'gcx,

'tcx::foldty 41: <smallvec::SmallVec<Aas core::iter::traits::FromIterator<<A as smallvec::Array::Item::fromiter 42: rustc::ty::fold::TypeFoldable::foldwith 43: rustc::ty::structuralimpls::<impl rustc::ty::fold::TypeFoldable<'tcxfor &'tcx rustc::ty::TyS<'tcx::superfoldwith 44: <rustc::traits::query::normalize::QueryNormalizer<'cx, 'gcx, 'tcxas rustc::ty::fold::TypeFolder<'gcx, 'tcx::foldty 45: <smallvec::SmallVec<Aas core::iter::traits::FromIterator<<A as smallvec::Array::Item::fromiter 46: rustc::ty::fold::TypeFoldable::foldwith 47: rustc::ty::structuralimpls::<impl rustc::ty::fold::TypeFoldable<'tcxfor &'tcx rustc::ty::TyS<'tcx::superfoldwith 48: <rustc::traits::query::normalize::QueryNormalizer<'cx, 'gcx, 'tcxas rustc::ty::fold::TypeFolder<'gcx, 'tcx::foldty 49: <smallvec::SmallVec<Aas core::iter::traits::FromIterator<<A as smallvec::Array::Item::fromiter 50: rustc::ty::fold::TypeFoldable::foldwith 51: rustc::ty::structuralimpls::<impl rustc::ty::fold::TypeFoldable<'tcxfor &'tcx rustc::ty::TyS<'tcx::superfoldwith 52: <rustc::traits::query::normalize::QueryNormalizer<'cx, 'gcx, 'tcxas rustc::ty::fold::TypeFolder<'gcx, 'tcx::foldty 53: rustc::traits::query::normalize::<impl rustc::infer::at::At<'cx, 'gcx,

'tcx::normalize 54: rustc::ty::context::tls::withrelatedcontext 55: rustc::infer::InferCtxtBuilder::enter 56: rustctraits::normalizeerasingregions::normalizetyaftererasingregions 57: rustc::ty::query::_querycompute::normalizetyaftererasingregions 58: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::normalizetyaftererasingregions<'tcx::compute 59: rustc::ty::context::tls::withcontext 60: rustc::depgraph::graph::DepGraph::withtaskimpl 61: <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q::start 62: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::forcequerywithjob 63: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::getquery 64: <rustc::traits::query::normalizeerasingregions::NormalizeAfterErasingRegionsFolder<'cx, 'tcxas rustc::ty::fold::TypeFolder<'tcx, 'tcx::foldty 65: rustc::traits::codegen::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'tcx::substandnormalizeerasingregions 66: <rustcmir::monomorphize::collector::MirNeighborCollector<'a, 'tcxas rustc::mir::visit::Visitor<'tcx::visitterminatorkind 67: rustcmir::monomorphize::collector::collectitemsrec 68: rustcmir::monomorphize::collector::collectitemsrec 69: rustcmir::monomorphize::collector::collectitemsrec 70: rustcmir::monomorphize::collector::collectitemsrec 71: rustcmir::monomorphize::collector::collectitemsrec 72: rustcmir::monomorphize::collector::collectitemsrec 73: rustcmir::monomorphize::collector::collectitemsrec

74: rustcmir::monomorphize::collector::collectitemsrec 75: rustcmir::monomorphize::collector::collectitemsrec 76: rustcmir::monomorphize::collector::collectitemsrec 77: rustcmir::monomorphize::collector::collectitemsrec 78: rustcmir::monomorphize::collector::collectitemsrec 79: rustcmir::monomorphize::collector::collectitemsrec 80: rustcmir::monomorphize::collector::collectitemsrec 81: rustcmir::monomorphize::collector::collectitemsrec 82: rustcmir::monomorphize::collector::collectitemsrec 83: rustcmir::monomorphize::collector::collectitemsrec 84: rustcmir::monomorphize::collector::collectitemsrec 85: rustcmir::monomorphize::collector::collectcratemonoitems::{{closure}} 86: rustc::util::common::time 87: rustcmir::monomorphize::collector::collectcratemonoitems 88: rustc::util::common::time 89: rustcmir::monomorphize::partitioning::collectandpartitionmonoitems 90: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::collectandpartitionmonoitems<'tcx::compute 91: rustc::ty::context::tls::withcontext 92: rustc::depgraph::graph::DepGraph::withtaskimpl 93: <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q::start 94: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::forcequerywithjob 95: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,

'tcx::getquery 96: rustccodegenssa::base::codegencrate 97: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 98: rustc::util::common::time 99: rustcdriver::driver::phase4codegen query stack during panic: [associateditem] processing [normalizeprojectionty] normalizing [normalizetyaftererasingregions] normalizing [collectandpartitionmonoitems] collectandpartitionmonoitems end of query stack<code</pre</details
Yes. If you see the "Easy playground repro" link in the OP, that happens because the doctest is a separate crate.
any thoughts on the further ICEs that discovered when trying to fix this? This ICE sadly makes existential types pretty unusable in libraries.
Sorry about taking so long, it was just a few small fixes in the end. I think fixes all the ICEs mentioned in this issue.
Thanks. I confirmed this fixed all the issues with my original project too.
could you also take a look at , I suppose it is very close to that one. Thank you.