Fix collector ICE on closures from non-local crates

[mbrobbel]

Kernels that reach a closure defined in a dependency crate ICE the compiler:

error: internal compiler error: .../rustc_middle/src/ty/mod.rs:1529:13: item_name: no name for DefPath { data: [DisambiguatedDefPathData { data: ValueNs("gated_load"), disambiguator: 0 }, DisambiguatedDefPathData { data: Closure, disambiguator: 0 }], krate: crate48 }
  ...
  <rustc_codegen_cuda::collector::DeviceCollector>::should_collect_from_crate
  <rustc_codegen_cuda::collector::DeviceCollector>::enqueue_callable_trait_receiver_body

should_collect_from_crate (collector.rs) calls tcx.item_name to allow cross-crate kernel entry points, but closures have no item name. Closure DefIds from non-local crates reach it via enqueue_callable_trait_receiver_body — e.g. an FnOnce receiver inside a library function called from a kernel. Local-crate closures take the early LOCAL_CRATE return, so existing examples never hit this.

The fix uses opt_item_name and falls through to the crate-based decision for unnamed items, which can never be kernel entry points.

The first commit adds an extern_crate_closure example (following the cross_crate_embedded pattern) that reproduces the ICE without the fix; the closure is routed through an #[inline(never)] applier so MIR inlining doesn't erase it before collection.

🤖 Generated with Claude Code