Fix R2R TypeMap fallback for unresolved assembly targets

[Copilot]

Description

Interop/TypeMap/TypeMapApp/TypeMapApp.cmd fails deterministically in all R2R configurations because of a disconnect between CrossGen2 and the runtime when a TypeMapAssemblyTarget references an unresolvable assembly (e.g., "DoesNotExist").

When CrossGen2 fails to resolve an assembly target, it catches the exception and sets error stubs on the external/proxy type maps (state=0), but AddTargetModule is never called, leaving TargetModules empty. CrossGen2 then emits a TypeMapAssemblyTargets entry with count=0 while marking the external/proxy maps as invalid. At runtime, HasTypeMapAssemblyTargets finds this empty entry → returns true with count=0 → sets hasPrecachedTargets = true → skips fallback to attribute processing → FileNotFoundException is never thrown.

Primary fix (runtime — assemblynative.cpp): The outer if block already enters when any of the three precached maps (targets, external, proxy) are missing. The assembly target attribute re-processing is now unconditional within that block, since the outer condition already guarantees at least one map needs fallback. The AssemblyTargetProcessor already deduplicates via _toProcess/_processed SHash collections, so re-processing is always safe.

if ((newExternalTypeEntry != nullptr && !hasPrecachedExternal) ||
    (newProxyTypeEntry != nullptr && !hasPrecachedProxy) ||
    !hasPrecachedTargets)
{
    // Fall back to attribute parsing for the assembly targets...
    // The AssemblyTargetProcessor already deduplicates, so re-processing is safe.
    ProcessTypeMapAttribute(
        TypeMapAssemblyTargetAttributeName,
        assemblies,
        groupTypeMT,
        currAssembly);
    // ...
}

Complementary cleanup (CrossGen2 — TypeMapAssemblyTargetsNode.cs): Skip emitting TypeMapAssemblyTargets entries for groups with zero resolved target modules, avoiding useless count=0 entries in the R2R image.

foreach (var map in _assemblyTypeMaps.Maps)
{
    if (map.Value.TargetModules.Count == 0)
        continue; // runtime will fall back to attribute processing
    // ...emit entry...
}

---

⚡ Quickly spin up Copilot coding agent tasks from anywhere on your macOS or Windows machine with Raycast.

[mangod9]

@copilot why did you not implement the option 1 as mentioned in the analysis on the issue?

[Copilot]

@copilot why did you not implement the option 1 as mentioned in the analysis on the issue?

Implemented Option 1 (the runtime fix) in 42159286. The condition in assemblynative.cpp now also re-processes assembly target attributes when the external/proxy type maps weren't pre-cached, which handles the mixed case where some assembly targets resolve and some don't. The CrossGen2 fix (Option 2) is kept as the complementary cleanup recommended in the analysis.

[jkoritzinsky]

This condition is the same as the condition on 1772. We can remove this and unconditionally run this block (the comment is good though).

[mangod9]

@copilot can you make the update as requested here ?

[Copilot]

Removed the redundant inner condition in bd14f210. The ProcessTypeMapAttribute call is now unconditional within the outer if block, with the explanatory comment preserved.