Fix ArgumentOutOfRangeException in Type and Decl constructors during ObjC AST traversal

[dalexsoto]

Problem

When using ClangSharp to traverse Objective-C translation units that include Apple system frameworks (e.g. <Foundation/Foundation.h>), the Type constructor throws ArgumentOutOfRangeException("handle") during deep AST traversal. This makes it impossible to some Objective-C frameworks like Facebook's FBSDKCoreKit using tools built on ClangSharp.

The crash was discovered while using the sharpie bind tool (from dotnet/macios) to generate C# bindings for iOS frameworks. The specific crash path is:

TranslationUnitDecl.Decls
→ RecordDecl.Decls (C struct fields from Foundation)
→ FieldDecl.Type
→ PointerType.PointeeType (lazy evaluation)
→ Type.Create() dispatches to AttributedType based on TypeClass
→ AttributedType constructor passes CXType_Attributed as expectedKind
→ Type constructor: handle.kind (CXType_ObjCId) != expectedKind → THROW

Root Cause

The Type constructor validates CXTypeKind (from libclang) BEFORE CX_TypeClass (from libClangSharp), and throws when they don't match. However, libclang's CXTypeKind is a coarser classification than libClangSharp's CX_TypeClass. For certain Objective-C types, libclang returns a broad kind like CXType_ObjCId (27) or CXType_Unexposed (1) while libClangSharp correctly classifies the same type as CX_TypeClass_Attributed by inspecting the Clang AST directly.

The Type.Create() factory method dispatches on TypeClass (which is correct), but the resulting subclass constructor then rejects the handle because CXTypeKind doesn't match the expected value. This is a false rejection — TypeClass is the authoritative classifier and should take precedence.

A secondary issue exists in the Decl constructor: the explicit check handle.DeclKind == CX_DeclKind_Invalid causes an unconditional throw even when Decl.Create()'s default case intentionally constructs a generic Decl wrapper for unknown declaration kinds. The default case passes expectedDeclKind = handle.DeclKind = CX_DeclKind_Invalid, which then triggers the Invalid-specific guard. This makes the default case dead code that always crashes instead of gracefully degrading.

Fix

Type.cs

• Reorder validation: check CX_TypeClass first (authoritative), then CXTypeKind (informational)
• When TypeClass matches but CXTypeKind doesn't, accept the type instead of throwing. This handles the common case where libclang uses a broader kind (e.g. CXType_ObjCId, CXType_Unexposed, CXType_ObjCObjectPointer) for a type that libClangSharp classifies more precisely

Decl.cs

• Remove the handle.DeclKind == CX_DeclKind_Invalid guard so that the default case in Decl.Create() can construct a generic Decl wrapper for unknown declaration kinds instead of crashing

Tests

Added 4 new tests in ObjectiveCTest.cs:

• Type_AttributedType_WithMismatchedCXTypeKind: Parses an ObjC file with nullable id parameters using Foundation headers and deeply traverses all type information including PointeeType and AttributedType chains
• Type_FullFoundationTraversal_DoesNotCrash: Full recursive traversal of all declarations from a Foundation-importing translation unit, including ObjCContainerDecl children and RecordDecl fields (the actual crash path)
• Type_DeepTraversal_DoesNotCrash: Deep traversal of inline ObjC code with interfaces, protocols, categories, methods, and properties
• Decl_InvalidDeclKind_DoesNotCrash: Traversal of diverse ObjC declaration kinds including CursorChildren access

The Foundation-based tests:

• Try iPhoneOS SDK first (where the bug manifests), fall back to macOS SDK
• Use xcrun clang --print-resource-dir for clang resource headers
• Gracefully skip via Assert.Ignore if no SDK is available
• Are already guarded by [Platform("macosx")] on the test class