The libClangSharp.runtime.win-arm64 22.1.8.2 native returns an invalid CX_TemplateName (kind == CX_TNK_Invalid) for the canonical TemplateSpecializationType of a dependent specialization base, e.g. Base<T> used as a base within a class template:
template <typename T> struct Base { int value; };
template <typename T> struct Derived : Base<T> {};
On every other RID (win-x64, linux-x64, linux-arm64, osx-arm64) the same input resolves the base to a valid ClassTemplateDecl. Only win-arm64 produces an invalid template name, which tripped TranslationUnit.GetOrCreate(CX_TemplateName)'s Debug.Fail("Unsupported template name encountered.") (and would NRE in Release). This surfaced as 8 DependentTemplateBaseTest failures exclusive to the win-arm64 debug CI leg on #805.
This looks like a win-arm64-specific native packaging/build defect (same class of problem as the mispackaged libClangSharp.runtime.win-x64 22.1.8.1 that shipped clang 21). The generator now falls back to resolving the base through the referenced ClassTemplateDecl so the invalid template name no longer breaks generation, but the underlying native should be verified/repackaged so Type_getTemplateName behaves consistently across all RIDs.
The
libClangSharp.runtime.win-arm6422.1.8.2 native returns an invalidCX_TemplateName(kind == CX_TNK_Invalid) for the canonicalTemplateSpecializationTypeof a dependent specialization base, e.g.Base<T>used as a base within a class template:On every other RID (win-x64, linux-x64, linux-arm64, osx-arm64) the same input resolves the base to a valid
ClassTemplateDecl. Onlywin-arm64produces an invalid template name, which trippedTranslationUnit.GetOrCreate(CX_TemplateName)'sDebug.Fail("Unsupported template name encountered.")(and would NRE in Release). This surfaced as 8DependentTemplateBaseTestfailures exclusive to the win-arm64 debug CI leg on #805.This looks like a win-arm64-specific native packaging/build defect (same class of problem as the mispackaged
libClangSharp.runtime.win-x6422.1.8.1 that shipped clang 21). The generator now falls back to resolving the base through the referencedClassTemplateDeclso the invalid template name no longer breaks generation, but the underlying native should be verified/repackaged soType_getTemplateNamebehaves consistently across all RIDs.